Proposal to house an open schema + catalogue of accessibility usage profiles

[anithapriyanatarajan]

Problem

Accessibility barriers accumulate one pull request at a time and are usually found long after release, when they are expensive to fix and people have already been shut out. The knowledge needed to catch them earlier already exists, but it lives in prose, reports, and people's heads. CI can't act on it.

Proposal

Two things, in the open:

1. A schema - how to describe a usage profile: a real combination of assistive technology, settings, and navigation style, plus what the product must provide under those conditions.
2. A catalogue - profiles written against that schema, reviewed by people who use those configurations.

Result: every PR can be optionally checked against the full range of ways people use the product.

What a profile looks like

id: screen-reader-with-magnification
summary: Screen reader at high speech rate, alongside 200% browser zoom

assistive_tech:
  - tool: NVDA
    version: "2024.4"
    settings: { speech_rate: fast, verbosity: low }
  - tool: browser-zoom
    level: 200%

environment:
  os: windows-11
  browser: firefox
  viewport: 1280x1024

interaction:
  navigation: [headings, landmarks, forms-mode]
  page_traversal: non-linear
  depends_on: [alt-text, live-regions, visible-focus, reflow]

product_requirements:
  - Every task completable without a pointing device
  - Form errors announced within 2s of submission
  - Full content and functionality retained at 200% zoom

wcag_focus: ["1.3.1", "1.4.4", "1.4.10", "2.4.7", "3.3.1", "4.1.3"]

provenance:
  type: synthetic-composite
  basis: published aggregate research and AT documentation
  reviewed_by: contributor-panel
  last_reviewed: 2026-05

Every field describes what the product must do. Nothing characterizes a person's abilities.

In CI

A maintainer comments /test accessibility. CI pulls the project's profiles from the catalog, runs the defined journeys under each set of conditions, and reports by profile:

screen-reader-with-magnification   FAIL  checkout step 3: error summary not announced (4.1.3)
keyboard-only                      PASS
extended-time-needed               WARN  session expires at 15m, no warning (2.2.1)

Why schema and catalogue are separate

• Different lifecycles. The schema is small and versioned carefully; the catalogue grows additively.
• Different reviewers. Schema changes need engineering review; profiles need review from people with direct AT experience.
• Adoption. Orgs that can't publish their profiles can still adopt the schema, build compatible tooling, and contribute back later.

How is this different from agent skills?

A skill is a capability. A profile is a set of conditions plus the requirements that apply under them.

	Skill	Usage profile
Answers	How to drive the tooling	Under what conditions, and what the product owes
Form	Instructions and scripts	Plain data (YAML/JSON)
Changes when	Tooling changes	Research or AT behaviour changes
Reviewed by	Engineers	Contributors with AT experience

What this is not

• Not a substitute for working with disabled people. Automation checks requirements that are already written down. It can't find the ones nobody thought of, or tell you whether a flow is exhausting to use. The point is to clear mechanical failures out of CI so paid work with disabled testers goes to the questions only they can answer.
• Not built from anyone's personal data. Disability information is special-category data under GDPR Art. 9 and similar laws. Profiles are synthetic composites from published aggregate research, and provenance is required.
• Not a certification. A pass is evidence under stated conditions, not a conformance claim.

[itsrajatrai]

I think the idea to build synthetic profiles from published aggregate research is brilliant and absolutely necessary to comply with GDPR Article 9.

However, I have one main concern about this approach. The CLI Research Deficit. Almost all existing accessibility research (like WebAIM) is heavily web- or mobile-centric.

There is virtually no published, peer-reviewed aggregate data on terminal-specific behaviours, such as screen-reader navigation speeds through 1,000-line log streams, or error rates for developers using voice-to-text with nested CLI flags. If we restrict ourselves strictly to existing published research, our catalog will be empty.