How do you test keyboard navigation and focus management in a web application?

The test process — done with a physical keyboard only:

1. Tab order: Tab through every interactive element on the page. The tab order should follow a logical reading order (top-to-bottom, left-to-right in LTR languages). Elements with tabindex="0" join the natural flow; elements with positive tabindex values (bad practice) create a custom order.

2. Focus visibility: every focused element must have a visible focus indicator — an outline, ring, or other visual signal. WCAG 2.2 (success criterion 2.4.11) requires a minimum focus indicator size and contrast. Look for outline: none in CSS — a very common accessibility failure added by developers who find the default outline visually unpleasant.

3. Interactive elements: activating a button or link with Enter should produce the same result as clicking it. Checkboxes and radio buttons respond to Space. Custom dropdowns and date pickers should follow the ARIA Authoring Practices Guide keyboard patterns for their widget type.

4. Keyboard traps: Tab must never get stuck inside a component that isn't a modal dialog. If pressing Tab inside a widget cycles within it without any escape route, that's a keyboard trap (WCAG 2.1.2).

5. Focus management on dynamic actions: opening a modal should move focus inside it; closing the modal should return focus to the trigger element. Adding a dynamic section to the page may need a focus shift to that section.

Tools: the browser's Accessibility pane shows focus order; the Tab key in the browser's focus mode cycles through focusable elements. Add an automated check using Playwright's page.keyboard.press('Tab') to verify focus reaches key elements.