Accessibility for an agent building and testing interfaces

What this project commits to, what gets verified, and where an agent should stop. The design system rootnote covers the component-level rules; this covers the commitment itself and how it is checked.

General accessibility practice is deliberately not restated here. A current model already knows that a button should be a button, that placeholders are not labels, and that “click here” is poor link text. Repeating it costs context on every session and changes nothing. What follows is only what this project has decided, which no model can know.

The blind spot that makes this a commitment rather than a checklist

An agent produces markup that looks correct and is semantically empty, and it cannot see the difference — the same blind spot as a sighted developer using a mouse, with no equivalent of the moment you try the keyboard and it fails.

So this is stated as a commitment with verification attached, rather than left to care at the time.

The commitment

Standard: {{accessibility_standard}}. Not aspirational — this is the level work is expected to meet, and falling short of it is a defect rather than a future improvement.

Tested against: {{assistive_tech_support}}. State what is genuinely tested rather than what is theoretically supported. “Works with screen readers” is a claim nobody has verified; naming the specific combinations is one somebody can.

What is actually required before merge

Automated checks catch perhaps a third of it. Run them — they find contrast, missing names and structure reliably — and then stop believing them, because what they cannot detect is whether focus order makes sense, whether an announcement is comprehensible, and whether the task is completable without sight.

The rest is three manual passes, none of which takes more than a minute:

• Keyboard only. Complete the task with the mouse down.
• Screen reader. Complete the same task listening rather than looking.
• 200% zoom, narrow viewport. Nothing cut off, no horizontal scrolling.

The point of naming them is that they are required here, not optional diligence.

Where to stop and ask

• Relaxing any of the above. An accessibility rule is a commitment with legal weight in most jurisdictions, and it is never a tidiness matter. If a rule is blocking something, that is a conversation.
• Shipping a known failure, which is sometimes the right call under time pressure but is a decision with an owner and a record, not a quiet omission.
• Adding a third-party component or embed, which brings its own accessibility — usually unverified, and inherited by you.
• Introducing a custom interactive control where a native element exists. Almost always the wrong trade, and always worth arguing for explicitly.

Why this survives pressure

The people affected mostly will not tell you. They will fail to complete the task and leave, and it will register as a conversion problem rather than an accessibility one.

So the only reliable signal is checking, which is why this document is about verification rather than intent. An intention to be accessible produces almost nothing; a keyboard pass before merge produces most of it.