Web Accessibility Checklist Every Business Should Follow

Web accessibility lawsuits in Canada increased 300% between 2020 and 2023. Small businesses are not exempt. A Vancouver bakery was sued in 2022 because their online ordering system couldn't be used with a screen reader. They settled for $18,000.

This isn't about fear. It's about reality. Fifteen percent of the global population lives with some form of disability. When your website excludes them, you're turning away customers and exposing yourself to legal action. The good news: most accessibility fixes are straightforward.

What web accessibility actually means

Web accessibility means people with disabilities can perceive, navigate, and interact with your website. This includes people who are blind or have low vision, are deaf or hard of hearing, have mobility limitations, or have cognitive differences.

The standard is WCAG 2.1 Level AA. That's what courts reference. It's what the Accessible Canada Act points to. And it's what this checklist is based on.

You don't need to be a developer to understand most of this. You need to know what to look for and what to tell your web team to fix.

Colour contrast and visual design

Text must have sufficient contrast against its background. The ratio is 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold). Grey text on a white background often fails. Light blue links on white definitely fail.

Use a free tool like WebAIM's Contrast Checker. Plug in your hex codes. If it fails, adjust until it passes.

Common failures:

• Pale grey text for body copy
• White text on yellow buttons
• Light blue hyperlinks
• Grey placeholder text in form fields

Don't rely on colour alone to convey information. If your error messages are only red text, colour-blind users won't notice them. Add an icon or label.

Keyboard navigation

Every interactive element must be reachable and usable with a keyboard alone. No mouse. No trackpad.

Open your website. Unplug your mouse. Press Tab to move forward, Shift+Tab to move backward. Can you reach every link, button, and form field? Can you see where you are (the focus indicator)? Can you activate buttons with Enter or Space?

If your custom dropdown menu doesn't work with arrow keys, it fails. If your mega navigation disappears when you tab into it, it fails. If there's no visible outline around the focused element, it fails.

Most failures come from custom JavaScript components that override native browser behaviour. The fix: use semantic HTML elements when possible, and test with a keyboard before launch.

Alt text for images

Every image needs alt text that describes its content or function. Screen readers announce this text. Search engines read it. If the image doesn't load, the alt text appears.

Decorative images (purely visual elements with no informational value) should have empty alt text: alt="". This tells screen readers to skip it.

Informative images need descriptive alt text. "Photo of storefront" is weak. "Rosewood Cafe storefront at 1234 Main Street, Vancouver, with outdoor seating and red awning" is better.

Functional images (logos that link, icons that trigger actions) need alt text that describes the function. A magnifying glass icon should be alt="Search", not alt="Magnifying glass".

Don't start with "Image of" or "Picture of". Screen readers already announce it's an image.

Form labels and error handling

Every form field needs a visible label. Placeholder text doesn't count. "Enter your email" inside the field disappears when you start typing. Use a <label> element tied to the field with a for attribute.

Error messages must be clear and associated with the specific field that failed. "Please fix the errors below" at the top of the form isn't enough. Each field needs its own message: "Email address is required" or "Password must be at least 8 characters".

Required fields should be marked with more than just a red asterisk. Add the word "required" in the label or use aria-required="true".

Multi-step forms need clear progress indicators. "Step 2 of 4" works. A progress bar with text labels is better.

Heading structure

Headings create an outline for your content. Screen reader users navigate by jumping between headings. If your structure is broken, they get lost.

Use one H1 per page. It should be the page title. After that, H2 sections, H3 subsections. Never skip a level. Don't go H2 to H4. Don't use headings just to make text bigger.

Most content management systems mess this up. Your theme might style the sidebar heading as H4 when it should be H2. Your blog post might use H3 for the author bio when it should be outside the main heading structure.

View your page source. Look for <h1>, <h2>, etc. Does the hierarchy make sense? Would you understand the page structure from headings alone?

Video and audio content

All video content needs captions. Not auto-generated YouTube captions that say "[Music]" for three minutes. Accurate captions that include speaker identification and relevant sound effects.

If your video has important visual information (a product demonstration, a chart), you need audio description. That's a separate audio track that describes what's happening visually during pauses in dialogue.

Audio-only content (podcasts) needs a transcript. It doesn't need to be verbatim, but it should capture all meaningful content.

Zazen Media Group handles video captioning and transcript generation for clients who produce regular content. It adds cost and time, but it's not optional.

Link text and context

Links must make sense out of context. Screen reader users often navigate by pulling up a list of all links on the page. If ten links say "Click here" or "Read more", they're useless.

"Read our accessibility policy" is clear. "Click here to read our accessibility policy" is redundant. "Click here" alone is meaningless.

Links should describe where they go. "Download the 2024 annual report (PDF, 2.3 MB)" tells users what to expect. "Download" doesn't.

Avoid vague phrases: "Learn more", "Find out", "Discover". Be specific: "View our service packages", "Read the full case study", "Compare pricing plans".

Mobile accessibility

Touch targets must be at least 44×44 pixels. Smaller targets are hard to tap for people with motor impairments, older users, anyone with large fingers.

Check your mobile navigation. Those three horizontal lines (hamburger menu) are fine if they're big enough and clearly labelled ("Menu" or "Open menu").

Pinch-to-zoom must be enabled. Don't disable it with user-scalable=no in your viewport meta tag. People with low vision need to zoom. It's non-negotiable.

Text must reflow at 200% zoom without horizontal scrolling. This is a common failure. Your desktop layout might break when zoomed. Test it.

Testing and maintenance

Accessibility isn't a one-time fix. Content changes. Features get added. New issues emerge.

Run automated scans with WAVE (browser extension) or axe DevTools. They catch about 30% of issues. The rest require manual testing.

Hire someone to do a proper audit every 18–24 months. Budget $2,000–$5,000 for a small business site. Less than a single lawsuit settlement.

Train your content team. The person uploading blog posts needs to know how to write alt text. The person editing your homepage needs to understand heading structure.

If you're based in BC and need help auditing your site or fixing accessibility issues, talk to Zazen Media Group. We work with businesses that want to do this properly, not just check a box.