how to
How to make a mobile navigation accessible (WCAG 2.2 AA)
An accessible mobile navigation is a mobile navigation that meets WCAG 2.2 Level AA — operable by keyboard alone, properly announced by screen readers (NVDA, JAWS, VoiceOver, TalkBack), with visible focus indicators, sufficient colour contrast, and the correct ARIA semantics where native HTML is insufficient.
What WCAG criteria apply to a mobile navigation?
The minimum applicable success criteria are 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum), 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, 4.1.2 Name, Role, Value, and 4.1.3 Status Messages.
Keyboard interactions
A mobile navigation must be operable with only keyboard input. Tab to focus; Enter/Space to activate; Escape to dismiss where applicable; arrow keys within composite widgets per the ARIA Authoring Practices Guide.
Screen reader behaviour
The role of the mobile navigation must be announced (e.g. "button", "dialog", "menu"); its state ("expanded", "selected", "checked") must be communicated; and any updates must be announced via live regions if focus does not move to them.
Focus management
On mount, focus stays where the user was. On activation (e.g. opening a dialog), focus moves into the new context. On dismissal, focus returns to the trigger. Focus must not be trapped silently outside an explicitly modal context.
Common failures and how to avoid them
Building a mobile navigation from div + onClick instead of a native element — fails 4.1.2. Removing the focus outline without replacement — fails 2.4.7. Auto-opening behaviour without user trigger — frequently fails 3.2.5 Change on Request.
Reference implementations
react-aria (Adobe), Radix UI, Headless UI, and the W3C ARIA Authoring Practices Guide each publish accessibility-tested mobile navigation patterns. Use them rather than building your own.
FAQ
Frequently asked questions
Cited answers. Sourced. Updated as standards and case law change.
What is the correct ARIA role for a mobile navigation?
The ARIA Authoring Practices Guide (apg.w3.org) lists the recommended role and keyboard pattern for mobile navigation and other common widgets. In most cases the native HTML element (where one exists) is preferable to manually-applied ARIA.
Can a mobile navigation pass WCAG without ARIA?
Sometimes — when a native HTML equivalent exists. The first rule of ARIA is "do not use ARIA": native HTML communicates more semantics than custom ARIA in most cases.
How do I test a mobile navigation for accessibility?
Combine: keyboard-only traversal, NVDA + Chrome screen reader pass, axe-core automated scan, visible focus indicator check, contrast measurement, and 200% browser zoom test.
Stop guessing. Get the audit a Fortune 500 a11y team would have written.
Free audit on your live URL. No sign-up. IAAP-format report. Ready in hours.
founders@accessivepath.com · +977 9851094056