Web Accessibility: A Practical Guide for Business Sites

Why Accessibility Is a Business Issue, Not a Charity Project

Web accessibility has a framing problem. It gets pitched either as a legal threat or as a moral obligation, and both framings push it to the bottom of the backlog — one because the risk feels abstract, the other because goodwill doesn’t survive a budget meeting. The more useful framing is simpler: a meaningful share of your customers cannot use parts of your website right now, and most of the barriers in their way are cheap to remove.

The scale is bigger than most owners assume. Statistics Canada’s 2022 Canadian Survey on Disability found that 27 percent of Canadians aged 15 and over — roughly eight million people — live with at least one disability. That includes vision and hearing impairments, but also motor conditions that make a mouse difficult and cognitive conditions that punish cluttered layouts. Add the temporary cases — a broken wrist, eye surgery, a screen in direct sunlight — and the population that benefits from an accessible site at any given moment is larger still.

For a business, that population is leads. If your booking form can’t be completed with a keyboard, those visitors don’t file a complaint — they go to a competitor. Accessibility work is conversion work for traffic you’re already paying to acquire. And because so much of it overlaps with technical SEO and general usability — semantic structure, descriptive link text, readable contrast — the same fixes tend to lift performance for everyone.

The Legal Landscape in Canada: ACA, AODA, and Who They Actually Apply To

Canadian accessibility law is a patchwork, and it’s worth being precise about which pieces apply to you, because much of what circulates online is American (the ADA does not govern Canadian businesses) or overstated.

Federally, the Accessible Canada Act came into force in 2019. It applies to federally regulated entities — banks, airlines, telecoms, broadcasting, interprovincial transport, and the federal government itself — and requires them to publish accessibility plans, set up feedback processes, and report on progress, with the stated goal of a barrier-free Canada by 2040. If you run a typical local or provincial business, the ACA does not directly apply to you; it matters mostly as a signal that the regulatory trend is toward more accessibility requirements, not fewer.

Provincially, Ontario’s Accessibility for Ontarians with Disabilities Act is the one with teeth for websites. Under its Integrated Accessibility Standards Regulation, since January 1, 2021, private and non-profit organizations with 50 or more employees in Ontario, and all public-sector organizations, must make their public websites and web content conform to WCAG 2.0 Level AA (with exemptions for live captions and pre-recorded audio description). Organizations with 20 or more employees also have to file compliance reports. The Act allows for significant penalties, though enforcement to date has leaned on reporting and education rather than aggressive fines — which is a reason not to panic, not a reason to ignore it.

Two caveats keep small businesses honest. First, other provinces are following: Manitoba, Nova Scotia, and British Columbia all have accessibility legislation at various stages, with B.C.’s Accessible British Columbia Act currently focused on the public sector. Second, employee-count thresholds don’t exempt anyone from human rights law. Disability is a protected ground under the Ontario Human Rights Code and its provincial counterparts, and an inaccessible service — including a website — can ground a discrimination complaint regardless of headcount. The thresholds decide who must report, not whether accessibility is your problem.

What WCAG 2.1 AA Actually Means in Plain Language

Every accessibility law and lawsuit eventually points at the same document: the Web Content Accessibility Guidelines, maintained by the W3C. WCAG comes in versions — 2.0 from 2008, 2.1 from 2018, and 2.2 from late 2023 — and three conformance levels: A (bare minimum), AA (the standard regulators and courts reference), and AAA (aspirational, rarely required in full). When anyone says “make the site compliant,” they almost always mean WCAG 2.1 Level AA, and building to 2.2 AA — which adds a handful of criteria around focus visibility, target sizes, and reducing redundant data entry — is the sensible target for new work in 2025. Ontario’s regulation technically references 2.0 AA, but each version is backwards-compatible, so meeting 2.1 or 2.2 AA covers you.

The guidelines organize everything under four principles, abbreviated POUR. Perceivable: users must be able to take in your content — images need text alternatives, video needs captions, text needs sufficient contrast against its background. Operable: users must be able to navigate and interact — everything reachable by keyboard, no traps, enough time to act, nothing that flashes seizure-inducingly. Understandable: content and controls must behave predictably — clear labels, helpful error messages, consistent navigation. Robust: the code underneath must be clean enough that assistive technologies like screen readers can interpret it.

