When a compliant website still fails its residents

Picture a resident trying to renew a parking permit online. The page loads quickly. The heading structure is correct. The contrast passes WCAG AA. The form fields all have proper labels. Your automated accessibility scanner gives it a clean bill of health.

Then the resident hits the first instruction: "Applicants must submit the prescribed documentation in accordance with the applicable municipal bylaw provisions."

They close the tab and call the helpline instead.

This is the gap that sits between legal compliance and real inclusion. WCAG 2.1 and AODA tell us what our websites must do structurally. They say almost nothing about whether a resident with a Grade 10 reading level, or a newcomer still building English fluency, can actually understand and use what's in front of them. Accessible markup and plain language are not the same thing. We need both.

Why this checklist has two parts

Accessibility standards (WCAG 2.1 Level AA, which AODA requires for Ontario public-sector sites) define a technical floor: perceivable, operable, understandable, robust. They cover structure, contrast, keyboard behavior, and code semantics.

Plain language is a separate discipline focused on clarity, reading level, and cognitive load. It answers a different question: once a resident can perceive and operate your form, can they actually understand what it's asking?

Neither discipline replaces the other. A screen reader delivers every word perfectly to a blind user. If those words are bureaucratic boilerplate, the experience is still broken. Real inclusion means both layers work together.

The checklist below is split into two parts. Work through Part 1 to verify your technical accessibility. Work through Part 2 to audit your content's language. I recommend reviewing both during any content update, not just initial builds.

Part 1: Accessibility checklist

Headings and document structure

Headings are the skeleton of a web page. Screen reader users navigate by jumping between headings, the same way sighted users scan visually. A broken heading structure turns that navigation into a guessing game.

Check these things:

Quick test: Open any high-traffic page. Read only the headings, in order. Do they tell a coherent story about what the page contains? If the headings are vague or out of sequence, so is the experience for someone navigating without a mouse.

Common failure on municipal sites: A page titled "Permits and Licensing" with a single H1, then a mix of bold paragraphs and H3s used for visual formatting, no H2s at all.

Colour contrast

Low contrast is the most common accessibility failure I find on municipal sites, and also one of the easiest to fix. The standard is clear: normal text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt or larger, or 14pt bold) needs at least 3:1.

Check these things:

Free tool: WebAIM's Contrast Checker lets you paste in hex codes and get an instant ratio. Run it on your primary text colour, your navigation links, your button labels, and any secondary or caption text.

Common failure on municipal sites: Navigation bars using the municipality's brand colours, where white text on a light blue background fails at 2.8:1.

Keyboard navigation

Every piece of functionality on your site must be reachable and operable with a keyboard alone. This covers users who cannot use a mouse (motor disabilities, tremors, some mobility conditions) as well as screen reader users.

Check these things:

Quick test (do this right now): Unplug your mouse or disable your trackpad. Navigate to your homepage and try to complete one common task, such as finding a service page or submitting a contact form. Count how many times you press Tab before reaching the main content. If it is more than three, you are missing a skip link.

Skip link basics: Add a "Skip to main content" link as the very first focusable element on every page. It can be visually hidden by default but must become visible on keyboard focus.

<!-- Add this as the first element inside <body> -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- Then on your main content area -->
<main id="main-content">
  <!-- page content -->
</main>

Readable forms

Forms are where accessible structure and plain language collide. A technically correct form can still be completely unusable if the fields are confusing, the instructions are vague, or errors provide no guidance.

Check these things:

<!-- Bad: no label, placeholder only -->
<input type="text" placeholder="Date of birth (DD/MM/YYYY)">

<!-- Good: visible label, input with id, placeholder as a hint only -->
<label for="dob">Date of birth</label>
<input
  type="text"
  id="dob"
  placeholder="DD/MM/YYYY"
  autocomplete="bday"
  aria-describedby="dob-hint"
>
<span id="dob-hint">Format: day, month, year. Example: 14/10/1985.</span>

On error messages: "Invalid input" tells a user nothing. "Please enter your date of birth in DD/MM/YYYY format, for example 14/10/1985" gives them a path forward. Error messages are not legal disclaimers: they are instructions.

Images and alt text

Alt text is not just a legal checkbox item. It is the primary way screen reader users experience images. Every image on a municipal website carries meaning: a photo of a community event, a map of a construction closure, a chart of budget allocations. That meaning needs to be communicated in text.

Check these things:

A note on quality: Alt text that says "photo" or "image.jpg" is not alt text. It is noise. Describe what the image shows and why it matters in context. For a photo of the mayor signing a bylaw, a useful description is: "Mayor Johnson signs the Accessible Pedestrian Infrastructure Bylaw at City Hall, surrounded by members of the Accessibility Advisory Committee."

