Accessibility is not only a legal concern. It is a design and engineering baseline that affects forms, navigation, content, checkout, and whether people can use the site at all.
For websites serving Canada and the United States, WCAG 2.2 AA is a practical accessibility baseline. Focus first on keyboard access, visible focus, semantic headings, labels, contrast, forms, checkout, modals, media, and error messages. This is technical guidance, not legal advice.
Key takeaways
- Accessibility should be scoped before design and development, not patched only after launch.
- Forms, checkout, navigation, modals, PDFs, video, and custom components create the most practical risk.
- U.S.-facing websites should consider ADA exposure even when the company is based in Canada.
- The best accessibility work combines automated checks, keyboard testing, screen reader spot checks, and manual review.
Use WCAG as the practical baseline
WCAG is the most useful working standard for design and development teams. A practical baseline includes semantic headings, visible focus states, keyboard navigation, sufficient contrast, labels, alt text, and predictable error messages.
For U.S.-facing sites, ADA risk often makes accessibility a business issue even when the company is based in Canada. Legal interpretation should come from counsel, but implementation habits can start in the build.
The highest-risk areas
Forms, ecommerce checkout, modals, navigation, video, PDFs, color contrast, and custom interactive components create most of the practical risk. These should be checked before launch, not after a complaint.
Forms
Every field needs a label, clear errors, keyboard access, and success/failure states.
Navigation
Menus, language switchers, accordions, and modals need predictable focus behavior.
Content
Headings, alt text, link labels, captions, and readable contrast shape daily usability.
| Area | What to check | Why it matters |
|---|---|---|
| Forms | Labels, errors, instructions, focus order, keyboard access, success states | Forms are where users request quotes, buy, subscribe, and contact support |
| Navigation | Menus, language switchers, skip links, focus states, mobile drawers | People need to move through the site without a mouse |
| Checkout and portals | Modals, validation, payment steps, account pages, session messages | Blocked transactional flows create both revenue and compliance risk |
| Content | Headings, link labels, contrast, alt text, captions, PDFs | Readable structure helps users and assistive technology understand the page |
How to include accessibility in scope
Add accessibility expectations to the project brief. Define the target baseline, who checks it, which templates are tested, and what happens if third-party apps or embedded tools fail.
Accessibility is easier when components are designed correctly from the start. Retrofitting later usually costs more and creates awkward compromises.
What to include in a practical accessibility pass
A practical accessibility pass should cover design tokens, reusable components, content templates, and real user flows. Checking only one page does not help if the same broken modal, menu, or form component appears everywhere.
The goal is not to make a perfect legal claim. The goal is to reduce known barriers, document the baseline, and build habits that make future pages easier to maintain.
Automated checks
Use tools to catch missing labels, contrast issues, ARIA mistakes, and obvious structural problems.
Manual keyboard review
Navigate the main flows with Tab, Shift+Tab, Enter, Escape, and arrow keys where applicable.
Template coverage
Test homepage, service page, article, contact form, ecommerce flow, modal, and portal views when present.
Frequently asked questions
What accessibility standard should a Canada/U.S. website use?
WCAG 2.2 AA is a practical baseline for most design and development work, though legal obligations can vary by jurisdiction and should be reviewed with counsel.
Is ADA compliance relevant to Canadian companies?
It can be relevant when a Canadian company serves U.S. customers or operates in the U.S. market. The legal interpretation should come from counsel, but accessibility implementation should still be part of the build.
What are the fastest accessibility wins before launch?
Check color contrast, keyboard navigation, focus states, form labels, error messages, headings, alt text, button names, and modal behavior.
Can automated accessibility tools find every issue?
No. Automated tools are useful, but they miss many usability problems. Combine them with keyboard testing, screen reader spot checks, and manual review of real flows.
This primer is implementation guidance from Odavio accessibility QA work for marketing sites, ecommerce flows, and web apps. It is not legal advice; legal obligations should be reviewed by qualified counsel.