how to
How to make a dropdown menu accessible (WCAG 2.2 AA)
An accessible dropdown menu is a dropdown menu 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 dropdown menu?
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 dropdown menu 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 dropdown menu 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 dropdown menu 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 dropdown menu 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 dropdown menu?
The ARIA Authoring Practices Guide (apg.w3.org) lists the recommended role and keyboard pattern for dropdown menu and other common widgets. In most cases the native HTML element (where one exists) is preferable to manually-applied ARIA.
Can a dropdown menu 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 dropdown menu 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