Website Accessibility for E-Commerce: ADA and AODA Basics for US and Canadian Brands

If you sell online in the US or Canada, ecommerce website accessibility isn't just a nice-to-have. It's a legal exposure, a customer experience issue, and a revenue issue all at once. The good news is that most of what makes a storefront accessible is ordinary, well-understood front-end work, and you can start on it this week.

This guide covers what US and Canadian (especially Ontario) businesses actually need to know about the rules, then walks through a practical, WCAG-based fix list for a typical storefront.

This isn't legal advice. Accessibility law varies by jurisdiction and changes over time. If you've received a demand letter or need a definitive answer about your obligations, talk to a lawyer who handles accessibility cases.

ADA compliance for websites: where US law actually stands

The Americans with Disabilities Act was written before online shopping existed, so it doesn't mention websites. Title III prohibits disability discrimination by "places of public accommodation," and over the years many courts have applied that to websites, especially those of businesses that sell goods and services to the public. The Department of Justice has also said publicly that the websites of businesses open to the public should be accessible to people with disabilities.

What's missing is a single codified technical standard for private businesses. There's no federal regulation that says "your store's website must meet exactly this checklist." Courts in different parts of the country have also reached different conclusions on some questions, such as whether an online-only business counts as a public accommodation at all.

In practice, the industry has settled on a benchmark anyway: the Web Content Accessibility Guidelines (WCAG), published by the W3C, at Level AA. WCAG 2.1 AA is the version you'll see referenced most often in settlements and audits, and WCAG 2.2 AA is the current version. If you build to 2.2 AA, you generally cover 2.1 AA and 2.0 AA too, since each version builds on the last.

Why this matters for e-commerce specifically: web accessibility lawsuits and demand letters are common, and online retailers are a frequent target. Storefronts are public, easy to test, and full of patterns that tend to break for screen reader and keyboard users: image-heavy product grids, custom dropdowns, pop-ups, and multi-step forms. No need to panic, but don't assume your brand is too small to notice.

AODA website requirements and the rest of Canada

Canada is more explicit, at least in Ontario.

Ontario: the AODA

The Accessibility for Ontarians with Disabilities Act (AODA) includes the Integrated Accessibility Standards Regulation, which sets web requirements. Under it, designated public sector organizations and private or non-profit organizations with 50 or more employees in Ontario must make their public websites and web content conform to WCAG 2.0 Level AA. The final deadline for that was January 1, 2021, so if you're in scope, you're expected to be compliant now.

There are limited exceptions. Live captions and pre-recorded audio descriptions are excluded from the requirement, and there are carve-outs for situations where meeting a requirement isn't practicable. Organizations in scope also have reporting obligations under the AODA, separate from the website work itself.

If you've grown past 50 employees in Ontario, check this carefully. Even under the threshold, Ontario shoppers are still your customers.

Federal and other provinces

The federal Accessible Canada Act applies to federally regulated sectors, such as banking, telecommunications, broadcasting, and federally regulated transportation. Most DTC brands aren't covered by it directly, but if you sell into or partner with those sectors, you may run into its expectations.

Other provinces vary. Quebec has its own accessibility standards for public bodies, and several provinces, including Manitoba and Nova Scotia, have their own accessibility legislation with standards at different stages. If you operate outside Ontario, check your province's current rules rather than assuming Ontario's apply.

Why accessibility overlays won't make you compliant

You've probably seen the pitch: add one line of JavaScript, get a floating accessibility widget, and your site is "ADA compliant." It isn't.

Overlays sit on top of your existing code. They can't reliably fix a custom variant picker that doesn't work with a keyboard, a checkout form with missing labels, or a cart drawer that traps screen reader users. Some overlays add their own barriers by interfering with the assistive technology people already use. Many disabled users and accessibility practitioners actively dislike them, and having an overlay installed hasn't stopped stores from receiving demand letters.

Accessibility lives in your theme, your components, and your content. That's where the fixes have to happen.

Shopify accessibility: what you control and what you don't

If you're on Shopify, there's a useful split to understand. Shopify controls most of checkout. The core checkout flow is built and maintained by Shopify, and you can't (and shouldn't need to) rewrite its markup. Any checkout extensions or customizations you add, though, are yours to get right.

Everything before checkout is your responsibility: your theme, product and collection pages, cart, navigation, search, pop-ups, and every app that injects code into the storefront. A theme can start out reasonably accessible and drift over time as sections get customized and apps get added. Reviews widgets, bundle builders, size-chart modals, email capture pop-ups, and quiz apps are common sources of problems, and you're accountable for them even though someone else wrote the code.

A WCAG 2.2 checklist for e-commerce storefronts

