Focus Trap
// Definition
Deliberately confining keyboard focus within a region — correct inside an open modal (Tab should cycle within it, not escape to the page behind), but a serious bug anywhere else (a user who can't Tab out is stuck). The accessible pattern: trap focus while a modal is open, restore it to the trigger on close.
// Why it matters
Focus trapping is a two-sided QA concern: its absence in modals lets keyboard users tab into the obscured page behind (confusing, broken), while an unintended trap anywhere strands the user entirely. Both are WCAG failures. Testing it needs nothing but the Tab key, so there's no excuse to skip it.
// How to test
// Modal: focus must stay inside while open, return to trigger on close
cy.get('[data-cy=open-modal]').click()
cy.focused().should('be.visible') // focus moved into modal
// tab through every focusable, confirm it cycles and never leaves the modal
cy.get('body').type('{esc}')
cy.focused().should('have.attr', 'data-cy', 'open-modal') // restored to trigger
// Anti-test: NO region outside a modal should trap focus// Common mistakes
- Modals that don't trap focus (Tab escapes to the page behind)
- Traps that never release, stranding keyboard users
- Not restoring focus to the trigger element when the modal closes
// Related terms
Keyboard Navigation
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.
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.
ARIA (Accessible Rich Internet Applications)
A W3C specification that adds roles, states, and properties to HTML elements to expose semantics to assistive technologies when native HTML alone is insufficient. The first rule of ARIA is: do not use ARIA — prefer native HTML elements (button, input, nav) that carry the correct semantics implicitly. Incorrect ARIA can make an interface less accessible than no ARIA at all. QA testers check that ARIA roles match the component's actual behaviour, required states (aria-expanded, aria-selected, aria-checked) update dynamically, and aria-label or aria-labelledby provides meaningful names for elements that lack visible text.