Website Accessibility Standards Explained

Most small business owners find out their website is inaccessible the same way: a customer emails to say they could not complete the contact form, or a compliance letter arrives, or a competitor quietly starts winning the contracts that require an accessibility statement. By that point the fix is a rebuild rather than an adjustment.

The uncomfortable part is that this is not a fringe problem. It is the norm. And unlike most website issues, accessibility carries legal weight in Canada, affects your search visibility, and shapes whether roughly one in five potential customers can use your site at all.

How bad the problem actually is

The scale is not a matter of opinion. WebAIM analyses the home pages of the top one million websites every year using automated testing, and the 2026 results, published from February 2026 data, are blunt. The overwhelming majority of the most influential pages on the web fail basic accessibility checks that a machine can detect without human judgement.

Read those numbers carefully, because the detail matters. These are only the failures a machine can spot. WebAIM is explicit that automated tools cannot detect every conformance failure, which means the true rate of full Level AA conformance is lower still. Their analysis puts it below 4.1%.

The trend is also going the wrong way. Errors per page rose more than ten percent year over year, and the failure rate increased after six consecutive years of small improvements. Sites are getting more complex faster than they are getting more accessible.

What the law requires in Canada

Canadian accessibility obligations come from two directions: federal and provincial. Which applies to you depends on your sector, your size, and where you operate. Neither framework invents its own technical rules. Both point back to WCAG, which is why WCAG is the practical target regardless of jurisdiction.

Federally, the Accessible Canada Act sets a framework for identifying and removing barriers in areas under federal jurisdiction, with information and communication technologies explicitly included. The Government of Canada publishes guidance and regulatory detail at accessible.canada.ca.

Provincially, Ontario is the most developed example. The Integrated Accessibility Standards Regulation under the AODA sets out information and communications requirements, including web content obligations, and the regulation text is published in full at Ontario Regulation 191/11. Other provinces including Manitoba, Nova Scotia and British Columbia have their own accessibility legislation at varying stages of implementation.

There is a commercial dimension too, and it is often the one that moves the needle. Public sector procurement, grant applications and enterprise vendor reviews increasingly ask for an accessibility statement or a conformance claim. A small business that cannot answer that question is quietly excluded from bids it never sees.

WCAG explained without the jargon

WCAG stands for Web Content Accessibility Guidelines. It is maintained by the World Wide Web Consortium and organised around four principles: content must be perceivable, operable, understandable and robust. Each principle contains success criteria at three conformance levels: A, AA and AAA. The full specification is published at w3.org/TR/WCAG22.

Level A is the floor. Level AA is what regulations and contracts almost always reference. Level AAA is aspirational and not expected across an entire site. For a small business website, Level AA is the target, and it is entirely achievable without a specialist rebuild.

The four failures that cause most problems

Accessibility sounds enormous until you look at where the failures actually cluster. WebAIM’s data shows a small number of issues account for the overwhelming majority of detected errors. Fix these four and you eliminate most of your exposure, usually in days rather than months.

1. Low contrast text. Found on 83.9% of home pages. This is grey text on white, light text on pale photographs, and brand colours used for body copy without checking the ratio. WCAG AA requires a contrast ratio of at least 4.5 to 1 for normal text. Free contrast checkers give you the number in seconds.

2. Missing alternative text on images. A screen reader announces an image by reading its alt attribute. With no alt text, the user hears the filename or nothing at all. Every image that carries meaning needs a short, factual description. Decorative images should carry an empty alt attribute so screen readers skip them.

3. Unlabelled form inputs. A field with placeholder text but no programmatic label is invisible to assistive technology. This is the failure that most directly costs money, because it breaks the contact form, the quote request and the checkout. If your forms are not labelled, some visitors literally cannot buy from you.

4. Empty links and buttons. Icon-only buttons with no accessible name announce as “link” or “button” and nothing else. Social icons, hamburger menus and search toggles are the usual culprits. An aria-label attribute solves it in one line.

“Accessibility failures are rarely exotic. They are grey text, unnamed buttons and forms nobody labelled. The fixes are boring, which is exactly why they get skipped.”

Why accessibility and SEO are the same job

Search engines and screen readers consume a page the same way: as structured text, without seeing the design. Every change that helps assistive technology understand your page also helps a crawler understand it. This is the most underused argument for accessibility work, and it turns a compliance cost into a growth investment.

Alt text gives search engines context for images. Proper heading hierarchy tells both a crawler and a screen reader how the page is organised. Descriptive link text outperforms “click here” for users and for ranking signals alike. Semantic HTML is what allows featured snippets to be extracted at all.

