The Workbench · The Shelf
A mouse-only interface fails WCAG at Level A
This blog has already covered what “browser-only” actually promises about where a tool's data goes, and what it owes a visitor's in-progress answers between visits. Neither question touches a more basic one: can a visitor actually operate the tool at all? The Web Content Accessibility Guidelines answer that at two different levels, and the lower one isn't a stretch goal sitting below a nicer-to-have AA. Level A is the floor a classification decider or a cross-border tracker fails before any conversation about color contrast or focus rings even starts.
AA is additive, not a harder version of A
WCAG's conformance levels don't describe the same list graded on a curve. Meeting Level AA means meeting every Level A success criterion, plus a further set of criteria that AA adds on top — it isn't a stricter restatement of the Level A list. A tool that passes every color-contrast and focus-styling check an AA audit would run, while still being unusable from a keyboard, hasn't half-met the standard. It has met the half that was never going to be checked first.
Keyboard operability is Level A
Success Criterion 2.1.1, Keyboard, requires that all of a page's functionality be operable through a keyboard interface, with no requirement that the operation happen at any particular speed. It sits at Level A — the minimum WCAG defines, not an enhancement layered on afterward. A classification decider built as a set of clickable cards with no keyboard handler behind them, or a cross-border tracker whose “add a row” control only responds to a pointer event, fails this criterion outright. Nothing about how its colors test changes that, because 2.1.1 was never a color question.
Labels and error text are Level A too
Success Criterion 3.3.2, Labels or Instructions, requires a label or instruction wherever a page asks for input. Success Criterion 3.3.1, Error Identification, requires that when an input error is detected automatically, the item in error is identified and the error described to the user in text. Both sit at Level A, alongside keyboard operability, not waiting in AA. A form field that marks a bad entry with only a red border and no accompanying text has failed a Level A criterion before any AA review of its color choices becomes relevant — and conveying the error by color alone fails a second criterion on its own separate terms.
What the floor rules out, before the ceiling gets interesting
Section 508 and a number of public-sector procurement standards treat WCAG Level AA as the governing bar for software bought by the institutions that hold to them, and AA has always folded A in as a prerequisite rather than offered it as an alternative path. For a shelf of tools built for regulatory and quality teams, several of whom work inside institutions holding to exactly that standard, treating Level A as a later polish pass gets the order backwards. A tool can't earn AA credit for color contrast it never had the chance to apply, because the keyboard path that would have reached the control in question never worked to begin with.
A mouse demo is the wrong way to check this
The failure mode is easy to miss precisely because it's invisible to the way most teams actually test a tool: open it, click through it, confirm the right answer comes out the other end. A demo run entirely by mouse can pass every informal review a team runs on it and still fail 2.1.1 outright, because nobody driving the demo ever tried to reach the “next” button with Tab or activate a card with Enter or Space. The only way to actually check keyboard operability is to try it — unplug the mouse, or simply stop touching it, and walk the same path with Tab, Shift+Tab, Enter, and the arrow keys a native select or radio group expects. A tool that's never been reviewed that way hasn't been checked against 2.1.1 at all; it's been checked against a narrower standard that happens to look similar from behind a mouse.
Where this meets the build
The interactive tools previewed under the launch catalog's tools section — the classification decider, the timeline estimator, the RTA readiness scorer now in build — are built keyboard-first: every control reachable and operable without a pointer, checked before any of them are tuned for contrast or focus-ring styling. If one of them ever falls short of that floor, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.