Keyboard access and focus: navigation, dialogs and cookie banners

Keyboard access works when users can reach every function without a mouse, identify their current focus and continue meaningfully after each action. For navigation, dialogs and cookie banners, that means appropriate native elements, a logical sequence, visible focus indicators and clearly defined focus changes. Do not simply check whether an element responds to Tab. Check whether a complete task succeeds: opening a menu, selecting a destination, changing settings, confirming and returning to the original activity.

This guide translates those requirements into interaction decisions and concrete acceptance tests. All application scenarios described here are hypothetical examples, not documented client outcomes. The recommendations address product owners, designers, developers and quality assurance teams. Content reviewed on 7 November 2026. A technical test produces substantiated findings for the scope examined; it does not replace a complete conformity assessment or a legal review.

1. Test a task first, not individual keys

Start with a realistic journey. For example, someone visits a hypothetical event shop, rejects optional cookies, opens the main navigation, finds an event and reads its participation conditions in a dialog. This journey connects several components. Each might work in isolation while the transition fails: closing the dialog could send focus to the top of the page rather than the triggering link. Users then have to find their position again.

Before implementation, describe the starting state, the action and the expected outcome. Always record the expected focus location too. “Dialog closes” is insufficient for acceptance; a better description is “Escape closes the dialog, focus returns to the triggering button, and the next Tab step follows the page order.” Include forward and backward navigation and at least one cancellation route. This turns a vague requirement into a reproducible test that different people can perform consistently.

2. Native elements and a logical sequence

A link takes users to a destination; a button performs an action. This distinction already provides much of the keyboard behaviour: native buttons generally respond to Enter and Space, while links respond to Enter. A clickable text container does not automatically acquire that behaviour through an ARIA role. Its state, focusability and event handling must also work together. Before building a custom control, check whether an existing HTML element reliably serves the purpose.

The Tab sequence should emerge from a meaningful document structure. Positive tabindex values often create a second, hard-to-maintain order alongside the visual layout. Do not use them to repair a poorly structured layout. Deliberately managed focus models can, however, make sense for composite widgets. The WAI-ARIA Authoring Practices Guide: Developing a Keyboard Interface explains the distinction between Tab navigation and movement within these components. These are implementation resources, not an additional WCAG conformance level.

3. Main navigation: a website menu is not automatically an ARIA menu

Ordinary website navigation usually consists of links, sometimes accompanied by buttons that reveal additional links. It frequently does not require an ARIA menu with its own arrow-key model. In a hypothetical header, “Services” might link to an overview page while an adjacent, clearly named button opens the subpages. Alternatively, a single button could open the list. What matters is that users do not have to guess whether a control navigates somewhere or expands something.

Test both the closed and open states. The trigger must communicate its state programmatically, for example through aria-expanded. Hidden sublinks must not accidentally remain in the Tab sequence. Once opened, the available destinations must be reachable; when Escape closes the component as specified, focus must not disappear into hidden content. Also test a transition between mobile and larger layouts: a previously opened mobile menu must not leave an invisible background blocker behind. Acceptance evidence should document the same successful navigation journey in both views.

4. Keep focus visible, including beneath sticky headers

A visible focus indicator continuously answers the question: “Where would my next input take effect?” Do not remove the browser’s focus outline without providing a replacement. Design an indicator that remains recognisable on light and dark surfaces, next to error messages and within selected states. Focus and selection are different: an already selected navigation item still needs a distinguishable focus treatment when users reach it with the keyboard.

WCAG 2.2 includes criterion 2.4.11, “Focus Not Obscured (Minimum),” at Level AA. A focused component must not be entirely hidden by author-created content. Full visibility goes beyond that minimum and is a sensible project target. “Focus Appearance,” by contrast, belongs to AAA, not AA; the W3C overview of what is new in WCAG 2.2 explains these criteria. Test sticky headers, fixed action bars and cookie banners together. A hypothetical jump to a form field might place it underneath the header; appropriate scroll spacing and checks for dynamic header heights address this more reliably than a fixed offset designed for just one layout.

5. Skip links must change the next working step

A skip link to the main content avoids repeated journeys through extensive navigation. Place it early in the focus sequence and make it visible when focused. Its destination should be a meaningful start to the main content, not an arbitrary container halfway down the page. A visible scrolling movement alone does not prove that keyboard navigation now continues from the correct position.

Immediately test the next Tab step after activation. It should reach the next meaningful interactive element in the main content rather than returning through the header. Depending on the implementation, the destination may need tabindex with a value of minus one to receive programmatic focus without becoming an additional regular Tab stop. Repeat the test on a long content page and with an enlarged display. Record the destination, actual focus location and immediately following control as acceptance evidence.

6. Modal dialogs: entry and a contained focus area

A modal dialog interrupts work in the background. Its technical implementation must therefore reflect that interruption: the background is unavailable for interaction, the dialog has an accessible name and focus moves to an appropriate location inside it. For a short confirmation, that might be a button. For lengthy terms and conditions, a heading or introductory passage is often more appropriate initially, so that the visible beginning is not skipped.

Tab and Shift+Tab remain within the open modal dialog. aria-modal alone does not create this behaviour. Even with a native dialog, you must check its name, initial focus and integration. The WAI-ARIA Authoring Practices Guide: Dialog (Modal) Pattern describes the relevant decisions. Pay particular attention to long content: every action must remain reachable, the content must be operable or scrollable, and a fixed dialog footer must not obscure focused content. A screenshot of the open dialog is not sufficient evidence.

7. Leave dialogs without losing the working context

