After auditing dozens of municipal websites across Canada, we have identified a clear pattern: the same accessibility failures appear again and again, across communities of every size and budget. The issues are remarkably consistent, and — this is the encouraging part — most of them are straightforward to fix once you know where to look.
Web accessibility is not about perfection. It is about ensuring that every resident can access the information and services your municipality provides online, regardless of ability. Under the Accessible Canada Act and equivalent provincial legislation, it is also increasingly a legal obligation. Here are the gaps we see most often.
Missing or meaningless alt text on images
This is the most common accessibility failure on municipal websites, and it is one of the simplest to fix. Every image on your website needs an alt attribute that describes the content or function of the image. Screen readers rely on this text to convey visual information to users who cannot see the image.
The problem is not usually that alt text is completely absent — most content management systems will at least generate an empty alt attribute. The problem is that the alt text, when it exists, is often meaningless. We routinely see alt text like "IMG_2847.jpg", "photo", or simply the filename of the image. None of these tell a screen reader user what the image actually shows. A photo of the mayor announcing a new park should have alt text that describes exactly that — not the camera's auto-generated filename.
Decorative images that do not convey content — background textures, divider lines, purely decorative icons — should have an empty alt attribute (alt="") so screen readers skip them entirely. The key principle: every image either needs a meaningful description or an explicit instruction to be ignored.
Insufficient colour contrast
WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Many municipal websites fail this standard, particularly on navigation elements, footer text, placeholder text in form fields, and text overlaid on images or coloured backgrounds.
Light grey text on a white background is the most frequent offender. It looks elegant in a design mockup, but it is genuinely difficult to read for people with low vision, colour blindness, or anyone viewing the site on a lower-quality screen in bright sunlight. The fix is straightforward: run your colour combinations through a contrast checker and adjust until they meet the minimum ratios. Tools like the WebAIM Contrast Checker make this a five-minute task for any colour pairing.
Forms without proper labels
Municipal websites are full of forms — service requests, permit applications, feedback forms, event registrations. For sighted users, a form field with visible placeholder text that says "Enter your email" seems perfectly clear. For screen reader users, if that field does not have a properly associated label element, it may be announced as simply "edit text" with no indication of what information is expected.
Every form field needs a label element with a matching "for" attribute, or an aria-label attribute if a visible label is not part of the design. Placeholder text is not a substitute for a label — it disappears when users start typing and is not reliably announced by all screen readers. This is particularly important for complex forms like permit applications, where dozens of fields may need to be completed correctly. If a screen reader user cannot identify what each field requires, the form is effectively unusable.
Missing heading hierarchy
Heading elements (h1 through h6) are not just visual styling choices — they create a structural outline of the page that screen reader users rely on for navigation. A properly structured heading hierarchy lets a user quickly scan the page and jump to the section they need, much the way a sighted user visually scans headings and subheadings.
The most common problems: pages with no h1 element, heading levels that skip (jumping from h2 to h4), headings used purely for visual styling rather than semantic structure, and pages where all text is the same size with no heading markup at all. Municipal pages with dense informational content — bylaws, council minutes, service descriptions — are the worst offenders. Fix the heading structure and you dramatically improve the experience for screen reader users and search engines alike.
PDFs that are not accessible
This may be the most pervasive accessibility barrier on municipal websites. Municipalities publish an enormous volume of content as PDF documents — council agendas, meeting minutes, bylaws, reports, forms, maps. The vast majority of these PDFs are not tagged for accessibility, meaning screen readers cannot parse their structure or read their content in a meaningful order.
Scanned documents are the worst case: they are essentially images of text, completely invisible to screen readers. But even digitally-created PDFs are often inaccessible if they have not been properly tagged with headings, reading order, alt text for images, and table structure. The solution is to either make PDFs accessible using tools like Adobe Acrobat's accessibility features, or better yet, publish the content as HTML web pages with PDF available as a secondary format. HTML is inherently more accessible and easier to maintain.
Keyboard navigation failures
Not every user navigates with a mouse. People with motor disabilities, power keyboard users, and screen reader users all rely on keyboard navigation. Every interactive element on your website — links, buttons, form fields, dropdown menus, modal dialogs — must be reachable and operable using only a keyboard.
The most common failures include dropdown menus that only open on mouse hover, modal dialogs that trap keyboard focus or do not trap it properly, custom interactive elements built with divs and spans instead of semantic HTML buttons and links, and missing visible focus indicators. Test your site by putting your mouse aside and trying to complete common tasks using only the Tab, Enter, Escape, and arrow keys. If you get stuck, your keyboard users are getting stuck too.
Where to start
You do not need to fix everything at once. Start with the pages that matter most — your homepage, your service request forms, your contact page, your most-visited content pages. Run an automated scan using a tool like axe or WAVE to identify the low-hanging fruit, then work through the issues systematically. Automated tools will catch about 30 to 40 percent of accessibility issues. For the rest, you need manual testing: keyboard navigation, screen reader testing, and ideally, testing with people who actually use assistive technology.
Accessibility is not a destination — it is an ongoing practice. Build it into your content publishing process, your design reviews, and your vendor requirements. Every improvement you make is an improvement for real residents in your community who are currently being excluded from services they have every right to access.
Want to talk about this for your municipality?
Start a conversation →