The Website Accessibility Checklist for Business Owners

A screen reader user lands on your website. The first thing they hear is "link, link, link, link, link, link, image, image, image, link, link." No headings. No labels. No indication of what your business does or where anything is. They leave in under eight seconds. You never know it happened because your analytics can't track what a screen reader does.

This is happening right now on roughly 96% of websites. WebAIM's 2025 analysis of the top one million home pages found an average of 51 detectable accessibility errors per page. Detectable. The kind an automated tool can catch. The real number is worse.

If you're a business owner, you don't need to understand ARIA attributes or semantic HTML. You need to know whether your site works for the 8 million Canadians with a disability and whether you're exposed to legal risk under the Accessible Canada Act. This checklist gives you that.

Why This Matters More Than You Think

The Accessible Canada Act (ACA), passed in 2019, requires that Canada become barrier-free by 2040. It applies directly to federally regulated organizations, but its influence is spreading fast. British Columbia already has accessibility legislation. Ontario's AODA has been enforceable since 2014. Alberta doesn't have standalone accessibility legislation yet, but the ACA sets the floor, and provincial expectations are rising. Several Alberta municipalities now require WCAG 2.1 AA compliance in their procurement processes.

Beyond legal exposure, the business case is straightforward. People with disabilities represent a market segment with $55 billion in annual disposable income in Canada alone. An inaccessible website turns that money away.

And there's a less obvious angle: the same structural problems that break accessibility also break your visibility in AI search results. Screen readers and AI crawlers parse your site in similar ways. When your headings are a mess and your images have no descriptions, both struggle to understand your content. We wrote about this connection in our guide to AI search optimization — the overlap is significant.

The Checklist: 10 Things You Can Test Yourself

You don't need to be a developer to run these checks. You need a keyboard, a browser, and about 30 minutes.

That last step alone will tell you whether your developer has been thinking about accessibility at all.

Test 1: The Keyboard Test

Put your mouse in a drawer. Seriously.

Now press Tab. You should see a visible outline or highlight move from one interactive element to the next — links, buttons, form fields, menu items. Press Tab again. And again. Follow it through the page.

Three things to watch for:

Does the focus indicator exist? Some developers remove the default browser outline because they think it looks ugly. That's like removing a wheelchair ramp because it clashes with the landscaping. If you can't see where your keyboard focus is, a keyboard-only user can't either.

Does the focus move in a logical order? It should follow the visual layout of the page, roughly top to bottom, left to right. If focus jumps from your header to the footer and back to the middle of the page, something is structurally wrong in the code.

Can you actually do things? Try opening your navigation menu with Enter or Space. Try submitting your contact form. Try clicking a call-to-action button. If any of these fail without a mouse, you have a hard blocker for keyboard users, screen reader users, and many people with motor impairments.

About 11% of Canadian adults have a mobility-related disability. The keyboard test isn't a nice-to-have.

Test 2: The Zoom Test

Hold down Ctrl (or Cmd on a Mac) and press the plus key until your browser hits 200% zoom.

WCAG 2.1 AA requires that your site remain functional at 200% zoom with no loss of content or functionality. No horizontal scrolling on text content. No overlapping elements. No text cut off by containers that don't resize.

Most modern responsive sites handle this well. But we still see it fail regularly on sites with fixed-width containers, absolutely positioned elements, and text embedded in images. If your logo has text baked into it as a PNG, it's going to look terrible at 200%. If your hero banner has a headline layered over a photo using absolute positioning, it might overlap on zoom.

This test takes 30 seconds. If it fails, your developer needs to hear about it.

Test 3: Image Alt Text

Right-click any image on your site. Select "Inspect" (Chrome) or "Inspect Element" (Firefox). Look for the alt attribute in the highlighted HTML.

Good alt text: alt="Team of four Breemedia developers working at a whiteboard in our Calgary office"