That’s genuinely the whole conceptual model. WCAG’s intimidating part is its size — dozens of formally worded success criteria — but on a typical marketing site or store, the same fifteen or so issues account for the overwhelming majority of real-world failures. The rest of this guide focuses on those.

The Low-Effort Fixes With the Biggest Impact

If you do nothing else, do these four things. None requires a rebuild, and together they resolve the most common barriers on business sites.

First, alt text on images. Every meaningful image needs a text alternative that conveys what the image communicates in context — “Technician replacing a furnace filter in a North Vancouver home,” not “image1” or a pile of keywords. Purely decorative images should have an empty alt attribute so screen readers skip them instead of announcing file names. This is usually an afternoon of content work, and it doubles as an SEO improvement.

Second, colour contrast. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text against its background. The chronic offenders are light grey body copy on white, white text over busy hero photos, and placeholder-coloured labels. Free contrast checkers will tell you in seconds whether a combination passes; fixing it is typically a few values in a stylesheet. While you’re at it, make sure colour is never the only signal — an error shown solely by turning a border red is invisible to a colour-blind user, so pair it with text or an icon.

Third, real heading structure. Headings should describe the document’s outline — one h1 per page, h2 for major sections, h3 nested beneath — because screen reader users navigate by jumping between them. Sites that pick heading tags for their font size break that map completely. Style with CSS; structure with semantics.

Fourth, descriptive link text. A screen reader can pull up a list of every link on the page, stripped of surrounding context. A list that reads “learn more, learn more, click here, read more” is useless. “See our furnace repair pricing” costs nothing extra and helps search engines understand the page, too.

Keyboard Navigation and Visible Focus: The Five-Minute Test

Here’s the single most revealing accessibility test you can run today, and it costs nothing: put your mouse out of reach and try to use your own website. Tab moves you forward through interactive elements, Shift-Tab moves you back, Enter activates links and buttons, Space toggles checkboxes, arrow keys drive menus and radio groups. Try to navigate from the homepage to your contact form and submit it.

Most business sites fail within a minute, in predictable ways. You press Tab and can’t see where you are, because someone disabled the focus outline for being “ugly” — the accessibility equivalent of removing the cursor. You reach a dropdown that only opens on mouse hover, sealing off entire sections of the site. You hit a modal or chat widget that swallows focus and won’t let go. You discover the clickable cards on your services page are div elements with click handlers rather than real links, so the keyboard skips them entirely.

The fixes are mostly straightforward. Keep focus indicators visible — if the browser default clashes with your brand, style a better one rather than deleting it; WCAG 2.2 raises the bar on focus visibility precisely because it got removed so often. Build interactive elements from the HTML tags designed for the job: links for navigation, buttons for actions. Native elements are keyboard-operable and screen-reader-announced for free, while a div pretending to be a button needs handcrafted scripting to claw back what the real tag gave you by default. Add a “skip to main content” link as the first focusable element so keyboard users aren’t forced through your full navigation on every page. And repeat the keyboard pass after any redesign — it’s five minutes, and it catches regressions nothing else will.

Screen Readers: What They Need From Your Site

A screen reader converts your page into speech or braille, and the experience it produces depends almost entirely on the quality of your HTML. You don’t need to buy anything to see this firsthand: VoiceOver ships free with every Mac and iPhone, and NVDA is a free, widely used screen reader for Windows. Spending twenty minutes listening to your own homepage is uncomfortable and enormously educational.

What screen readers rely on is semantics — markup that says what things are, not just what they look like. Landmark regions (header, nav, main, footer) let users jump straight to content; correct headings provide the outline they navigate by; lists announced as lists tell users how many items to expect; buttons signal an action on this page, links a destination elsewhere. When a site is built from anonymous styled boxes, the screen reader can only recite an undifferentiated stream of text, and the user is left to guess at structure that sighted visitors absorb in a glance.

A few specifics catch most sites. Icon-only buttons — the hamburger menu, the search magnifier, the cart — need an accessible name; an aria-label is the difference between hearing “button, menu” and hearing “button” with no clue what it does. Content that updates without a page load, like a form confirmation, may need a live region so the change is announced rather than happening silently. And be conservative with ARIA generally: incorrect ARIA is worse than none, because it confidently lies to the user about how an element behaves. Native HTML first, ARIA only for the gaps.

