Our team in Mexico just started doing structured keyboard-only testing as part of our accessibility regression suite. We’re covering the obvious stuff — Tab order, Enter/Space on buttons, Escape to close modals.

But I keep feeling like we’re missing things. Would love to crowdsource a more complete checklist from people who do this regularly.

Here’s what we currently check:

  • All interactive elements reachable via Tab / Shift+Tab
  • Visible focus indicator present at all times
  • Forms submittable without a mouse
  • Modals trap focus correctly and return focus on close
  • Skip navigation link present and functional
  • Dropdowns operable with arrow keys

What are we missing?

Particularly interested in edge cases around:

  • Single page app routing — focus management when the “page” changes
  • Custom components like date pickers and data tables
  • Toast/notification interactions
  • perangkat_lunakEnglish
    0·
    2 months ago

    Good list. A few things I’d add from our testing standards in indonesia:

    • Timeout warnings — if your app has session timeouts, can a keyboard user dismiss the warning and extend the session in time?
    • Drag and drop alternatives — anything with drag-and-drop UI needs a keyboard-accessible alternative. Often completely forgotten.
    • Autocomplete/combobox patterns — these are notoriously broken. Test whether results can be navigated with arrow keys and selected with Enter.
    • perangkat_lunakEnglish
      0·
      2 months ago

      For SPA routing specifically — the accepted pattern is moving focus to either the new page <h1> or a skip link after navigation. Most teams just… don’t do this. It’s a significant failure for screen reader users but keyboard-only users are also affected.