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
  • pakistani_tester1947English
    0·
    2 months ago

    The one that gets missed most often in my experience: focus returning correctly after a dynamic UI change.

    Close a modal → focus goes to the button that opened it ✅ Submit a form and get a validation error → focus moves to the error summary ✅ Delete an item from a list → focus goes… somewhere reasonable ✅

    • definitelydevelopingMEnglish
      0·
      2 months ago

      That last one is where it usually falls apart. What’s “somewhere reasonable” requires a judgment call and devs rarely think about it.

      Also: pointer-events: none and visibility: hidden don’t always remove elements from tab order the way devs think they do. Worth explicitly testing hidden/off-screen content isn’t focusable.