Documents and PDFs

PDFs are one of the most consistently inaccessible formats on municipal websites. Scanned documents are images. Images have no text. Screen readers cannot read images. This is one of the most common grounds for AODA complaints I see in audits.

Check these things:

Practical rule of thumb: If a document is accessed more than 500 times per month, it should be an HTML page, not a PDF. The conversion effort pays off quickly in usability, accessibility, and search visibility.

Part 2: Plain language checklist

Meeting your technical accessibility obligations is necessary. But readability is what determines whether your residents actually trust and use your website. Plain language is not dumbing things down: it is respecting your audience's time.

The target reading level for municipal web content is Grade 7-8. That is not because your residents are unsophisticated. It is because they are often reading quickly, on a phone, while doing something else, possibly in their second or third language.

Cut the bureaucratic preamble

Municipal content often opens with legal throat-clearing before getting to the actual information. Residents scan. They do not read top-to-bottom. If the first two sentences do not tell them what the page is about and whether it applies to them, they are already gone.

Rewrite patterns:

| Before | After |

|---|---|

| "Pursuant to the provisions of the Municipal Act, 2001, the City of [Name] hereby notifies eligible residents..." | "You may qualify for this program if..." |

| "This page provides information regarding the applicable requirements for the submission of..." | "To apply for a [permit/licence/program], you'll need to..." |

| "Residents are advised that in accordance with current operational protocols..." | "Starting [date], the process has changed. Here's what to do." |

Front-load the action. What does the resident need to know? What do they need to do? Put that in the first sentence.

Use active voice

Active voice puts the person doing the thing first. Passive voice buries them. This matters for clarity, and it matters especially for residents whose first language is not English.

Rewrite patterns:

| Before (passive) | After (active) |

|---|---|

| "Applications must be submitted by October 31." | "Submit your application by October 31." |

| "Supporting documents are required to be uploaded." | "Upload your supporting documents." |

| "Fees will be collected upon issuance of the permit." | "You'll pay the fee when we issue your permit." |

| "The form is to be completed in its entirety." | "Fill out every section of the form." |

Active voice is also shorter by default. Shorter sentences reduce reading load. Both benefits compound when you scale across a site with hundreds of pages.

Rewrite for residents, not legal review

Legal language is written to be defensible. Plain language is written to be usable. These are different goals, and your web content should serve the second one. Your legal team can review a plain-language page and confirm its accuracy without requiring it to read like a regulation.

Phrase replacement guide:

| Bureaucratic phrase | Plain language replacement |

|---|---|

| "Submit the prescribed documentation" | "Send us the documents we need" or "Upload your [specific documents]" |

| "Notwithstanding the aforementioned" | "Even so" or restructure to remove it entirely |

| "Eligible individuals may avail themselves of" | "You can use" or "This is available to you if" |

| "The municipality endeavours to provide" | "We're working to provide" or "We provide" |

| "In the event that your application is deemed incomplete" | "If we need more information from you" |

| "Remit payment to" | "Pay" |

| "Upon receipt of all requisite materials" | "Once we have everything we need" |

| "The aforementioned policy is subject to amendment" | "This policy may change" |

When you catch yourself writing a phrase that belongs in a legal notice rather than a conversation, stop. Ask: how would I explain this to a neighbour? Write that instead, then let legal review the meaning, not the wording.

Define terms and explain acronyms

Do not assume residents understand internal terminology, program names, or government acronyms. Every acronym needs a full name on first use. Every program name that is not self-explanatory needs a one-sentence description.

Examples:

If you are using an acronym or program name more than three times on a page, define it once at the top, then use it freely below.

Test with someone who is not you

Every content author is too close to their own work. The best plain language check is a read-aloud test with someone outside your department: ideally someone who represents your actual audience.

A simple usability test (30 minutes, no tools required):

You will learn more from one 30-minute session than from 10 automated scans.

The combined quick-review checklist

Use this before publishing any new or updated page. It is not exhaustive, but it catches the most common failures.

Accessibility (technical)

Plain language (content)

Where to start if this feels overwhelming

Twenty checklist items can feel like a lot, especially for a small web team managing hundreds of pages. Start with the highest-traffic pages (check your analytics for the top 20) and work through only the items marked as WCAG "Level A" violations first.

A useful prioritization order:

Perfect is slow. Progress is fast. Every page you improve reduces friction for a real resident trying to do a real thing. That compounds.

Want a hands-on accessibility and plain language audit for your municipal website? Get in touch for a prioritized findings report and a remediation roadmap your team can act on immediately.