What should I test first with keyboard-only?

Start with focus visible and focus order. Then verify activation (Enter/Space) for each control, and finally check modals and custom widgets.

Are skip links enough to pass keyboard checks?

Skip links help, but they only cover one navigation shortcut. You still need a complete keyboard path through all interactive features.

How should we document results?

Record where the failure happens (page/section), what the keyboard behavior is, and what the expected behavior should be. Keep notes thematic so it maps to your action plan.

Keyboard-only accessibility testing checklist (RGAA)

Keyboard-only testing is often the fastest way to find “real usability” blockers. Use this checklist to validate focus visible, focus order, activation, modals, and custom components.

1) Focus visible & focus order

Every interactive element shows a clear focus indicator.
Focus moves in a predictable order (top-to-bottom, left-to-right).
No focus “teleporting” between unrelated sections.

2) Activation: Enter and Space

Links behave like links and buttons behave like buttons.
Custom clickable components respond to the keyboard (Enter/Space as appropriate).
Disabled states are communicated and do not trigger unexpected actions.

3) Skip links and landmarks (start of the path)

Use the skip link to jump to the main content.
Verify it works consistently after page load and after closing overlays.
Check you can reach the same navigation options without the mouse.

4) Modals, popups, and focus management

Modals are where keyboard testing usually finds the biggest issues.

Open the modal with the keyboard and confirm focus lands inside it.
Use Escape (or the visible close control) to close and confirm focus returns to the opener.
Tab navigation should not “escape” the modal while it is open.

5) Custom widgets (menus, carousels, accordions)

Verify keyboard behavior is consistent across states (open/closed, hover/active).
Confirm the widget has an accessible name and exposes the correct role.
Ensure content updates are understandable (at least visually and ideally through announcements).

Quick documentation template

Page/section: …
Control: … (button/link/menu item)
Keyboard step: what keys you pressed.
Observed behavior: what actually happens.
Expected behavior: what should happen.
Suggested fix: short technical direction or component-level ownership.

Quick checklist (before publishing)

Focus is visible for all interactive controls.
Focus order is logical on representative pages.
Activation works for custom components (not only native controls).
Modals manage focus and do not trap incorrectly.
Your notes map to your action plan (thematic and component-based).

Where RGAAudit.com helps

RGAAudit.com can accelerate your preparation by running an automated RGAA 4.1.2 scan and organising findings by theme. Keyboard-only checks remain essential for manual validation and real-world usability.

Next step: use the DINUM accessibility statement checklist to publish with confidence.