A practical guide to website accessibility.

You’re halfway through a form when you enlarge the text and the button you need disappears. Someone using a keyboard might get stuck at the same point for a different reason, while a screen reader might read the fields without saying what they’re for. Website accessibility is about making sure people can finish what they came to do in each of those situations.

On an association, regulator, charity, or public-facing website, getting stuck can mean missing a renewal, a program registration, or an application for support. Putting the service online is only the first step towards making it available.

This guide explains common barriers, how WCAG and Canadian accessibility requirements apply, and what to expect from the people designing, building, testing, and maintaining your website.

What website accessibility means

People encounter barriers for many reasons, including differences in vision, hearing, mobility, speech, learning, memory, and concentration. Many of these needs are invisible, so it’s easy to miss them if you judge the website only by how your team uses it.

The 2022 Canadian Survey on Disability gives a sense of how broad that audience is. Among Canadians aged 15 and older, 27% reported disabilities that limit their daily activities.¹

Consider someone who increases the text size on their phone as they get older. They may never describe themselves as having a disability, but if the larger text is clipped or pushes a button out of reach, the design has created a barrier. That’s one way age-related changes in vision, dexterity, and cognition can overlap with the needs addressed by web accessibility.²

The same principle applies when someone relies on a screen reader, voice commands, switch controls, or a keyboard. Some people use these tools every day, and others may need them temporarily after an injury.

Access means being able to complete the task.

To see where a barrier matters, follow the task from start to finish. Someone who finds an application page still needs to understand the requirements, gather documents, complete the form, correct any errors, and know that the application was received.

When one of those steps fails, the person may have to ask for help or abandon the task. They may also need to disclose personal information to someone assisting them. Independent access matters because it gives people more control over how and when they use a service.

Alternative help matters, but does not excuse online barriers. GOV.UK’s service standard recommends considering online and offline steps and the support needed between them.³

Accessibility, usability, and compliance

Accessibility, usability, and compliance ask different questions about the same website. Accessibility looks at disability-related barriers, usability considers how easily people can use the service, and compliance checks whether the organization is meeting its obligations.

A form can satisfy technical requirements and still be exhausting to complete. A site can feel straightforward to its project team while excluding people who use different technology. The strongest approach combines a clear standard with attention to the experience of the people using the service.

Where WCAG fits

The Web Content Accessibility Guidelines (WCAG), developed through the World Wide Web Consortium (W3C), turn accessibility intentions into shared requirements teams can evaluate.⁴

That shared reference helps when a project moves between teams. If the brief says “make the text readable,” a designer, developer, and evaluator may each interpret it differently. A contrast requirement gives them something specific to check while they work out what readers need.

WCAG’s four principles address perceivable information, operable interfaces, understandable interactions, and compatibility with browsers and assistive technology. Captions, keyboard access, and identified controls put them into practice.

What an organization needs to specify

A project should name a WCAG version and level. WCAG 2.2 Level AA is a sensible target for a new website, alongside confirmation of the legal and contractual requirements that apply. Some laws still refer to WCAG 2.0 or 2.1, so a project target and a legal requirement are not always the same thing.

The levels are cumulative: AA includes A requirements, and AAA adds more. A higher level is not a simple quality rating for an entire website. W3C does not recommend requiring full AAA conformance as a general policy for whole sites because some content cannot meet every AAA criterion.⁵

The numbered success criteria below identify selected requirements. Your project team should explain how they apply to your services.

Designing content people can see and adapt

Colour contrast: assess combinations, not colours.

How you pair brand colours matters as much as the colours themselves. A pale blue that works well behind dark text may be hard to read as a small label on white. A colour that passes for a large heading might need a darker variation for the navigation.

That gives you room to work with the existing palette during a redesign. A colour that falls short for text can still be useful as a background or decorative accent.

WCAG’s Contrast (Minimum), criterion 1.4.3, requires at least 4.5:1 for most text and 3:1 for text meeting its large-text definition. Those thresholds provide a more dependable measure than judging a colour combination on one person’s monitor.⁶

Controls and meaningful graphics need visible identifying information, generally at least 3:1 against adjacent colours. A faint field outline may be essential; a decorative border may not be.⁷

A useful digital brand guide records approved pairings for specific uses. It should include what happens when a button is selected, a link receives keyboard focus, or a form displays an error. Editors then have practical choices they can trust, rather than a palette they have to reinterpret whenever they create a page.

