Keyboard Navigation

8 inlägg

WCAG Success Criteriawcag-2.2-A

WCAG 2.1.2: No Keyboard Trap

WCAG 2.1.2 requires that keyboard users are never trapped inside a component — if focus can be moved into a UI element using a keyboard, it must also be possible to move focus away using only the keyboard. This criterion is essential for users who rely exclusively on keyboard navigation, including people with motor disabilities and screen reader users.

WCAG Success Criteriawcag-2.2-A

WCAG 2.4.1: Bypass Blocks

WCAG 2.4.1 requires that web pages provide a mechanism to skip repeated blocks of content, such as navigation menus, so keyboard and assistive technology users can reach main content without tabbing through every link. This is a Level A requirement, meaning it is the baseline for accessible keyboard navigation.

WCAG Success Criteriawcag-2.2-A

WCAG 2.4.3: Focus Order

WCAG 2.4.3 requires that if a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components must receive focus in an order that preserves meaning and operability. This criterion is essential for keyboard and assistive technology users who rely on a logical, predictable focus sequence to understand and interact with content.

WCAG Success Criteriawcag-2.2-A

WCAG 3.2.1: On Focus

WCAG 3.2.1 On Focus requires that when any user interface component receives keyboard focus, it must not trigger an unexpected change of context. This protects keyboard and assistive technology users from disorienting, unpredictable behavior that can make a page impossible to navigate effectively.

WCAG Success Criteriawcag-2.2-AA

WCAG 2.4.7: Focus Visible

WCAG 2.4.7 requires that any keyboard-operable user interface has a visible focus indicator so users can always see which element currently has keyboard focus. This is essential for keyboard-only users, people with motor impairments, and anyone who cannot use a mouse.

WCAG Success Criteriawcag-2.2-AA

WCAG 2.4.11: Focus Not Obscured (Minimum)

WCAG 2.4.11 requires that when a UI component receives keyboard focus, it is not entirely hidden by author-created content such as sticky headers, cookie banners, or chat widgets. This criterion ensures keyboard users can always see where they are on the page, which is essential for navigation and usability.

WCAG Success Criteriawcag-2.2-AAA

WCAG 2.4.12: Focus Not Obscured (Enhanced)

WCAG 2.4.12 requires that when a UI component receives keyboard focus, no part of that component is hidden by author-created content — the focused element must be fully visible. This enhanced (AAA) criterion eliminates the partial-visibility allowance of its AA counterpart, ensuring keyboard users always see exactly where focus is.

WCAG Success Criteriawcag-2.2-AAA

WCAG 2.4.13: Focus Appearance

WCAG 2.4.13 requires that keyboard focus indicators meet minimum size and contrast requirements so that users can clearly see which element has focus. This criterion ensures that people who rely on keyboards or assistive technologies can navigate interfaces without losing track of their current position.