Website Accessibility for Canadian Organizations: Practical Planning

Start with what applies to you, then plan as if it all does

There is no single Canadian rule that tells every organization exactly what its website must do. Obligations depend on who you are and where you operate. Federally regulated organizations fall under the Accessible Canada Act. Several provinces have their own accessibility legislation, with Ontario’s the longest established and Nova Scotia and Newfoundland and Labrador among those that have passed laws with standards being developed and phased in over time. Human rights legislation, which applies to services offered to the public, sits underneath all of it. Public bodies and organizations that receive public funding may also have policy or contract requirements on top.

The legal landscape is covered in more detail in website accessibility and Canadian law. This article assumes you have read that, or asked your counsel, and want to know what to actually do. Confirm your specific obligations with a lawyer or the relevant provincial body, because they vary and they change.

Here is the practical point: whatever your legal exposure, the work to make a website accessible is the same. People who use screen readers, navigate by keyboard, need captions, zoom to large text or struggle with cluttered pages exist in every audience. Planning for them is planning for your customers. It also tends to make the site clearer for everyone else, which is not a bad side effect for a business website.

Pick a standard and write it down

“Accessible” is not a requirement anyone can test. A named standard is. The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the reference most Canadian legislation, policy and procurement language points to. They are organized into conformance levels A, AA and AAA, and level AA is the target most organizations are asked to meet. The 2.x versions are designed to be backward compatible, so building to the current one generally satisfies the earlier ones as well.

Write the version and level into three places:

1. The project brief or RFP, so bidders price it. The guide to writing a website RFP covers how to phrase it.
2. The contract, with how conformance will be verified before launch and who fixes failures.
3. Your internal content guidelines, so the standard survives the handoff from the builder to your team.

Also decide what is in scope. The public website, obviously. What about the client portal, the job application system, the booking widget, the PDF annual report? Third-party tools are where many accessibility plans quietly fail, because nobody asked the vendor.

Build it into design and development

Accessibility is cheapest at the start and most expensive as a retrofit. In practice, that means each phase owns a specific set of decisions.

Design

• Colour contrast checked in the design system, before any page is designed. Fixing contrast after launch can mean revisiting the brand palette on the web.
• Information never conveyed by colour alone (a red border on a form error needs a text message too).
• Visible focus states, so keyboard users can see where they are.
• Layouts that hold up when text is enlarged, and touch targets large enough for a thumb.
• Motion that can be reduced, and nothing that flashes.

Development

• Semantic HTML: real headings in order, real buttons, real lists. Most screen reader problems start with a div pretending to be something else.
• Every form field with a proper label, errors announced clearly, and no time limits that cannot be extended.
• Full keyboard operation, including menus, modals, carousels and anything custom.
• Correct language attributes, which matters for bilingual sites so screen readers pronounce French as French. The bilingual website planning guide covers accessibility in both languages.

Content

• Meaningful alt text, written by someone who knows why the image is there.
• Captions and transcripts for video.
• Link text that makes sense out of context (not “click here”).
• Plain language, short paragraphs and descriptive headings.

Test in layers

No single test proves a site is accessible. Plan for several, because each catches different problems.

1. Automated scanning. Browser extensions and scanning tools catch missing alt attributes, contrast failures, empty links and missing labels quickly. They cannot judge whether alt text is meaningful or whether a page makes sense, so treat a clean automated scan as the start of testing, not the end.
2. Keyboard testing. Put the mouse away and try to complete your key tasks: navigate the menu, submit the contact form, book an appointment. This takes minutes and finds problems automated tools miss.
3. Screen reader testing. Use at least one desktop and one mobile screen reader on your key templates. The goal is to hear whether the page makes sense in order, not to become an expert user.
4. Zoom and reflow. Enlarge the text and narrow the window. Does content stay readable without horizontal scrolling?
5. An independent audit before launch, by someone other than the people who built the site.
6. Testing with disabled users, where budget allows. Nothing else tells you as much about whether a task is genuinely usable.

Test templates and key tasks, not every page. If the service page template, the form and the navigation work, most of the site follows. Then spot-check the pages with the most traffic.

Documents and third-party tools

Two areas cause more trouble than the rest of the site combined.

Documents. A scanned PDF is an image of text, and to a screen reader it is effectively blank. Many organizations publish forms, reports, menus and agendas this way. The planning question is: does this need to be a document at all? Content that people read on screen is usually better as a web page. Where a document is genuinely needed, create it from a source file with proper headings and tags, and check it before publishing.

Third-party tools. Booking engines, chat widgets, embedded maps, payment pages, job application portals and cookie banners all live on your site from the visitor’s point of view. Ask each vendor for their accessibility conformance documentation, test the parts your visitors use, and treat a poor answer as a factor in choosing the tool. It is hard to fix someone else’s code.

Be careful with overlay products that promise to make a site compliant by adding a script. They do not fix the underlying markup, and many accessibility practitioners and disabled users regard them as a poor substitute for doing the work properly.

Roles and governance after launch

A site that passes an audit on launch day can fail within a few months. Someone uploads a scanned PDF, adds an image without alt text, embeds a video without captions, or installs a widget. Accessibility is a habit, and habits need owners.

• An accountable owner who reports on accessibility the way someone reports on security or privacy.
• Editor training, delivered at launch and repeated when staff change.
• A publishing checklist short enough that people actually use it: headings, alt text, link text, captions, document format.
• A scheduled review, perhaps quarterly, with an automated scan and a keyboard check of key tasks.
• A way for visitors to report barriers, with someone who responds.
• An accessibility statement describing the standard you aim for, known limitations and how to contact you.

Put the scheduled review into the same rhythm as your other post-launch work. The checklist in what to expect after launching a new website includes it alongside monitoring and maintenance.

An illustrative plan for a mid-sized organization

Consider a hypothetical regional health clinic group in New Brunswick, with several locations, an online booking tool and a bilingual site. A workable plan looks like this:

1. Counsel confirms which obligations apply, and leadership names a WCAG version at level AA as the target.
2. The redesign brief and contract include the standard, an independent audit before launch and editor training.
3. The booking vendor is asked for its conformance documentation and tested with a keyboard and screen reader in both languages. Gaps go to the vendor in writing.
4. Patient forms are rebuilt as web forms instead of downloadable PDFs.
5. The communications coordinator owns the publishing checklist and runs a quarterly review.

None of that requires an accessibility specialist on staff. It requires decisions made early and written down. That is how we approach accessibility on website design and development projects: as a requirement in every phase rather than a finding in the last one.