The cards show how the same background can pass with one text colour and fail with another. Teal, for example, works with navy or white at the WCAG AA threshold for large text. Both pairings fall short for normal text.

The surrounding design matters as well. Text over a photograph can be clear in one crop and disappear into a lighter area on a phone. Small, thin text can remain uncomfortable even when its colours meet a minimum. The U.S. Web Design System’s guidance on colour makes this wider point: readability also depends on typography, spacing, line length, and the content itself.⁸

Check small instructions, dates, captions, navigation, and labels alongside large headings. Quiet details often contain essential information.

Colour cannot carry the whole message.

A colour can be easy to see and still be hard to interpret. Contrast helps someone see a status indicator, for example, but the indicator’s colour alone may leave them guessing what the status means.

A chart can have strong contrast and still be difficult to interpret if its categories are identified only as red, green, and blue. A form can display an obvious red outline without explaining which detail needs correcting. In each case, making the colours stronger would leave the underlying problem unresolved.

The practical answer is to give the information another clear form. A status can say “Approved” or “Action required”. A chart can label its series directly or use patterns alongside colour. An error can explain what needs attention beside the affected field. These approaches support people who perceive colour differently and reduce the amount of interpretation expected of everyone else.¹⁰

WCAG’s Use of Color, criterion 1.4.1, permits colour to reinforce meaning, without carrying it alone. “Select ‘Continue’” is more dependable than “Select the green button”.

Larger text and layouts that adapt

Responsive design must accommodate enlarged text and pages alongside smaller screens. A phone layout that works at default settings may fail when someone increases text size.

On a phone with enlarged text, you’ll see fewer words at once. The page should make room for those larger words by moving content down, so the same instructions and actions stay within reach.

The problems are often small but consequential: a heading overlaps the next paragraph, an eligibility condition disappears inside a fixed-height box, or the final button moves out of reach. A screenshot at the default size will not reveal these problems. An enlarged view of a real page will.

WCAG addresses text resizing to 200% without losing content or functionality (1.4.4) and ordinary content reflow in a narrow area (1.4.10). These related checks help people read without repeatedly scrolling across each line.¹¹

People may adjust spacing or need a fixed orientation. A wheelchair-mounted tablet may be impossible to turn sideways. Include these conditions in design.¹²

Headings and links that help people find their way

When readers scan a page, headings, familiar terms, and descriptive links tell them where to look next.

Someone reviewing an application process might want to find eligibility, fees, deadlines, and required documents. Those topics make useful headings because they reflect the reader’s questions. A series of sections labelled “More information” requires much more exploration.

Code headings as headings so screen readers can navigate them. Larger, bolder text alone cannot supply that structure. Make the correct hierarchy straightforward for editors.¹³

“Download the membership application” is more informative than “Click here,” especially when a screen reader presents links without surrounding text.¹⁴

Review hierarchy and labels before migration. Successfully moving pages does not automatically make them easier to navigate.

Images need a purpose and an alternative.

Ask what readers would miss without an image: its explanation, context, or contribution to the story.

Alternative text, or alt text, conveys what a reader would otherwise miss. The same image can need a different description depending on the page.

A photograph of a building might introduce a news story. On a visitor information page, the same photograph might show which entrance has a ramp. The useful description changes with the purpose. Harvard’s alt text guidance includes examples of this contextual approach.¹⁵

Decorative images or those repeating nearby information usually need an empty alternative. Linked images need their action or destination communicated. W3C’s alt text decision tree helps distinguish these uses.¹⁶

Charts and diagrams need more care. “Funding chart” tells someone that a chart exists, but not what it shows. Explain the important conclusion in the page text and make the underlying information available in a suitable format, such as an accessible table. That explanation also helps readers who can see the graphic but find it difficult to interpret.¹⁷

Making navigation and interactions work

People need more than one way to navigate.

Support keyboards, voice commands, touch, and alternative inputs. Avoid requiring precise movements or a particular device when the task itself does not depend on them.

Try completing a task with just the keyboard. You might be able to open the menu, choose a search filter, and fill in your details, then get stuck at a date picker that requires a mouse.

They also need to know where they are. Keyboard focus is the current location for interaction, often shown by an outline around a link, button, or field. If that indicator disappears, the person can be left guessing what will happen next. If a dialogue opens, they need a clear way to close it and continue.¹⁸

WCAG’s Keyboard criterion, 2.1.1, expects keyboard operation with limited exceptions. Ask for a complete demonstration, including menus, pop-ups, and third-party steps.

