Open infrastructure for accessible software

Accessibility that software can understand

Accessibility starts with what people need, in the brief and the prompt. ShapeA11y carries that intent into design tools, code, AI assistants and checks.

Get the toolkit Read the letter

Get the ShapeA11y toolkit

Give AI assistants accessibility rules before they write UI, then check what they build as part of your coding workflow. Start with the CLI, or choose the packages you need.

Get the CLI on npm

Install with npm

npm install --save-dev @shapea11y/cli
npx playwright install chromium

The CLI checks accessible names, heading structure, accessibility trees, keyboard focus and APCA contrast. See the README for usage.

Explore all toolkit packages

@shapea11y/create
Add rules and skills to a repository with npm create @shapea11y.
@shapea11y/mcp
Connect agents to the inspection tools through MCP.
@shapea11y/name
Inspect an element’s accessible name, role and state.
@shapea11y/tree
Read a compact accessibility tree in Markdown or JSON.
@shapea11y/headings
Inspect the page’s heading outline.
@shapea11y/focus
Check real Tab order and missing focus indicators.
@shapea11y/hear
Read virtual screen-reader output. This is not NVDA or JAWS testing.
@shapea11y/apca
Measure APCA Lc contrast for a text/background pair. This is not a WCAG conformance result.
@shapea11y/rules
Give agents persistent rules for accessible UI.
@shapea11y/skills
Add skills for authoring, reviewing and hearing interfaces.

Shape intent. Shape interfaces. Shape evidence.

Accessibility starts in the requirement

Intent

Describe what people need to understand and do before asking an AI assistant to build.

Interface

Ask for semantic HTML, clear names and keyboard access from the outset.

Outcome

Check whether people can complete their task with choice and independence.

Evidence belongs beside the code

Bring automated checks into the coding workflow to find barriers early, before someone has to report them. Combine those checks with human review and assistive-technology testing. Record what was tested, what was found and what remains uncertain.

Running a business? Start with the tasks your customers depend on. Read our practical guide to customer access.

Illustrative example

intent Payment confirmation

semantics An accessible name and ordered actions

verification Check stated requirements

More access. More independence.

Disabled people and advocates

Help shape requirements and review real experiences. Your expertise should influence decisions, with time and resources for your participation.

Product teams

Behind every control is a person trying to do something. Ask AI assistants to suggest accessible patterns early, and test those choices with people.

Organisations responsible for digital services

Make comparable access, choice and independence part of delivery. Fund ongoing review, act on reported barriers and show where participation has improved.

An open letter

Accessibility should survive the change

A software update should not take away someone’s access. We’re calling on AI tool creators, business leaders, and engineering and design teams to make that a shared responsibility.

Read and sign the open letter

Supporting the letter does not require using ShapeA11y’s tools.

What we’re asking for

Preserve access through change

Carry reviewed accessibility requirements into redesigns and updates. Check what changes before release.
Be clear about the evidence

Share what was tested, what was found and what remains uncertain.
Involve disabled people

Resource their participation in decisions and review. Keep responsibility with people.