The same logic extends to how AI answer engines read your content, which we covered in our guide to answer engine optimization. Machines that cannot parse your structure cannot quote you, and increasingly, being quoted is the traffic.

If you are working through broader search improvements at the same time, our SEO guide for small business websites covers the structural side in more depth.

How to audit your own site in an afternoon

You do not need a consultant for a first pass. You need a browser, a free tool and about three hours. The goal is not a perfect report. The goal is a prioritised list of what is broken, so you know whether you are facing a tidy-up or a rebuild.

1. Run an automated scan on your five most important pages. Home, services, pricing, contact and your best-performing blog post. Free browser extensions such as WAVE or the built-in Lighthouse accessibility audit in Chrome will do this.
2. Unplug your mouse. Navigate the entire site using only the Tab, Shift+Tab and Enter keys. If you cannot reach the navigation, open the menu, complete the contact form and submit it, you have a Level A failure.
3. Watch the focus indicator. As you Tab, can you always see where you are? Many themes remove the focus outline for aesthetic reasons. That single change makes a site unusable for keyboard users.
4. Check your contrast. Sample your body text, your button text and any text sitting over an image. Anything below 4.5 to 1 fails AA for normal text.
5. Turn on a screen reader for ten minutes. VoiceOver is built into macOS and iOS, Narrator into Windows. Listen to your home page. It is uncomfortable and it is the most useful ten minutes you will spend.
6. Write down every failure with the page it appeared on. A list beats a score, because a list can be assigned and closed.

Fixing things in the right order

Not all failures are equal. Some block a transaction entirely, others are cosmetic annoyances. Fix in order of what stops someone becoming a customer, then work down. This sequencing is what turns an intimidating list into a week of ordinary work.

One caution about redesigns. If your audit turns up structural failures across every template, patching page by page is false economy. That is the moment to look at the underlying build, and our article on the signs a business website needs a redesign covers how to tell the difference between a fixable site and a tired one.

Why accessibility overlays are a trap

You have probably seen the pitch: add one line of JavaScript and your site becomes compliant automatically. Accessibility overlays promise to detect and remediate barriers in real time without touching your code. The appeal is obvious and the reality is more complicated.

Overlays operate on the rendered page after the fact. They cannot reliably infer what an unlabelled button does, what an image means, or how a custom widget should behave. They frequently conflict with the assistive technology a user has already configured, which is why many disability advocates actively recommend against them.

The honest alternative is less glamorous: fix the HTML. It costs more upfront and it stays fixed, which the overlay subscription does not.

Keeping a site accessible over time

Accessibility is not a project with an end date. Every new blog post, product image and landing page is an opportunity to reintroduce the problems you just cleared. Sites regress because publishing is continuous and auditing is occasional.

The practical answer is to build the checks into publishing rather than scheduling them separately. Alt text becomes part of uploading an image. Contrast is checked when a new brand colour is introduced. A quick keyboard pass happens before any new template goes live.

This is the same discipline that keeps a site fast, secure and current, which we set out in our guide to what website maintenance actually involves. Accessibility belongs in that routine, not in a separate annual panic.

“A site does not become inaccessible in one bad decision. It drifts there, one unlabelled image at a time.”

One last point worth making plainly. Roughly one in five people lives with some form of disability. Building for them is not charity and it is not risk management. It is the same argument as building a site that works on mobile: a meaningful share of your market cannot use the alternative.

Where accessibility breaks, page type by page type

Failures are not spread evenly across a website. Different page types fail in different, predictable ways, and knowing the pattern lets you check the right things instead of scanning everything with equal attention. Here is what usually goes wrong where.

The home page fails on contrast and on the hero section. Text placed over a background photograph almost never meets the 4.5 to 1 ratio at every point in the image, because the image is not a flat colour. Sliders and carousels add a second problem: auto-advancing content that a keyboard user cannot pause is an operable failure, not a design preference.

Service and pricing pages fail on structure. Comparison tables built from styled divs rather than real table markup lose all their relationships when read aloud, so a screen reader user hears a stream of disconnected numbers with no idea which plan they belong to. If it looks like a table, it should be a table.

Contact and quote pages fail on forms, and these are the expensive ones. Placeholder text is not a label. Red border colour alone is not an error message. If a required field fails validation and the only signal is a colour change, a colour-blind user or a screen reader user cannot tell what went wrong or how to fix it.

Blog posts fail on headings and images. Writers skip from H2 to H4 because H3 looked too big, which breaks the document outline that screen reader users navigate by. Images get uploaded in a hurry with no alt text. Both are content habits rather than code problems, which means they need a process fix, not a developer.