What a screen reader needs from a website

Screen readers support navigation between headings, links, and form controls, alongside reading aloud. Apple’s VoiceOver documentation demonstrates these methods.¹⁹

A menu must identify itself and announce whether it is open. Checkboxes must communicate their state. Visual position and appearance cannot replace information assistive software can understand.²⁰

Together, those details help someone understand where they are, which options they can choose, and what happened after they acted.

Touch targets, dragging, and voice control

Small, crowded controls ask a lot of the person using them. A row of tiny icons might look tidy, but selecting the right one can be difficult for someone with a tremor or limited dexterity. A larger area that responds to a tap gives them more room to act accurately.

Giving controls more room matters most when a missed tap can erase work, remove an item, or book the wrong appointment.

WCAG’s Target Size (Minimum), criterion 2.5.8, sets size and spacing benchmarks. Frequently used controls may benefit from more generous sizing.²¹

Provide a non-dragging pointer alternative, such as buttons, for actions that otherwise require holding and moving an item.²²

Voice-control names should match visible wording: “Click Apply now” should activate “Apply now”. Speech-recognition testing can reveal mismatches mouse testing misses.²³

Forms should help people succeed.

Every form field asks someone to interpret a question, find the information, and decide what to enter. The more of that work you can explain up front, the easier it is for people to complete the form on their own.

Use persistent labels, examples for unfamiliar formats, and early notice of required documents. Instructions that disappear when typing starts provide less help.²⁴

“Enter a postal code in the format A1A 1A1” explains how to correct the problem. “Invalid input” leaves people guessing. GOV.UK’s guidance on error messages recommends plain explanations and corrections.²⁵

WCAG’s Error Identification, criterion 3.3.1, requires errors to be described in text. Make messages findable and connect them to affected fields, including for assistive technology.²⁶

Preserve valid answers after errors. For consequential actions, review or confirmation steps help people catch incorrect amounts and unintended choices before submitting.²⁷

Communicate success to assistive technology when it appears without navigation. “Your application has been received” resolves uncertainty a green tick may leave.²⁸

Logins should not become an unexpected barrier.

Organizations sometimes put considerable care into their public website and much less scrutiny into the account system behind it. Yet a member who cannot sign in still cannot renew, register, or access the information they need.

Start with the ways people already sign in and recover their accounts. Try a password manager, paste a verification code, and see whether a security challenge requires someone to remember or transcribe information.

Accessible Authentication (Minimum), criterion 3.3.8, addresses cognitive barriers and assistance or alternatives. Passwords and MFA remain possible, with care over how people complete them.²⁹

Let people reuse earlier answers where appropriate. WCAG’s redundant-entry requirement includes exceptions for security and information no longer valid.³⁰

Give people control over motion and time.

If a banner rotates while someone is reading, they may lose their place before they finish. Scroll-triggered animation can make some people feel unwell, and a time limit can interrupt someone still working through instructions. A team that knows the page by heart can miss all three in a quick review.

Ask what motion contributes. Preserve meaning with reduced movement, provide appropriate pause controls, and observe WCAG’s requirements for automatically moving content and flashing.³¹

Respecting a person’s reduced-motion preference gives them control without requiring a separate setting on every website. Some motion-related recommendations go beyond Level AA, but can still be appropriate for the audience.³²

Security timeouts need appropriate warnings, extension opportunities, and treatment of unsaved work. Slower reading should not repeatedly erase progress. WCAG’s Timing Adjustable requirement addresses many situations, with defined exceptions.³³

Making information easier to understand and access

Plain language is part of accessibility.

Plain writing helps readers distinguish requirements from recommendations, understand deadlines, and prepare the right documents.

Plain language preserves useful detail in a form readers can act on. The Canada.ca Content Style Guide connects it to finding, understanding, and using information.³⁴

For example, “Upload proof of your address, such as a utility bill dated within the last three months” gives someone enough information to choose a file. “Submit supporting documentation” leaves that decision to guesswork.

Keep instructions, action names, and information placement predictable. Canada’s Digital Accessibility Toolkit recommends manageable information and support for difficulties with recall and time pressure.³⁵

Correctly coded headings can still introduce confusing content. Review explanations with the people who need them.

Audio and video need equivalent ways to understand them.

A video can be an effective way to explain a process or tell a story, but people need access to the information it carries. Someone who cannot hear the soundtrack needs the relevant speech and sounds in another form. Someone who cannot see the picture needs important visual information explained.

