WCAG compliance for ecommerce menus: what the law actually requires

WCAG stands for Web Content Accessibility Guidelines, published by the W3C (World Wide Web Consortium). It’s not a law itself—it’s a standard. But laws in the U.S., the EU, Canada, the UK, Australia, and dozens of other countries reference WCAG as the benchmark for what “accessible” means. When a court or regulator asks whether your website is accessible, they’re asking whether it meets WCAG.

The version that matters right now is WCAG 2.1, and the level that matters is Level AA. Level A is the minimum—most of it is so basic that failing it means the site is essentially unusable. Level AAA is aspirational—few sites achieve full compliance. Level AA is the practical, legal standard. When someone says “your site needs to be WCAG compliant,” they mean WCAG 2.1 Level AA.

The WCAG criteria that apply to navigation

Navigation menus are interactive, visual, and structural—which means they touch multiple WCAG success criteria. Here are the ones that directly apply:

2.1.1 Keyboard (Level A): All functionality must be available via keyboard. This means every link in your menu must be reachable by pressing Tab. Every dropdown must open with Enter or Space and close with Escape. Every submenu must be navigable with arrow keys or Tab. If any part of the navigation requires a mouse—hover-to-open dropdowns, click-only interactions that don’t respond to keyboard events—it fails.

2.1.2 No Keyboard Trap (Level A): A keyboard user must be able to move focus away from any element. If a user opens a dropdown and focus gets trapped inside it—Tab cycles endlessly through the submenu items with no way to exit—that’s a keyboard trap. Escape must close menus. Tab must eventually move focus past the navigation.

2.4.3 Focus Order (Level A): The order in which elements receive focus must be logical and meaningful. In navigation, this means left-to-right for horizontal menus, top-to-bottom for vertical ones. If a user tabs to “Women” and the next focused element is “Contact Us” instead of “Men” (the next menu item), the focus order is broken.

2.4.7 Focus Visible (Level AA): Any element that receives keyboard focus must have a visible focus indicator. A colored outline, a background change, an underline—something that shows the user where they are. Removing outline: none in CSS without adding a replacement fails this criterion.

2.4.4 Link Purpose (Level A): The purpose of each link must be determinable from its text or its surrounding context. Navigation links like “Dresses,” “Men’s Shoes,” and “Sale” pass because they describe the destination. Links labeled “Click here” or icon-only links without accessible text fail.

1.4.3 Contrast (Level AA): Text must have at least 4.5:1 contrast against its background. Navigation link text, button labels, and dropdown text all count. A light gray (#AAAAAA) link on a white (#FFFFFF) background has a 2.32:1 ratio—it fails.

1.4.11 Non-text Contrast (Level AA): Visual indicators that convey information—like the active state of a menu item, a focus indicator, or an icon that functions as a link—must have at least 3:1 contrast against adjacent colors. A light blue active-state highlight on a white background may fail this.

4.1.2 Name, Role, Value (Level A): Interactive elements must have a programmatically determinable name and role. A link must be an <a> tag (or have role="link"). A button must be a <button> (or have role="button"). A dropdown trigger must communicate its state with aria-expanded. When menus are built with <div> elements and JavaScript handlers, assistive technology can’t determine what they are.

What WCAG doesn’t say

WCAG doesn’t require a specific visual design. It doesn’t mandate a particular navigation pattern—mega menus, hamburger menus, tabbars, and sidebars can all be compliant. It doesn’t require any specific technology—React, vanilla HTML, Shopify Liquid, and server-rendered pages can all meet the standard.

WCAG also doesn’t require perfection on day one. Courts have generally looked at whether a business is making good-faith efforts to improve accessibility, whether an accessibility policy exists, and whether the most critical user paths (including navigation) are accessible. That said, “we’re working on it” is not a legal defense—it’s a mitigating factor.

The legal landscape: ADA and beyond

In the United States, the ADA (Americans with Disabilities Act) doesn’t mention websites explicitly. But federal courts have consistently ruled that websites of businesses open to the public are “places of public accommodation” under Title III. In 2024, the Department of Justice published a final rule under Title II requiring state and local government websites to conform to WCAG 2.1 Level AA—reinforcing WCAG as the benchmark.

ADA website lawsuits have become a major compliance pressure. According to UsableNet’s annual report, there were over 4,600 ADA web accessibility lawsuits filed in federal court in 2023, continuing a trend that began surging in 2018. Ecommerce is the most-targeted industry. Navigation barriers—menus that don’t work with keyboard, dropdowns that trap focus, links without meaningful text—are among the most commonly cited issues.

High-profile cases illustrate the risk. In Robles v. Domino’s Pizza, the Ninth Circuit ruled that the ADA applies to Domino’s website and app, and that WCAG 2.0 AA was the appropriate standard. The Supreme Court declined to hear Domino’s appeal, letting the ruling stand. In Gil v. Winn-Dixie, the Eleventh Circuit addressed website accessibility under ADA Title III, establishing precedent that influenced subsequent cases across the circuit.

Outside the U.S., the European Accessibility Act (effective June 2025) requires products and services—including ecommerce websites—to meet accessibility requirements aligned with WCAG. Canada’s Accessible Canada Act and the UK’s Equality Act impose similar obligations. Australia’s Disability Discrimination Act has been applied to websites since the Maguire v. SOCOG case in 2000.

Practical steps for compliance

Full WCAG 2.1 AA compliance across an entire Shopify store is a significant project. But navigation compliance is achievable with focused effort:

1. Use semantic HTML. Build navigation with <nav>, <ul>, <li>, <a>, and <button>. This alone addresses multiple criteria.
2. Add ARIA attributes. aria-label on <nav> elements, aria-expanded on dropdown triggers, aria-current="page" on active links.
3. Ensure keyboard operability. Test that Tab, Enter, Space, and Escape work correctly throughout the menu. Fix hover-only dropdowns.
4. Add visible focus indicators. Replace any outline: none with a visible, high-contrast focus style.
5. Check contrast. Use a tool like the WebAIM Contrast Checker to verify all navigation text meets 4.5:1.
6. Test with a screen reader. VoiceOver (Mac/iOS), NVDA (Windows), or TalkBack (Android). Navigate the menu by ear.
7. Document your efforts. Publish an accessibility statement. Document known issues and remediation plans.

The goal isn’t to check a box. It’s to build navigation that 100% of your visitors can use—which means more shoppers finding products, more completed purchases, and less legal risk.

This article is part of the larger guide on Navigation accessibility: why 15% of shoppers can’t use your menu.