Bad alt text: alt="image1.jpg" or alt="photo" or alt=""

Missing alt text: no alt attribute at all.

Decorative images (a background gradient, an abstract shape, a divider line) should have alt="" (empty on purpose). That tells screen readers to skip them. But every image that conveys information needs a description that would make sense if the image failed to load.

Here's the part most people miss: the alt text isn't just for screen readers. Google uses it. AI assistants parse it. When your product images have no alt text, they're invisible to every system that can't see pixels. We cover how this affects your search visibility in our piece on why accessibility matters.

Test 4: Colour Contrast

Pull up the WebAIM Contrast Checker. Enter your text colour and background colour.

WCAG 2.1 AA requires:

• Normal text: 4.5:1 contrast ratio minimum
• Large text (18px bold or 24px regular): 3:1 minimum
• UI components and graphical objects: 3:1 minimum

The most common failure we see in the wild? Light grey text on a white background. Designers love it because it looks "clean." Users with low vision hate it because they can't read it.

Trendy design and accessible design are not opposites, but you have to check. That beautiful sage green on cream might feel elegant and fail WCAG. A quick number check takes 10 seconds per colour combination.

Test 5: Heading Structure

This one's invisible to most people but it matters enormously.

Screen readers let users jump between headings to scan a page — the same way a sighted person skims by looking at the bold, large text. If your headings skip levels (H1 to H3 with no H2) or if someone used heading tags just to make text bigger, the page structure becomes meaningless to assistive technology.

Your page should have exactly one H1 (your page title), followed by H2s for major sections, H3s for subsections within those. No skipping.

To check this without touching code, install the free HeadingsMap browser extension. It shows you the heading hierarchy of any page in a sidebar. If it looks like a mess, it is.

Test 6: Forms

Your contact form is where accessibility failures cost you money directly.

Every form field needs a visible <label> element that's programmatically connected to the input. Placeholder text (that greyed-out hint inside the text box) is not a label. It vanishes when you start typing, which means users can't check what the field was asking for mid-entry. Screen readers may or may not read placeholder text depending on the browser.

Check that error messages are clear and specific. "Invalid input" helps nobody. "Please enter a valid email address" helps everyone.

And test the form with your keyboard. Can you Tab to every field? Can you select items in dropdown menus? Can you submit the form by pressing Enter? If any of these fail, you're losing leads from people who can't or don't use a mouse.

The Overlay Question

You've probably seen ads for accessibility overlay tools. They promise to "fix" your website's accessibility with a single line of JavaScript. A widget appears in the corner. Users can adjust font sizes, toggle high contrast, or enable a screen reader mode.

We're going to be direct about this: overlays don't work.

Accessibility isn't a widget you bolt onto a broken building. It's the foundation. If the structure is wrong, no amount of surface-level adjustment will make the building safe.

The National Federation of the Blind has publicly opposed overlay products. Over 800 accessibility professionals have signed a statement against them. AccessiBe, the largest overlay vendor, has been sued by users with disabilities for making sites harder to use, not easier. The overlays frequently conflict with the assistive technology people already use. A screen reader user doesn't need your overlay's "screen reader mode" — they already have a screen reader. Your overlay just gets in its way.

Overlays also don't protect you legally. Multiple lawsuits have specifically named overlay products as insufficient remediation. Courts want the actual code fixed, not a Band-Aid.

If a vendor pitches you an overlay as an accessibility solution, that's a red flag about their understanding of the field. Real accessibility happens in the HTML, the CSS, and the development process. There's no shortcut. When we build accessible sites, we write it into the code from the first line.

Using Free Tools for a Deeper Check

After running through the manual checklist above, two free browser tools will show you what you missed.

WAVE (wave.webaim.org) is a browser extension from WebAIM. Install it, go to your site, click the WAVE icon. It overlays coloured icons directly on your page — red for errors, yellow for alerts, green for structural elements. It's visual, immediate, and you don't need to understand code to see that 23 red icons is a bad sign.