The right alternative depends on what the audience needs. Captions carry speech and relevant sounds while the video plays, a transcript puts that information in a separate text format, and audio description explains important visuals the soundtrack leaves out.³⁶

Review automatic captions for names, missing words, timing, speakers, and meaningful sounds. Availability alone does not establish quality; the Captioning Key provides guidance.³⁷

WCAG’s Captions (Prerecorded), criterion 1.2.2, establishes a requirement behind this work. Include accessible versions in the video brief and budget so they are planned before the final edit.³⁸

Explain on-screen charts in the soundtrack. “As you can see here” leaves someone who cannot see without the information.³⁹

Provide text alternatives and usable controls for standalone audio. A screen-reader demonstration needs a transcript covering speech and relevant actions, giving its audience the access it illustrates.⁴⁰

Documents and third-party services are part of the website experience.

If your application, policy, report, or schedule lives in a download, the reader needs to use the file as easily as the page that links to it.

Selectable PDF text does not establish accessibility. Reading order, headings, descriptions, tables, and fields need attention. Scans need more than text recognition; accessible PDF resources cover production and testing.⁴¹

Consider a web page for information mainly read online. It can adapt to screens and reading preferences. Keep downloads where they serve a purpose.

Someone navigating a table cell by cell needs to know which heading belongs to each value. Preserve those relationships when moving spreadsheet information into reports or pages.⁴²

Registration tools, payment forms, and member portals can determine the whole journey’s accessibility. Seek demonstrations, product assessments, and accessibility reports. A supplier’s general commitment cannot establish how the chosen service works.⁴³

How to evaluate accessibility meaningfully

Good testing follows people through a task so you can see where they get stuck and what to fix. A score can point you towards some of those problems.

Automated tools detect some missing labels and contrast failures, but cannot reliably judge alt text, heading meaning, or confusing form recovery. Passing their checks leaves important questions unanswered.⁴⁴

Combine automated checks with manual evaluation and assistive-technology testing. GOV.UK’s accessibility testing guidance describes this approach. Each method reveals different problems; one tool leaves gaps.⁴⁵

Test expanded menus, failed submissions, empty searches, and signed-in pages. A working homepage cannot establish that someone can finish an application or payment.

People with disabilities can reveal difficulties the team misses. Their feedback complements standards-based testing; a small group cannot represent every need or establish conformance alone.⁴⁶

What to expect in a website proposal

A proposal should name the standard, included work, testing, and responsibility for findings. “The website will be accessible” gives buyers too little to assess.

Useful questions include:

• Does the work include existing content, documents, forms, and third-party services?
• How will important tasks be tested, including use without a mouse?
• What evidence will show which barriers were found and corrected?
• Who is responsible for unresolved issues, and when will they be addressed?
• What will the publishing team need to know to maintain accessibility?

Harvard’s accessibility questions for vendors offer a useful reference for these conversations, including documentation, demonstrations, and plans for improvement.⁴⁷

Specify independent specialist assessment in scope and budget where appropriate. Routine checks and formal conformance evaluations differ. Reports should state scope, findings, and limitations.⁴⁸

A scanner’s “98%” score tells you how the page did on the checks it ran. Someone who completes every field and gets stuck at Submit still can’t finish the form.

Where WordPress fits

WordPress provides headings, image alternatives, captions, and reusable layouts. A carefully configured editor supports consistent choices without requiring code knowledge.

The WordPress project targets WCAG 2.2 AA in its accessibility standards, while acknowledging known issues. An “accessibility-ready” theme has passed a defined theme review; it is not a certification of the completed website. Themes, plugins, custom features, and content decisions all affect the result.⁴⁹

Include editorial tasks in platform selection. Staff need accessible tools to maintain the website too.

Our guide to WordPress for mission-driven organizations explores that broader publishing context. The accessibility principle is the same on any platform: assess the website and workflows people will actually use.

Canadian accessibility requirements

There is no single website rule that applies identically to every Canadian organization. Jurisdiction, sector, organizational size, content, and timing can affect the requirements. A project may also have contractual obligations beyond the legislation’s minimum.

The following is a high-level orientation, not an exhaustive legal review or legal advice. Confirm the requirements that apply to your organization, including obligations outside website-specific regulations. Legal information last reviewed: November 2026.

Federal requirements

Amendments to the Accessible Canada Regulations introduce digital accessibility requirements for federal public-sector organizations and federally regulated private-sector organizations with at least 100 employees. They reference CAN/ASC–EN 301 549, a broader information and communication technology standard, rather than a simple requirement that every Canadian website meet WCAG 2.2.