Here's the practical part. These are the fixes that come up again and again on real storefronts, roughly in the order we'd tackle them.

1. Fix color contrast. Body text needs a contrast ratio of at least 4.5:1 against its background, and large text needs 3:1. Buttons, form field borders, and icons that convey meaning need at least 3:1 too. Light gray placeholder text, white text on pale product photography, and low-contrast "sale" badges are the usual offenders.
2. Make everything work with a keyboard. Tab through your homepage, a collection page, a product page, and the cart without touching the mouse. Every link, button, menu, filter, and form control should be reachable and usable, in a logical order. Mega menus that only open on hover are a common failure.
3. Keep focus visible. When someone tabs to an element, they need to see where they are. Many themes remove the browser's focus outline with outline: none and never replace it. Add a clear, high-contrast focus style, and make sure sticky headers or chat widgets don't hide the focused element (a WCAG 2.2 addition).
4. Write real alt text for product images. Describe what matters to a shopper: "Navy linen shirt, front view, with a button-down collar" beats "IMG_4471" or the product title repeated. Purely decorative images should have empty alt text (alt="") so screen readers skip them.
5. Label every form field and explain every error. Each input in your cart, account, newsletter, and any custom pre-checkout forms needs a programmatic label, not just placeholder text that disappears when you type. When something goes wrong, say what and how to fix it ("Enter a valid ZIP or postal code"), and make sure that message is announced to screen readers, not just shown in red.
6. Rebuild variant pickers and swatches properly. Size and color selectors are often custom-styled divs that screen readers can't make sense of. Use native radio buttons or selects under the styling, give each option an accessible name (a color swatch needs the color's name, not just a colored circle), and announce sold-out states in text, not only with a strikethrough.
7. Fix modals and drawers. Cart drawers, quick-view windows, size guides, and pop-ups should move focus into the dialog when they open, keep focus inside while open, close with the Escape key, and return focus to the button that opened them. Email capture pop-ups that appear on load and can't be dismissed by keyboard are a frequent problem.
8. Tame carousels and autoplay. Anything that moves automatically for more than five seconds needs a way to pause, stop, or hide it. Hero sliders need visible, keyboard-accessible controls. Background video should not autoplay with sound, and should respect users who've asked their system to reduce motion.
9. Caption your videos. Product demos, founder stories, and how-to videos need accurate captions. Auto-generated captions are a starting point, not a finished job; edit them for product names and accuracy.
10. Use a sensible heading structure. One h1 per page (usually the product or collection name), then h2s and h3s in order. Screen reader users navigate by headings, so headings chosen for their font size rather than their meaning make a page much harder to scan.
11. Size touch targets generously. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels (with some exceptions), and bigger is better on mobile. Tiny quantity steppers, close icons, and swatch dots are the usual problems. This overlaps heavily with mobile conversion work; see our notes on mobile checkout abandonment fixes.
12. Test with tools, then test by hand. Run an automated checker such as axe or Lighthouse to catch the obvious issues, but know that automated tools only catch part of the picture. Then do manual passes: keyboard-only navigation, and a real screen reader, VoiceOver on macOS and iOS and NVDA on Windows, through the path from homepage to product to cart to checkout.

Make accessibility part of how you build, not a one-time audit

A one-time audit and fix is a good start, but storefronts change constantly. New campaigns, new apps, new sections, and theme updates can all reintroduce problems you already fixed.

The teams that stay accessible tend to build it into their normal process:

• Design with it from the start. Check contrast, focus states, and target sizes in the design file, before anything gets built. It's far cheaper than retrofitting. This is a standard part of how we approach design work.
• Add it to your definition of done. A new section or component isn't finished until it's been tested with a keyboard and a screen reader.
• Vet apps before you install them. Try the app's storefront features with a keyboard on a development theme first. If it fails, ask the vendor about it or look for an alternative.
• Automate what you can. Accessibility checks in your build or deployment process can catch regressions like missing labels or alt text before they ship.
• Publish an accessibility statement and a way to report issues. Give customers a clear way to tell you when something doesn't work, and respond when they do. That feedback is often the fastest way to find real problems.

None of this requires a dedicated accessibility team, just developers who know the patterns and a process that doesn't skip the check. Accessible stores also tend to be cleaner, faster, and easier for everyone to use, which is the same direction you want your web development going anyway.

Want a second pair of eyes on your store?

If you're not sure where your storefront stands, an accessibility review is a reasonable place to start. We'll go through your key shopping paths with a keyboard and screen reader, flag the issues that matter most, and tell you plainly what's in your theme and apps versus what Shopify handles. If that sounds useful, get in touch and tell us a bit about your store.