Intentional focus containment within a modal dialog is not a keyboard trap when there is an understandable, keyboard-operable exit. Plan a named Close or Cancel button and dismissal with Escape. If a critical operation requires confirmation, design the exit explicitly rather than silently ignoring input. A second dialog over the first increases complexity; avoid such nesting when a simple view can serve the same purpose.

After closing, focus normally returns to the trigger. If that trigger no longer exists, there must be a logical alternative destination. In a hypothetical deletion dialog, a table row is removed; the next available row action or the table heading might then be appropriate. Document this decision in advance. Test confirmation, cancellation, Escape and any server-side errors separately. An error must not unexpectedly close the dialog or send focus to a removed DOM node. Acceptance evidence records the focus location for each outcome.

8. Cookie banners: consent without blocking operation

First decide whether your consent interface is genuinely modal. A nonmodal notice must not contain focus like a dialog; a genuinely modal settings dialog must make the background unavailable accordingly. This distinction is often blurred. One hypothetical failure is a banner at the bottom of the screen behind which users can still focus links without seeing them. Another is an invisible overlay that remains after a choice has been made.

Test every available route: rejecting optional cookies, accepting them, opening settings, changing categories and saving a selection. Buttons need unambiguous names, and switches need understandable states. After closing, focus must not remain associated with a removed banner button. If the dialog was opened through “Cookie settings,” returning there makes sense. An initially displayed banner needs a justified continuation within the page context. Also check reopening it later. Keyboard accessibility evaluates operation here; whether consent has been designed to be legally valid under data protection law remains a separate review task.

9. Accordions: keep state, content and focus together

For an ordinary accordion, a button inside an appropriately structured heading is suitable. Its name identifies the section, and its expanded state indicates whether the associated content is open. Enter and Space toggle the section; Tab moves to subsequent controls. Optional arrow-key navigation should only be used when it is implemented and tested consistently. It does not replace basic reachability with Tab.

A common hypothetical failure occurs when a section is collapsed only visually while its links remain focusable. Users then move through invisible content. Another failure occurs when code closes a region that currently contains focus. In that case, provide a meaningful return to the section button. Acceptance testing opens several sections, visits a link inside one, closes the region and checks the subsequent focus sequence. Also verify that the heading structure and accessible states survive dynamically loaded content.

10. A compact, reproducible keyboard acceptance test

Complete a pass without a mouse and record the browser, operating system, viewport size, zoom level and starting state. On systems with restricted default keyboard navigation, the relevant settings must be understood. Repeat critical journeys with a browser and assistive technology combination selected for a stated reason. A keyboard-only test does not reveal every accessible name or all screen reader issues. Conversely, a correct announcement alone does not prove that focus management is usable.

1. Reach the skip link, navigation and main action with Tab, and move backwards with Shift+Tab.
2. Activate links with Enter and buttons with both Enter and Space; watch for unexpected scrolling.
3. Open and close subnavigation, accordions, consent settings and modal dialogs.
4. After every state change, check focus location, visibility and access to the next step.
5. Repeat the journey with long content, an enlarged display and fixed page elements.

For each failure, capture the shortest reproducible key sequence. “Focus broken” offers little help; “after Escape closes Cookie settings, focus is at the document start instead of the trigger” creates a verifiable correction task. After the repair, run exactly the same sequence again.

11. Embed evidence and responsibility in the project

A useful test record connects the component, state, expected behaviour, actual result and retest. Where helpful, add a short screen recording with a visible focus indicator and a description of the keystrokes. Automated checks can identify certain structural problems, but they do not replace this interaction testing. Store the accepted focus rules in your component library so that a new menu or an updated consent service does not reintroduce the same failures.

If WCAG 2.2 AA is your assessment target, it includes all applicable Level A and AA criteria, not only the focus issues discussed here. The authoritative requirements are the Web Content Accessibility Guidelines (WCAG) 2.2. EN 301 549 is not interchangeable with them. Austria’s BaFG has applied to covered services since 28 June 2025, not automatically to every website. For scope and exemptions, use our guide to accessible websites in Austria rather than inferring complete legal compliance from a successful keyboard test.

12. Frequently asked questions and your next step

Is it enough if everything can be reached with Tab?

No. Functions must also be operable, states must remain understandable and focus changes must work meaningfully. Invisibly focusable links or a dialog without an exit fail even when Tab stops are present.

Must focus always be completely visible?

WCAG 2.2 criterion 2.4.11 at Level AA requires focused components not to be entirely hidden by author-created content. Full visibility is the more robust project target; other applicable criteria still need assessment.

Is focus containment always a keyboard trap?

No. It is intentional in a modal dialog. An operable exit and a meaningful focus position after closing are essential. A nonmodal notice should not restrict navigation in this way.

What should you prepare for an audit?

Provide core user journeys, test accounts, the components in use and known problem areas. States that cannot be linked to directly are especially useful, including errors, open dialogs and saved consent settings.

Zensations, a digital studio founded in Vienna in 2010, helps you assess these interactions systematically and translate corrections into design and development work. An accessibility audit can examine an agreed scope and provide traceable findings. If you subsequently want to develop components or processes further, explore our accessibility services. A practical starting point is a jointly selected user journey with clear acceptance criteria, rather than a promise of blanket conformity.

Primary sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — normative success criteria.
• WAI-ARIA Authoring Practices Guide: Developing a Keyboard Interface — focus and keyboard models.
• WAI-ARIA Authoring Practices Guide: Dialog (Modal) Pattern — implementing modal dialogs.
• W3C: What’s New in WCAG 2.2 — context for the new requirements.