Forms: Where Business Sites Lose the Most Leads

Forms deserve their own section because they’re where accessibility failures cost you directly. A visitor who can’t read your blog post is a shame; a visitor who can’t complete your quote request is lost revenue. Forms are also where business sites most reliably fail testing.

The foundational rule: every input needs a programmatically attached, visible label. Placeholder text is not a label — it vanishes the moment someone starts typing, it’s routinely styled below contrast minimums, and screen readers don’t treat it consistently. A proper label element tied to its input means the screen reader announces the field’s purpose, and clicking the label focuses the input, which enlarges the touch target for everyone on mobile.

Error handling is the next failure point. When validation fails, the user needs to know that something went wrong, which field is responsible, and how to fix it — in text, not just a red outline. Error messages should be associated with their fields so assistive technology announces them, and the message itself should be specific: “Enter a phone number with area code, like 604-555-0123,” not “invalid input.” Vague errors abandon exactly the users — cognitive disabilities, low vision, plain old hurry — who most need clarity.

Round it out with smaller wins: group related fields with fieldsets and legends so “Billing address” context isn’t lost; use correct input types and autocomplete attributes so browsers can fill in known details, which WCAG 2.2 now explicitly rewards; and test your CAPTCHA, because an inaccessible CAPTCHA is a locked door at the end of an otherwise perfect journey — honeypots and invisible verification beat puzzles.

How to Test Your Site Honestly

A realistic testing routine for a business site has three tiers, in ascending order of effort and value.

Tier one is automated scanning. Lighthouse, built into Chrome’s developer tools, includes an accessibility audit; axe DevTools and WAVE are free browser extensions that go deeper. Run them on your highest-traffic templates — home, service page, contact, checkout. They’ll reliably catch missing alt attributes, contrast failures, missing labels, and broken ARIA. But understand the limit: automated tools can only detect a portion of WCAG issues, because most criteria require judgment. A scanner can confirm an image has alt text; it can’t tell you the alt text is garbage. A perfect automated score is a floor, not a verdict.

Tier two is manual testing, and it’s where the real findings live. The keyboard-only pass described earlier. A screen reader session on your three most important user journeys. A zoom test — at 200 percent, required by WCAG, does the layout still work? A motion check — do animations respect the user’s reduced-motion setting? Budget a few hours per quarter and after any significant design change. Most teams find their first manual pass humbling and their fixes surprisingly fast.

Tier three is testing with actual users with disabilities, through a specialist firm or paid user testing. For a small business this is optional; for anyone covered by AODA reporting or running e-commerce at scale, it’s worth the money once the obvious issues are fixed, because it surfaces friction no checklist anticipates. Whichever tiers you use, write findings down with dates — if you’re ever asked to demonstrate compliance effort, a documented history of testing and remediation is exactly what you want to have.

Skip the Shortcuts, Build the Habit

One warning before the wrap-up: you will encounter accessibility overlay widgets — third-party scripts promising compliance with one line of code, usually advertising a toolbar of contrast toggles and font controls. Be skeptical. Overlays can’t fix broken underlying markup, they frequently interfere with the assistive technology users already have configured, and they’re widely criticized by the very community they claim to serve; in the United States, sites running overlays have still faced accessibility lawsuits. Money spent on a widget is better spent on a developer-day of real remediation.

The durable approach is to treat accessibility the way you treat security: not a one-time project but a property of how you work. Put the basics into your content workflow — alt text and heading structure checked before anything publishes. Put the checks into your development workflow — automated scans on new templates, a keyboard pass before launch, contrast verified when brand colours change. Ask about WCAG conformance in writing whenever you commission a site or a redesign, and make it an acceptance criterion rather than a hope. At SearchPod we build to WCAG AA by default for exactly this reason: retrofitting accessibility is expensive, while building it in is barely a line item.

Start with the five-minute keyboard test today. Fix the focus states, the labels, the contrast, and the alt text this quarter. You’ll be most of the way to the standard the law points at, ahead of the regulatory direction the ACA signals, and — more to the point — you’ll stop quietly turning away customers who were trying to give you money.