axe DevTools (from Deque) is a browser extension that integrates with Chrome's developer tools. Click "Analyze" and it returns a list of issues grouped by severity, with links to explanations of each rule. It catches things WAVE misses, and vice versa. Running both gives you a more complete picture.

Neither tool catches everything. Automated tools detect roughly 30-40% of accessibility issues. They can't tell you whether your alt text is actually useful or whether your heading hierarchy makes conceptual sense. They can't test whether a complex interaction like a modal dialog or an accordion menu works properly with a keyboard.

But they're a starting point. If either tool returns zero errors, your developer is doing something right. If they return dozens — and most sites do — you know where to start.

What to Do With the Results

You've run the checklist. You've used WAVE and axe DevTools. You've found problems.

Now what?

Don't panic, and don't try to fix everything at once. Accessibility remediation is a process, not a one-day project.

Prioritize by impact. Keyboard access and heading structure affect the most users. Colour contrast is usually the quickest fix. Missing alt text is high volume but straightforward to address. Form labels require a developer but have a direct effect on conversions.

Take your findings to your web developer. If they dismiss accessibility as unimportant or suggest an overlay, find a different developer. If they understand the issues and can explain the fixes in terms you follow, that's a good sign.

Ask for a proper WCAG 2.1 AA audit — not just an automated scan, but a manual review by someone who tests with real assistive technology. Automated tools miss the majority of real-world issues. A proper audit typically runs $2,000 to $5,000 depending on the size and complexity of the site, and it gives you a prioritized remediation roadmap.

If you're not sure where to start, our accessibility and WCAG services include exactly this kind of audit, built around what actually affects your users and your legal exposure.

The single thing to remember from this entire checklist: put your mouse in a drawer and try to use your website. If you can't, neither can a substantial portion of your potential customers. That's the test that matters.

Sources

• The WebAIM Million — 2025 Report — Annual analysis of the top 1,000,000 home pages for accessibility errors. Annual analysis of the top 1,000,000 home pages for accessibility errors. The 2025 report found 51 errors per page.
• Canadian Survey on Disability, 2017 — Statistics Canada source for Canadian disability data. The 2022 survey found 8 million Canadians (27% aged 15+) have a disability.
• The Global Economics of Disability — Return on Disability Group — Source for the $55 billion disposable income figure for Canadians with disabilities, widely cited by disability employment and advocacy organizations.
• Accessible Canada Act (S.C. 2019, c. 10) — Full text of the federal accessibility legislation on the Justice Laws Website. Summary available at canada.ca.
• Accessibility for Ontarians with Disabilities Act (AODA) — Ontario's accessibility legislation, referenced as enforceable since 2014.
• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C Recommendation. The 4.5:1 contrast ratio requirement is specified in Success Criterion 1.4.3 (Contrast Minimum).
• WebAIM Contrast Checker — Free tool for checking foreground/background colour contrast against WCAG AA and AAA thresholds.
• WAVE Web Accessibility Evaluation Tools — Free browser extension from WebAIM for visual accessibility evaluation. Extension download at wave.webaim.org/extension.
• axe DevTools Browser Extension — Free accessibility testing extension from Deque Systems, powered by the axe-core engine.
• HeadingsMap Browser Extension — Free Chrome extension for visualizing heading hierarchy on any page. Also available for Firefox.
• Overlay Fact Sheet — Joint statement signed by 800+ accessibility professionals and disability advocates opposing overlay products, maintained by Karl Groves.
• NFB Statement Regarding accessiBe — National Federation of the Blind's 2021 statement revoking accessiBe's convention sponsorship and calling the company's practices harmful.
• GDS Accessibility Tool Audit — UK Government Digital Service study introducing 142 known barriers and testing 13 automated tools. The best tool detected ~40% of issues, supporting the 30-40% automated detection rate cited in the article.