A customer visits a Canadian municipality's website to renew a permit. The form looks straightforward, but its date picker cannot be operated with a keyboard. Another visitor uses a screen reader and encounters three buttons labelled only as 'Learn more.' A third tries to check out from an online store but cannot distinguish the error message from the surrounding text.
These are not merely design inconveniences. They are barriers that can prevent people from accessing information, completing transactions, or using services independently.
Website accessibility means designing and maintaining digital experiences that people with disabilities can use. For Canadian businesses, public agencies, and organisations serving the public, it deserves attention during planning and development rather than as a final inspection before launch.
The Web Content Accessibility Guidelines (WCAG) 2.2, published by the World Wide Web Consortium (W3C), provide a practical technical framework for this work. They cover how people perceive content, operate interfaces, understand information, and interact with web technologies. The important distinction is that WCAG 2.2 is a useful current benchmark, but the legal standard applicable to an organisation depends on the legislation and regulations governing it.
What WCAG 2.2 means for a Canadian website
WCAG organises accessibility requirements around four principles: content must be perceivable, operable, understandable, and robust. These principles address different ways people interact with websites, including users who rely on screen readers, keyboard navigation, magnification, voice input, captions, or other assistive technologies.
The guidelines contain testable success criteria grouped into three conformance levels:
Level A: Addresses fundamental accessibility barriers, including keyboard access and text alternatives for meaningful non-text content.
Level AA: Adds requirements such as sufficient text contrast, clearer navigation, accessible forms, and appropriate text resizing.
Level AAA: Contains additional, more demanding criteria. W3C does not recommend requiring Level AAA conformance across an entire website as a general policy.
When an organisation selects Level AA as its target, it must satisfy the applicable Level A and Level AA success criteria across complete web pages and relevant user journeys. A website does not become WCAG-conformant simply because its homepage passes an automated accessibility scan.
WCAG 2.2 adds nine success criteria compared with WCAG 2.1. Several address issues that are particularly relevant to modern interfaces, including visible focus, target size, dragging movements, redundant data entry, and accessible authentication. Existing WCAG 2.1 criteria remain relevant; WCAG 2.2 extends the earlier guidelines rather than replacing them with an entirely different framework.
For developers, the practical approach is to use the official WCAG 2.2 Quick Reference during implementation and testing, while confirming which version and conformance level apply to the particular project.
Which accessibility laws apply to businesses in Canada?
There is no single rule that makes WCAG 2.2 Level AA a universal legal requirement for every website in Canada. Accessibility obligations depend on factors such as the organisation's jurisdiction, sector, size, services, and applicable regulations.
That distinction matters when a company operates across provincial borders or supplies digital services to a government department. A technical target selected by a development team should not be confused with a legal determination.
Ontario: AODA website requirements
Ontario's Accessibility for Ontarians with Disabilities Act (AODA) and its Integrated Accessibility Standards Regulation establish website accessibility requirements for covered organisations. Under the Information and Communications Standards, designated public-sector organisations and private or non-profit organisations with 50 or more employees are generally required to make their public websites and applicable web content conform to WCAG 2.0 Level AA, subject to the regulation's stated exceptions.
Ontario's requirements are not identical to the latest WCAG publication. Businesses should consult the province's official website accessibility guidance to determine the obligations applicable to their organisation and content.
Federal organisations and federally regulated businesses
The Accessible Canada Act establishes a framework for identifying, removing, and preventing accessibility barriers in areas under federal jurisdiction. Its reach includes federal departments and agencies, Crown corporations, and certain federally regulated private-sector organisations, including businesses in banking, transportation, broadcasting, and telecommunications.
Federal digital accessibility requirements have also been developing through amendments to the Accessible Canada Regulations. The federal government's published implementation guidance sets out phased requirements for web pages, mobile applications, digital documents, and accessibility statements, with different dates and obligations for different categories of organisation.
For example, the amended federal digital technology rules specify that covered new and updated web pages must follow the applicable digital standard beginning December 5, 2027, for federal public-sector organisations and December 5, 2028, for large businesses. The precise scope and timing depend on the applicable regulatory category and exceptions. Consult the Government of Canada's digital accessibility regulation summary for the current requirements.
Other provinces and territories
Accessibility legislation and obligations differ across Canada. A requirement that applies to an Ontario organisation should not automatically be assumed to apply in the same way to a business operating in Alberta, British Columbia, Quebec, or another jurisdiction. Procurement terms, contracts, human rights obligations, and sector-specific regulations may also affect a website project.
Public-sector projects deserve particular care. A municipality, provincial agency, or federal department may specify an accessibility standard in its procurement documents even when the supplier's own legal obligations are different.
For organisations with complex operations, obtain legal advice when necessary. The development team can implement and test technical requirements, but it should not promise legal compliance based solely on an accessibility scan.
The accessibility problems worth fixing first
Accessibility audits can produce long reports, but the most useful starting point is to identify barriers that prevent people from completing important tasks. A customer who cannot submit an application faces a more immediate problem than someone encountering a minor inconsistency in a decorative element.
1. Make every important action work with a keyboard
Some people cannot use a mouse or touchscreen with precision. They navigate with a keyboard, switch device, or other input method instead.
Test whether a visitor can move through navigation, open menus, select form fields, operate dialogs, dismiss notices, and submit forms without using a mouse. Keyboard focus should move in a logical order, remain visible, and never become trapped inside an interface component without a way to escape.
Custom dropdowns, modal windows, sliders, and date pickers deserve special attention. A control may look correct while remaining unusable for keyboard-only visitors.
2. Use sufficient colour contrast
Low contrast makes text difficult to read for people with low vision or colour-vision deficiencies and can affect users viewing a screen in bright conditions. Small text in pale grey, white text over a photograph, and lightly coloured placeholder text are common examples.
For WCAG 2.2 Level AA, the general minimum contrast ratio is 4.5:1 for normal text and 3:1 for large text, subject to the standard's exceptions. Certain user-interface components and graphical objects have their own contrast requirements.
Do not rely on colour alone to communicate meaning. An error field should have a clear message or other identifiable indication, not just a red border. Similarly, links within paragraphs should remain distinguishable from surrounding text through more than colour where required by the applicable criteria.
3. Give images and icons meaningful alternatives
Alternative text allows assistive technology to communicate the purpose of meaningful images. A photograph illustrating a service may need a concise description, while a decorative background image generally does not need to be announced.
Context matters. If an image links to a product, the alternative text should communicate the link's purpose rather than simply describe the photograph. An icon-only search button needs an accessible name that tells users what the control does.
WordPress site owners should review image fields, custom blocks, reusable templates, and content publishing workflows. A developer can build accessible components, but editors must still supply appropriate alternative text for newly uploaded images.
4. Build forms that explain what went wrong
Forms often combine several accessibility problems: labels that disappear when users type, instructions that appear only as placeholder text, errors that are announced poorly, and required fields that are not identified clearly.
Use programmatically associated labels, explain required information, identify errors in text, and tell users how to correct them. When a submission fails, preserve the information already entered where possible and make the error message available to assistive technology.
For multi-step forms, booking systems, and checkout processes, test the complete journey. A single inaccessible field can prevent the entire transaction from being completed.
5. Keep headings and navigation meaningful
Use headings to communicate the structure of a page, not simply to control font size. A logical heading hierarchy helps screen-reader users understand the content and jump to relevant sections. Navigation labels should also be consistent, and repeated components should behave predictably across the site.
Descriptive link text is equally important. A collection of links labelled 'Read more' gives little context when a screen-reader user navigates through links independently. Labels such as 'View the municipal permit application requirements' communicate a more useful destination.
6. Make mobile interactions practical
A responsive layout is not automatically accessible. Buttons may become too small to activate accurately, sticky headers may obscure keyboard focus, and a menu that works with touch may fail with a keyboard or voice-control software.
WCAG 2.2 includes a minimum target-size criterion at Level AA, with defined exceptions. Its focus-related criteria also address situations where a focused component may be obscured by other content. Test the interface at different viewport sizes rather than assuming that a desktop accessibility review covers the mobile experience.
WCAG 2.2 features that deserve specific attention
When updating a website previously assessed against WCAG 2.1, review the newer criteria deliberately. Some improvements require changes to shared components or authentication workflows rather than a simple adjustment to page styling.
Focus Not Obscured (Minimum), 2.4.11: A focused component must not be entirely hidden by author-created content. Sticky navigation and floating banners should not cover the keyboard focus indicator completely.
Dragging Movements, 2.5.7: Functionality that requires dragging should have a single-pointer alternative that does not require dragging, unless an exception applies. For example, a sortable interface may offer buttons to move an item up or down.
Target Size (Minimum), 2.5.8: Pointer targets generally need to meet the specified minimum size or spacing conditions, subject to the criterion's exceptions. Tiny icon controls can create difficulties for people with limited dexterity.
Redundant Entry, 3.3.7: Information already entered by a user during the same process should not generally need to be entered again, unless the standard's exceptions apply. A checkout should avoid asking customers to retype information unnecessarily.
Accessible Authentication (Minimum), 3.3.8: Authentication should not require users to solve a cognitive function test, such as remembering or transcribing information, unless an allowed exception applies. Password managers, copy-and-paste support, and alternative authentication methods can help.
These are examples rather than a complete compliance checklist. The full standard contains additional criteria, and successful conformance depends on the complete set applicable to the selected level.
How to audit an existing business website
A useful audit combines automated checks, manual testing, and evaluation by people who use assistive technologies. Each method reveals different problems.
Start with the pages that matter commercially
List the main tasks visitors need to complete. For a small business, that may include finding service information, requesting a quote, and submitting a contact form. An online store should also assess product selection, account access, cart management, payment, and order confirmation. A public agency may need to review applications, service requests, document downloads, and information about public meetings.
Include representative page templates, not just individual URLs. A problem in a shared header or form component may affect dozens of pages. Conversely, a page containing a complex interactive tool may need additional testing beyond the standard templates.
Use automated tools for an initial pass
Automated accessibility tools can identify many issues, including missing accessible names, some contrast failures, invalid ARIA attributes, and certain structural problems. They are useful for establishing a baseline and catching regressions during development.
They cannot reliably determine whether every image has meaningful alternative text, whether instructions make sense, whether a keyboard journey is usable, or whether a screen reader communicates the right information in context. A report showing zero automated violations is not proof of WCAG conformance.
Test manually with a keyboard and assistive technology
Navigate the website using only the keyboard. Check focus order, visible focus, menus, dialogs, error handling, and the ability to reach and operate all important controls. Then test representative pages using screen-reader software and browsers relevant to the audience.
Where possible, include people with disabilities in usability testing. They can reveal barriers that are difficult to anticipate from code inspection alone. Testing should be conducted respectfully, with clear tasks and appropriate compensation when recruiting participants for formal research.
Record findings and retest after changes
Each finding should identify the affected page or component, the barrier, the applicable success criterion where relevant, the severity or user impact, and the proposed fix. After remediation, retest the affected workflow rather than assuming that changing the reported element resolves the entire issue.
For ongoing technical reviews, accessible website design and development should incorporate semantic HTML, predictable interaction patterns, responsive layouts, and testing into the normal delivery process. Accessibility is easier to maintain when it is part of the design system rather than a separate repair project.
Accessibility must continue after launch
A website can become less accessible after a redesign, a plugin update, the addition of a marketing popup, or the publication of a new PDF. A shared navigation component may be accessible today and broken after a third-party update next month.
Assign responsibility for reviewing new templates, checking content, and testing significant changes. Development teams should include accessibility checks in quality assurance and regression testing. Content teams need guidance on headings, link labels, alternative text, captions, and document accessibility.
Organisations using WordPress should examine the accessibility of their themes, page-builder widgets, forms, navigation components, and third-party plugins. A plugin's accessibility statement or a theme's marketing claims should not substitute for testing the actual implementation. Custom components may require additional development work to expose names, roles, states, and keyboard behaviour correctly.
When a website undergoes a substantial redesign, consider reviewing its information architecture and interaction patterns before development begins. A new design that repeats the same inaccessible workflow will not solve the underlying problem.
Accessibility, search visibility, and customer experience
Accessibility and search engine optimisation are different disciplines, but they often benefit from some of the same implementation practices. Descriptive headings, meaningful link text, useful image alternatives, clear navigation, and well-structured HTML can make content easier to understand for both visitors and search systems.
That does not mean WCAG conformance automatically improves rankings or guarantees more traffic. Search visibility depends on many factors, and accessibility criteria should be addressed because they support access and usability, not as a shortcut to SEO performance.
Likewise, a visually attractive website is not necessarily easy to use. Visitors may struggle with a booking form, lose their place when a modal opens, or encounter unclear instructions despite the quality of the visual design. The principles discussed in this guide to UX and UI design for Canadian businesses are relevant when reviewing how accessible interactions fit into the wider user experience.
Organisations can also align accessibility work with a broader technical SEO and performance review, provided each discipline is evaluated against its own requirements. Accessibility testing, performance testing, and search optimisation should complement one another without being treated as interchangeable.
What public-sector organisations should add to their review
Public-sector websites often provide information and services that people cannot easily obtain elsewhere. An inaccessible permit application, benefit form, public notice, or meeting document may create a greater practical barrier than an inaccessible marketing page.
Start by identifying the services that citizens depend on and the digital tasks needed to access them. Review application forms, document libraries, public notices, service interruptions, appointment systems, and feedback channels. Include third-party tools and embedded services in the review when they form part of the user journey and fall within the organisation's responsibilities.
Document accessibility matters too. A scanned PDF may be impossible to search or navigate with assistive technology, even when the page hosting it is otherwise well designed. Where documents are published, review their reading order, headings, tags, tables, language settings, and text alternatives. Consider providing accessible HTML when that format is appropriate for the information.
Public organisations should align development and procurement requirements with the standards that actually apply to them. A contract with a vendor should specify deliverables, test expectations, defect remediation, documentation, and ongoing responsibilities. Refer to government and public-sector digital solutions when assessing the broader technical and service-delivery needs of public-facing systems.
A practical starting plan for Canadian businesses
Organisations do not need to rebuild every page immediately to begin improving accessibility. A structured plan can identify major barriers, assign responsibility, and make progress measurable.
Confirm applicable obligations. Identify the organisation's jurisdiction, sector, size, contractual commitments, and relevant accessibility legislation or regulations. Select a technical target that meets the actual requirements and supports a sensible long-term direction.
Map important user journeys. List the pages and tasks that customers, employees, or members of the public must be able to use, including forms, account access, checkout, applications, and document downloads.
Run an initial audit. Combine automated scans with keyboard checks, manual review, and assistive-technology testing. Document barriers and prioritise failures that block important tasks.
Fix shared components first. Address common problems in navigation, forms, buttons, dialogs, headings, and design tokens before repairing the same issue separately on many pages.
Build accessibility into content and development. Establish publishing guidance, code-review expectations, testing procedures, and clear responsibility for new content and functionality.
Retest and maintain. Verify corrections, record remaining issues, and repeat checks when significant updates are made. Keep evidence of the work and communicate limitations accurately.
For a new website, incorporate accessibility acceptance criteria into the original project brief. For an existing website, begin with the most important workflows and a realistic remediation plan. Both approaches are more dependable than relying on a last-minute overlay or a single automated score.
Make accessibility part of your next website project
Website accessibility is not a one-time badge. It is an ongoing engineering and content responsibility that helps people access information and complete tasks with fewer barriers.
WCAG 2.2 offers a practical framework for modern website development, but Canadian organisations should confirm the specific legal and contractual standards that apply to them. Start with the highest-impact barriers, test real user journeys, and maintain accessibility as the website changes.
HB Technology Solutions Ltd helps Canadian businesses and organisations plan and develop websites with attention to responsive design, maintainability, and user experience. If you are planning a new website or reviewing an existing one, request a free project proposal to discuss your development requirements and accessibility priorities.
Note: This article provides general technical information, not legal advice. Accessibility obligations and implementation deadlines may change; confirm current requirements with the relevant regulator or qualified legal counsel.