Linked PDFs are the worst offenders and the most commonly forgotten. A scanned PDF is an image of text, entirely unreadable to assistive technology. If you publish menus, price lists, forms or reports as PDFs, they carry the same obligations as your web pages, and most of them fail outright.

What a screen reader user actually experiences on your site

Most site owners have never heard their own website. The gap between how a page looks and how it sounds is where the empathy for this work comes from, and it is worth ten minutes of discomfort to understand it properly.

A screen reader does not read a page top to bottom the way you would. Experienced users navigate by jumping between headings, links and landmarks, building a mental map first and then diving into the section they want. That behaviour explains why heading hierarchy matters so much. If your page has one H1 and then eleven H2s with no sub-structure, the map is flat and the user has to listen linearly to find anything.

Links are announced out of context too. A user can pull up a list of every link on the page, which is why a page with nine links that all say “read more” is functionally useless. Descriptive link text is not a style preference; it is the difference between a usable index and noise.

Then there is the navigation problem. Without a skip link, every single page visit begins with the same forty seconds of menu items before the content starts. Adding one skip-to-content link at the top of the document removes that tax from every page on your site.

“Nine links that all say read more are not nine links. They are one link repeated nine times, and none of them say where they go.”

Writing an accessibility statement that is actually useful

An accessibility statement is a public page describing how accessible your site is, what standard you are working towards, and how someone can report a problem. It is frequently requested in procurement, and unlike a vendor badge it costs nothing and is entirely within your control.

The instinct is to claim full compliance. Resist it. An honest statement that says you are working towards WCAG 2 Level AA, lists the known gaps, and gives a contact route is more credible and less risky than a blanket claim you cannot substantiate. Overstating conformance is how a good-faith effort turns into a liability.

Four myths worth retiring

Accessibility attracts a particular set of objections, and most of them dissolve on contact with the actual requirements. These four come up in almost every conversation with a small business owner.

“Our customers do not have disabilities.” You cannot know that, because the people who could not use your site did not contact you to explain why. Disability also includes temporary and situational cases: a broken arm, bright sunlight on a phone screen, an ear infection affecting video.

“It will make the site ugly.” Accessible design constrains contrast ratios and focus states. It does not constrain typography, layout, imagery or brand. Plenty of visually striking sites meet Level AA without compromise.

“We will do it in the next redesign.” Redesigns slip, and in the meantime the exposure is live. Contrast and form labels can be fixed this month on the current site for a fraction of the cost of waiting.

“We are too small to be a target.” Size affects which regulations apply, not whether a customer can use your contact form. The commercial cost of a broken form arrives long before any compliance question does.

The third-party problem

Booking widgets, chat bubbles, review carousels, embedded maps and payment forms are usually the least accessible things on a small business website, and they are the parts you did not build. This is a genuine constraint rather than an excuse, but it is not a reason to stop.

Start by auditing what you actually embed. Most sites accumulate widgets over years and keep running them long after anyone used the feature. Removing a broken chat widget nobody answers is both an accessibility improvement and a speed improvement.

For the embeds you need, ask the vendor directly whether they publish a conformance report. Many now do, because their enterprise customers demand it. Where a vendor cannot answer, provide an accessible alternative path: a phone number beside the booking widget, a plain HTML form alongside the embedded one. An alternative route is an accepted approach when a component cannot be fixed directly.

Document these gaps in your accessibility statement rather than hiding them. A known, disclosed limitation with a workaround is a defensible position. An undisclosed one is not.

Testing with actual people

Automated tools and keyboard checks will take you most of the way. The last stretch, and the part that separates a compliant site from a genuinely usable one, only comes from watching real people try to use it. This is cheaper and less formal than it sounds.

You do not need a research panel. Ask two or three people who use assistive technology to attempt one specific task on your site: request a quote, find your phone number, book an appointment. Watch without helping. The places where they pause are the places your automated scan reported as clean.

Recruit through local disability organisations, accessibility consultancies or your own network, and pay people for their time as you would any other tester. Unpaid accessibility feedback is a request for free labour from the group least well served by the industry that created the problem.

What you learn tends to be structural rather than technical. Navigation labels that made sense internally turn out to be jargon. A form that passes every automated check turns out to ask for information in an order nobody expects. These are the findings that improve conversion for every visitor, which is why this step usually pays for itself.

Repeat it after any significant redesign. A site that was tested once and rebuilt twice has not been tested.

Frequently asked questions