The OSBR Handbook
Sign in

Accessibility

We put accessibility at the start of the experience, not at the end of it. This page sets the floor every OSBR product clears for the people who use it, and it extends that same floor in a direction many teams still skip: a product that is genuinely reachable must be reachable by AI agents too — as operators acting on a user's behalf, and as consumers of the information the product holds. It builds on the concrete rules in the Design Guidelines, shares its machine-access half with Building for AI Users, and is held to work by the Quality Gate's review. Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and justified in the project's design notes.

Accessibility is where our values meet the person, or agent, actually in front of the product. Be Nice: meet people through the tools they already rely on — a screen reader, a keyboard, an agent — rather than the one input we happened to design for. Be Kind: assume the user reaching for a feature may be a person or the AI acting for them, and let both in without a fight. Be Strong: hold a real, tested floor rather than "accessible enough" — the failure we guard against is invisible to the person who never has to hit it. This commitment runs through human ⇄ AI cooperation the same way it runs through human use.

How to read this policy

1. Goal

Every OSBR product is usable, from the first interaction, by:

without either being forced to reverse-engineer a UI built only for a sighted mouse user. Accessibility is designed in at the start, not bolted on as late-stage polish.

The reasoning is one idea, not two. An interface that states its meaning and its operations explicitly — semantic structure for people, declared tools for machines — is reachable by whoever, or whatever, shows up. A screen reader and an AI agent both consume a product through its stated structure, never its pixels; build well for the one and you have most of the other. This is the inclusive-design bargain: designing for the edges makes the centre better for everyone.

2. Responsibility

3. Practices

3-1. Accessibility comes first, not last

Accessibility is a starting constraint, alongside "does it work" — never a finishing touch. A control that cannot be reached by keyboard, or an image with no text alternative, is an unfinished feature, exactly as a broken button is.

3-2. WCAG 2.2 AA is the floor

WCAG 2.2 AA is the minimum, not the target — the target is a product people actually find easy. 2.2 is the current W3C Recommendation and supersedes 2.1; the handbook is standardized on 2.2 AA, and the Design Guidelines carry the concrete rules that meet it.

3-3. Verify with a screen reader and keyboard — not just a linter

Automated checkers (axe, Lighthouse) catch perhaps a third of issues. They cannot tell us whether a flow makes sense announced aloud or driven by Tab alone — and that is the part that decides whether the product is actually usable.

3-4. Build from semantic HTML; ARIA only to fill gaps

Native semantic elements carry role, state, focus, and keyboard behaviour for free. We reach for them first.

3-5. Open operations to AI agents

Where a product performs real operations — search, create, update, submit, query — we expose those operations as machine-callable tools so an AI agent can operate the product and read its information without scraping the DOM or guessing from screenshots. This is the same accessibility problem as a screen reader operating the product: meaning must be stated, not painted. The full agent-facing standard lives in Building for AI Users; this page states the floor it shares with human accessibility.

Same principle, one rung further: declared tools serve the machine consumer the way semantic HTML serves the assistive-technology consumer.

References

Accessibility standards & guidance

Verification

Machine access (AI agents)

Related handbook pages