Accessibility

Municipal website accessibility: a practical guide

Accessibility is an ongoing municipal service practice. The platform matters, and so do the words, documents, forms, publishing habits, testing, and response when a resident encounters a barrier.

Published July 9, 2026 · Reviewed against W3C guidance · 9 minute read

An accessibility widget cannot make an inaccessible website accessible. Strong semantics, keyboard support, readable content, usable forms, accessible documents, testing, and a feedback process all matter.

Start with WCAG, then check local requirements

The W3C Web Content Accessibility Guidelines provide a shared international technical standard. WCAG 2.2 groups 13 guidelines under four principles: perceivable, operable, understandable, and robust, with testable success criteria at A, AA, and AAA levels.

W3C encourages use of the latest WCAG version. Laws and policies may reference different versions or add obligations beyond web content. In Canada, requirements also vary across federal, provincial, and municipal contexts. In the United States, ADA and Section 508 questions have their own scope. Do not substitute a marketing claim for a jurisdiction-specific review.

Accessibility is a shared responsibility

LayerWhat it should cover
PlatformSemantic templates, keyboard operation, focus, responsive layouts, contrast, form behavior, language attributes, error handling, and editor guardrails.
ImplementationNavigation, branding colours, integrations, migrated content, custom components, third-party tools, and launch testing.
Municipal contentHeadings, links, images, tables, video, plain language, documents, translations, and accurate service instructions.
OperationsTraining, ownership, recurring testing, issue response, procurement, accessibility statements, and public feedback.

Everyday publishing checklist

  • Use descriptive page titles and a logical heading hierarchy; do not choose headings for visual size.
  • Write links that make sense out of context. Replace “click here” with the destination or action.
  • Provide meaningful text alternatives for informative images and mark decorative images appropriately.
  • Do not rely on colour, position, shape, or sound alone to communicate meaning.
  • Use plain language, short sections, descriptive labels, and explicit dates and deadlines.
  • Identify page language and preserve a real review workflow for translated content.
  • Provide captions and, where needed, transcripts or audio description for media.

Documents and forms are part of the website

A tagged PDF can still be difficult to use, especially on a phone. Publish important service information as HTML where practical. When a document is necessary, require structure, reading order, document title, language, table headers, meaningful links, and text alternatives.

Forms need persistent labels, clear instructions, programmatic relationships, keyboard operation, understandable validation, error summaries, and a way to review important submissions. Test the complete workflow, including embedded vendors, payment handoffs, confirmation messages, and email receipts.

Use automated and human testing

Automated checks are valuable for repeatable issues but cannot determine whether alternative text is useful, instructions make sense, focus order follows the task, or a screen-reader experience is coherent. WCAG itself is designed to be tested with a combination of automation and human evaluation.

  • Automated scanning across representative templates and new content.
  • Keyboard-only review, including visible focus, menus, dialogs, forms, and skip links.
  • Screen-reader testing on important resident journeys.
  • Zoom, reflow, mobile orientation, high contrast, reduced motion, and text-spacing checks.
  • Manual content and document review by trained people.
  • Testing with people with disabilities where the scope and risk warrant it.

Ask vendors for a process, not a promise

Ask which WCAG version and conformance level they target, what evidence supports the claim, what was tested manually, which pages/components were sampled, how third-party tools are treated, who remediates migrated content, and what happens when a resident reports a barrier.

Accessibility is one part of the broader website evaluation. Use the local government website software buyer’s guide to connect it to migration, ownership, support, and staff workflow.

Primary references