Keyboard Navigation
// Definition
The ability to operate all interactive elements of a user interface using only a keyboard — Tab to move between focusable elements, Enter/Space to activate controls, arrow keys within composite widgets, and Escape to dismiss overlays. WCAG 2.1 Success Criterion 2.1.1 requires that all functionality is operable via keyboard. QA testers verify keyboard navigation by tabbing through a page without a mouse, confirming a visible focus indicator appears on every focusable element, the tab order follows the logical reading order, and no keyboard trap prevents a user from moving forward or escaping a component.
// Why it matters
Everything must work without a mouse — keyboard users, screen-reader users, and many motor-impaired users depend on it. QA cares because it's both a legal requirement and a frequent break point: custom widgets, modals, and SPAs routinely trap focus or skip interactive elements. It's testable with nothing but the Tab key.
// How to test
// Tab order, focus visibility, no traps
cy.visit('/signup')
cy.get('body').tab() // (cypress-real-events / plugin)
cy.focused().should('have.attr', 'data-cy', 'email') // logical first stop
cy.focused().tab()
cy.focused().should('have.attr', 'data-cy', 'password')
// Modal must trap focus while open, and restore it on close
cy.get('[data-cy=open-modal]').click()
cy.focused().should('exist') // focus moved into the modal
cy.get('body').type('{esc}')
cy.focused().should('have.attr', 'data-cy', 'open-modal') // focus returned// Common mistakes
- Focus order that doesn't match visual order (jumps around the page)
- No visible focus indicator (or
outline: nonewith nothing replacing it) - Modals/menus that trap focus and never release, or never receive it
// Related terms
Focus Management
The practice of programmatically controlling which element receives keyboard focus in response to user interaction or content changes — particularly when opening and closing dynamic UI components such as modals, drawers, toast messages, and single-page navigation. Correct focus management ensures that keyboard and screen-reader users are always aware of their position in the interface. QA testers verify that opening a modal moves focus into it, focus is constrained within the modal while it is open (a deliberate focus trap), closing the modal returns focus to the triggering element, and client-side navigation moves focus to the new page heading or a skip target.
Accessibility
The practice of designing and testing software so it is usable by people with a wide range of abilities — including users who rely on screen readers, keyboard navigation, voice control, switch access, or high-contrast display modes. In QA, accessibility testing involves both automated scanning and manual verification. Automated tools (axe, Lighthouse, Accessibility Scanner for Android, Accessibility Inspector for iOS) catch structural issues such as missing labels, insufficient colour contrast, and incorrect ARIA roles — typically around a third of all accessibility issues. The remaining two-thirds require testing with actual assistive technologies: VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on Windows. WCAG 2.1 AA is the most widely referenced standard; Level AA compliance is required by law in many jurisdictions (ADA, EN 301 549, AODA). Integrating accessibility checks into CI — for example, running axe as part of a Playwright or Selenium test suite — prevents regressions from being merged undetected.
WCAG
Web Content Accessibility Guidelines — the international standard for accessible web content, organised into four principles (Perceivable, Operable, Understandable, Robust). Levels A, AA, and AAA define increasing conformance. Most regulations target WCAG 2.1 or 2.2 Level AA.