Requirements for new or updated web pages begin on December 5, 2027 for covered federal public-sector organizations and December 5, 2028 for covered private-sector organizations. Other provisions address training, documents, mobile applications, procurement, and accessibility statements, with scope and dates that vary. Check the federal summary and the regulations for the relevant organization and deliverable.⁵⁰

Ontario

Ontario’s website requirements under the Accessibility for Ontarians with Disabilities Act generally cover designated public-sector organizations and businesses and non-profits with 50 or more employees. Covered public websites and web content published after January 1, 2012 must meet WCAG 2.0 Level AA, with exceptions including live captions and prerecorded audio description. Separate provisions apply to the Ontario government and Legislative Assembly. Scope, control of content, and practicability provisions need to be considered.⁵¹

Manitoba

Manitoba’s Accessible Information and Communication Standard Regulation uses WCAG 2.1 Level AA. Its web-content requirement covers content published after the regulation applies to an organization and content needed to access its goods and services. Web applications have related requirements for publication and significant updates. The regulation sets out the covered organizations, phase-in dates, and exceptions, including provisions concerning technical feasibility, control, and undue hardship.⁵²

Quebec

Quebec’s SGQRI 008 3.0 standard applies to specified public bodies. It draws on WCAG 2.1 A and AA with stated exceptions, adds selected AAA criteria, and includes selected WCAG 2.2 requirements. It also contains requirements for accessibility information and assistance. Describing it simply as “WCAG 2.1 AA” misses important details, and it should not be presented as a blanket rule for every Quebec business.⁵³

British Columbia and other jurisdictions

The Accessible B.C. Act and its regulation require covered public-sector organizations to establish accessibility committees, plans, and public feedback mechanisms. Those requirements should not be confused with a province-wide WCAG mandate for every business website.⁵⁴

Other provinces and territories have their own legal and policy contexts. Review current requirements when planning a project and revisit them as standards develop. The absence of a particular website regulation is not a useful reason to leave a known barrier unresolved.

Why overlays are not a substitute for accessibility.

Overlays promise a quicker way to improve a website by adding a toolbar, changing pages as they load, or combining the two. How much they help depends on which barriers they can address.

Automation may fix a missing label while failing to choose a meaningful one. It cannot reliably assess image descriptions, instructions, or complex processes. The practitioner-supported Overlay Fact Sheet recommends correcting barriers at their source.⁵⁵

Visitors may have their assistive technology configured already. Overlay controls can duplicate or interfere with it. Perkins School for the Blind’s explanation of overlays describes that risk. The European Disability Forum and the International Association of Accessibility Professionals make a related point in their joint statement on overlay limitations: personalization can help without making the underlying website accessible.⁵⁶

Claims of automatic compliance deserve particular scrutiny. In April 2025, the U.S. Federal Trade Commission finalized an order requiring accessiBe to pay US$1 million to settle allegations involving unsubstantiated claims about its product’s ability to make websites WCAG-compliant. The FTC case record provides a concrete example of why buyers should ask for evidence. It concerns a particular vendor’s claims under American consumer-protection law, rather than a ruling about Canadian accessibility obligations.⁵⁷

We recommend fixing and testing the website. Personalisation and automated tools can help when their results are evaluated. Ask overlay suppliers which barriers remain and how assistive-technology users tested the result. Success means people can use the service.

Keeping accessibility part of everyday website work

New forms, colour changes, uploads, and embedded services can introduce barriers long after launch, so the people publishing and maintaining the site need to know how to spot them.

Agree on responsibilities for design, development, content, and third-party services. Editors need practical publishing guidance, and technical changes need someone responsible for testing their effect on accessibility.

Tested layouts and forms reduce editorial guesswork. Train with the organization’s own content and provide a route to specialist help.

Record each barrier, its impact, who is responsible, and the planned correction. Prioritize blocked essential tasks. Explain temporary workarounds and the plan to resolve the cause.

Keep an honest, current accessibility statement covering the standard, evaluated scope, limitations, and help or feedback routes. W3C’s accessibility statement guidance offers a starting point.⁵⁸

Start with a task that matters to your visitors. Follow it from the instructions through to confirmation, including what happens if someone makes a mistake. Then use a standards-based assessment to check for barriers that a single walkthrough might miss. Revisit both as your website and the needs of your audience change.