Making your Shopify navigation WCAG 2.1 AA compliant means anyone can use your menu, whether they shop with a mouse, a keyboard, a screen reader or voice control. It matters because your navigation is on every page, it's usually the most customised part of the store, and if a customer can't get through it they can't reach a single product. It's also a legal requirement in more of the markets you sell into every year.
Accessibility is a revenue question
Plenty of your customers have accessibility needs. ABS figures put it at more than one in five Australians, or 5.5 million people in 2022, and the number is growing as the population ages. Low vision, limited hand movement, tremors and cognitive load all change how a person uses a website.
When a site doesn't work for them, most don't email support. They leave. The UK's Click-Away Pound research found around 70% of shoppers with accessibility needs click away from sites they find hard to use, and they take their spend to a competitor whose site works.
That's the part most brands miss. Accessibility gets filed under compliance, when it's really a conversion problem affecting a slice of your customers big enough to show up in your revenue.
The legal side is catching up
The rules now apply in most markets a scaling Shopify brand sells into.
The European Accessibility Act has covered ecommerce serving EU consumers since 28 June 2025, including businesses based outside the EU, and its technical standard builds on WCAG 2.1 AA. In the US, ADA website claims routinely use WCAG 2.1 AA as the benchmark. In Australia, the Disability Discrimination Act covers goods and services sold online, and the Human Rights Commission points to WCAG as the standard a website is measured against.
None of this means a letter is coming next week. It does mean "we didn't think about it" stops being a defence the moment someone complains.
Why navigation is where stores break
Most accessibility problems on a Shopify store sit in the header. That's no accident.
Your navigation loads on every page, so a problem there blocks every journey. It's also the part brands most often rebuild. Mega menus, featured product panels, promo tiles and multi-level mobile drawers get designed and built custom for global brands, and every custom interaction is another place accessibility can drop out without anyone noticing.
And nobody does notice, because the problems are about behaviour. A menu can look perfect and still be impossible to open without a mouse. Automated scanners are bad at catching this. WebAIM's 2026 review of the top million home pages found detectable accessibility failures on 95.9% of them, and that's only the issues a scanner can see. A menu can pass an automated check and still be unusable for someone on a screen reader.
What an accessible navigation actually does
You don't need to know the code to know what good looks like. An accessible navigation does five things.
| What it does | Who it helps |
|---|---|
| Every menu opens and closes with the keyboard as well as the mouse | Keyboard users, switch users, anyone who can't use a mouse precisely |
| Menus open on click and stay open while you use them | People with tremors or limited movement, and anyone whose cursor drifts |
| You can always see which link you're on | Keyboard users, who otherwise tab through the header with no idea where they are |
| The mobile menu takes the screen reader with it when it opens | Shoppers with low or no vision, on their phones |
| Each menu is named, so the main menu and footer can be told apart | Screen reader users jumping around the page |
The second one deserves a closer look. Hover-only menus are still common on Shopify stores, and they cause problems for far more people than you'd expect. Menus that open on click are easier for everyone, including customers with no accessibility needs at all, because they stop flashing open every time someone moves their cursor across the header. We'd default to click menus on any new build.
How to test your Shopify navigation accessibility in 15 minutes
You don't need a specialist to find most navigation problems. You need a keyboard and the screen reader already built into your phone.
Keyboard test on desktop
Put the mouse away and press Tab from the top of your homepage. Can you always see where you are? Can you open every menu and reach every link inside it? Can you close it again with Escape?
Screen reader test on mobile
Turn on VoiceOver on iPhone or TalkBack on Android and open your menu. When it opens, does the phone start reading the menu, or does it keep reading the page behind it? When you go into a sub-menu, does it read the new options out?
Zoom test
Zoom your browser to 200%. Does the menu still work, or do items overlap and disappear?
If any of these fail, you've found real work. If they all pass, you've cleared the problems customers hit first.
What to ask your agency or dev team
If you're briefing a redesign or reviewing your current store, these questions tell you quickly whether accessibility is being taken seriously.
- Do you test navigation with a keyboard and a screen reader before launch, or only with automated tools?
- Will menus open on click, and work fully without a mouse?
- How will we keep accessibility from breaking when we add promo tiles, apps or new sections later?
- Which WCAG level are you building to, and will you document it?
A good partner answers these without hesitating. If the answer to the first one is "we run a scan", you have your answer.
Where accessibility fits in a project
The cheapest time to get accessibility right is before anything is built. From the project side, that means treating it like any other requirement, with a place in every phase.
Discovery
Agree the standard up front. For most brands that's WCAG 2.1 AA, and it should sit in the scope next to browser and device support, so nobody is surprised by it later.
Design
Designers check the things a customer will see. Text that's readable against its background, menus that open on click, and a clear highlight on whichever link you're on. Fixing these in a design file takes minutes. Fixing them after build takes a ticket, a developer and another round of testing.
QA and sign-off
The keyboard and screen reader tests above become part of sign-off, the same way checking the store on an iPhone is. If the menu fails, the release isn't done.
After launch
Add the same quick test to the checklist for every change that touches the header. That's what stops a store that launched accessible from drifting back out of it.
This is the same thinking behind considered design. The details customers never notice are the ones that decide whether the store works for them.
What keeping your nav accessible actually costs
An accessible navigation doesn't stay that way on its own. It can break next month when someone adds a promo tile, a theme update changes the styling, or a new app adds its own banner to the header. Each of those changes needs a quick keyboard and screen reader check before it goes live, and that's QA time you have to budget into every release that touches the header.
Third-party apps are the part you control least. Chat widgets, review pop-ups and announcement bars bring their own code, and your developers can't fix a vendor's product. If an app doesn't work with a keyboard, you can push the vendor, replace the app, or live with the gap.
And don't expect an accessibility overlay to fix it. Overlay widgets add a toolbar to the page, but they can't change how your menu is built. The real fixes are made in the store's theme by your developers.
The bottom line
Accessible navigation comes down to a simple standard. Every customer should be able to open your menu, see where they are and reach any product, however they use the web. None of it changes how your header looks. All of it changes who can use it. If your design and build partner treats accessibility as part of how the storefront is designed, you get it at build time instead of paying for it after a complaint. Build it into your design system too, so every new section inherits it. A store that only works with a mouse has a locked front door.
Are Shopify themes WCAG 2.1 AA compliant out of the box?
No theme guarantees WCAG 2.1 AA on a live store. Shopify's own themes are a good starting point, but compliance depends on how you customise the theme, which apps you install and how your team adds content. Custom navigation is one of the most common places a compliant theme stops being compliant.
Does WCAG apply to Australian ecommerce stores?
The Disability Discrimination Act covers goods and services sold online, and the Australian Human Rights Commission points to WCAG as the benchmark for accessible websites. There's no certification to get. If someone makes a complaint, WCAG at AA level is the practical test of whether your store is accessible.
Does the European Accessibility Act apply to Shopify stores outside the EU?
Yes, if you sell to consumers in the EU, wherever your business is based. The Act has covered ecommerce since 28 June 2025. Microenterprises are exempt, meaning businesses with fewer than 10 staff and an annual turnover or balance sheet total of no more than EUR 2 million. Get legal advice on your obligations for each market.
Why does website accessibility matter for ecommerce sales?
More than one in five Australians has accessibility needs, and UK research found around 70% of shoppers with accessibility needs leave sites they find hard to use. An inaccessible store loses those customers quietly, without a complaint or a support ticket, to a competitor whose site works.
Should a Shopify mega menu open on hover or click?
Click is the simpler route to WCAG 2.1 AA and usually the better experience for every customer. A hover menu can still be compliant if it also works fully with a keyboard, but it takes more work to build and more testing to keep working.
Can an automated checker test navigation accessibility?
Only partly. Automated tools catch things like missing labels or text that's too low in contrast. They can't tell whether a menu opens with a keyboard or whether a screen reader reads the right thing. Navigation needs a hands-on keyboard and screen reader test.
Do accessibility overlay apps make a Shopify store compliant?
No. Overlays add a toolbar on top of the page, but they can't change how your menu or mobile drawer is built. The fixes that make navigation work for keyboard and screen reader users have to be made in the theme itself.
Flux is a Shopify Plus Agency for Advanced Engineering & AEO
- More than one in five Australians has accessibility needs, and around 70% of those shoppers leave sites they find hard to use.
- Accessibility law now reaches most markets Shopify brands sell into, including the EU, the US and Australia.
- Navigation is where most stores break, because it's on every page and usually custom-built.
- An accessible menu works with a keyboard, opens on click, shows where you are, takes screen readers into the mobile menu and names each menu.
- Automated scans and overlay apps won't catch or fix navigation problems. A 15-minute keyboard and screen reader test will find most of them.
- Accessibility needs rechecking every time the header changes, so budget for it in every release.
