Enrichment · Passion Projects

Put the mouse away.
Try the page.

People who use a keyboard, a switch or a screen reader move through a page one focus stop at a time. Tab through the whole page, try every control, and mark ten checks taken from the Web Content Accessibility Guidelines. Log what broke, the criterion it fails and whether it blocks the task. The checklist sorts out what to fix first.

Pages tested

The worked example is made up: a club sign-up form where the date picker traps focus and the club cards cannot be reached by keyboard at all. Saved on this device only.

Loading the page form. If nothing appears, turn on JavaScript.

What you get

Enrichment · Passion ProjectsFree

What you finish with
A record per page with name, address, date and browser; ten keyboard checks with their WCAG 2.2 criteria, each pass, fail or not present; issues with element, what happened, criterion and severity; a summary. Flags every fail and every issue that blocks the task; counts passes, fails and issues per page.
Who it is for
Students building websites and apps, web design and computer science classes, and anyone checking a school or club site for accessibility.
Format
Browser checklist with a saved record per page. Prints one page’s results for a developer, every page as a table or a blank checklist; downloads a spreadsheet (.csv); exports and imports a file.
Access
Free. No account, no sign-in and nothing to install. Everything you type stays in this browser; nothing is sent to Caveat.
Where it lives
The Passion Projects space in Caveat Enrichment.
Support
Questions about access, an order or a correction: team@caveatacademic.com.

How to use it

  1. Open the page and click in the address bar.
  2. Press Tab through the whole page, watching where focus goes.
  3. Try every menu, form field, button and dialog with the keys.
  4. Mark each check and log each problem as an issue.
  5. Write a two-sentence summary that names the most urgent fix.

Test a page

The keys

Keys to test withTabnext controlShift + Tabprevious controlEnterfollow a link, press a buttonSpacepress a button, tick a boxArrowsmove inside menus, tabs, radiosEscapeclose a menu or dialogOn a Mac, Safari skips links on Tab until you turn on “Press Tab to highlight eachitem” in its settings.Keys to test withTabnext controlShift + Tabprevious controlEnterfollow a link, press a buttonSpacepress a button, tick a boxArrowsmove inside menus, tabs, radiosEscapeclose a menu or dialogOn a Mac, Safari skips links on Tabuntil you turn on “Press Tab tohighlight each item” in its settings.
These are the keys keyboard and switch users depend on. If one of them does nothing where it should, log it as an issue.

Why it matters

Many people never use a mouse: people with motor disabilities, many blind people using screen readers, people using switches or voice control, and anyone with a broken trackpad. If a control cannot be reached or used from the keyboard, it does not exist for them. Keyboard testing is free, fast and finds some of the most serious problems.

The rules, in general

WCAG 2.2 Level AA is the reference most accessibility rules point to. In 2024 the U.S. Department of Justice issued a rule under Title II of the Americans with Disabilities Act that sets WCAG 2.1 AA as the standard for state and local government websites, including public schools, with compliance dates starting in 2026. Section 508 covers federal agencies.

Sources

  1. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2 (w3.org/TR/WCAG22).
  2. W3C Web Accessibility Initiative. ARIA Authoring Practices Guide: keyboard interaction patterns (w3.org/WAI/ARIA/apg).
  3. U.S. Department of Justice. Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps under ADA Title II (ada.gov).
  4. WebAIM, Utah State University. Keyboard Accessibility (webaim.org).

The worked example is made up. A keyboard test finds many problems but not all; screen reader and automated tests find others. Nothing you type is sent to Caveat. Support: team@caveatacademic.com.