opsinjs
AccessibilityConformance

Accessibility statement

A dated, honest statement of what has and has not been assessed, written so that a reviewer can tell the difference.

What we guarantee

Statement date: 2 September 2026. This statement covers the opsinjs design system and its documentation site. It does not cover any product built with them.

The claim

opsinjs makes no conformance claim against WCAG 2.2 or any other accessibility standard, at any level.

That is not modesty. Every one of the sixty catalogue components has now been audited against WCAG 2.2 AA, in a static source pass and a rendered pass, and the findings were fixed in the same change. That audit was run by the authors of the components, not by an independent reviewer, so it cannot ground a conformance claim: a conformance claim requires independent evaluation evidence, and there is none. What may be said is what was done, that the catalogue was audited against WCAG 2.2 AA by its own authors, and no more. See ADR 0025 for how the audit was run and why it is not independent.

What we do claim

Three narrower things, each of which is checkable:

  1. The published design decisions are accessibility-led, and each one names the criterion it serves and the failure it prevents. Those decisions are on the pages linked from Accessibility.
  2. Every accessibility number published anywhere on this site is generated by a named, committed script and is dated. No figure is typed by an author, and the build fails if a regenerated figure differs from the committed one.
  3. Known gaps are published on the page they affect. There is a Known gaps section on every page in this pillar and it is never empty by omission.

Scope

In scopeOut of scope
The opsinjs token layer and stylesheetsAny product built with opsinjs
The documentation site at this domainThird-party sites linked from it
The component specifications and the sixty implementations, audited against WCAG 2.2 AA by their authorsAn independent review of that audit, and a clinical review, neither of which has happened

What you own

If you are shipping a product built on opsinjs and you need an accessibility statement of your own, you cannot inherit this one. Yours must describe your product, your evaluation and your known issues. What you may reasonably reuse: the token-pair contrast measurements, once generated, cited with the date and version you took them from.

If you are procuring, the artefact you probably want is the conformance report, which is an ACR skeleton with every criterion marked Not Evaluated.

How to check

Do not take this statement on trust. Every claim in it is verifiable from the repository:

Verify the audit claim

Open Components and pick any component. Its catalogue row records an author-run WCAG 2.2 AA audit and no independent accessibility review, and so does each of the other fifty-nine. The status matrix on that page prints the same finding as a sentence above the table rather than as a column of sixty identical cells. Every component here was audited by its own authors, none has been independently reviewed, and none has had a clinical review.

Verify the "generated numbers" claim

Run pnpm run contrast and then git diff. If the committed numbers differ from the regenerated ones, this statement is wrong and you have found it in under a minute.

Verify the "gaps are published" claim

Open any page in this pillar and read its Known gaps section. Compare against what the rest of the page claims.

Ask us

Report an accessibility problem through the channel on Community. Accessibility reports are treated as defects rather than as feedback.

Measured results

The only measurement this project publishes is token-pair contrast. scripts/check-contrast.mts computes it from the shipped token values, its output is committed, and the figures appear on Contrast conformance and in the generated contrast reference with the date of the run that produced them.

A measured result for any rendered component has not been generated.

No figure has yet been captured for anything that renders. The rendered audit pass checked components against WCAG 2.2 AA by hand rather than by capturing a number, and the two scripts that would publish one are scripts/check-a11y.mts --layout and scripts/capture-registry.mts. Both need Playwright, which is deliberately in no package.json, so they run only in the nightly workflow and neither publishes a figure here.

Nothing on this site types a measured number by hand, so an ungenerated table shows this rather than an example.

Known gaps

Stated plainly, because a statement without this section is not a statement.

  • No independent accessibility review has been performed. The sixty components were audited against WCAG 2.2 AA by their own authors, in a source pass and a rendered pass, and the findings were fixed; an author auditing their own work is a floor raised, not a verdict delivered. There has been no third-party audit and no independent expert review. See ADR 0025.
  • No clinical review has taken place. Nothing in the catalogue is for a production health surface until a clinician signs it.
  • No assistive technology has been used against this codebase. Every cell of the tested matrix on Screen readers says Not tested.
  • forced-colors is unimplemented, and prefers-contrast is answered in one component rather than in the token layer. Surface drops its translucency and widens its edge under prefers-contrast: more; nothing else responds to either query, and neither behaviour has been measured. See Increased contrast.
  • The automated gates cover source and layout, not conformance. Three run: the contrast diff, scripts/check-a11y.mts blocking every pull request on what a component's source says, and that script's --layout half measuring hit area, 1.3x and 200% in a browser once a night. All three check rules this project wrote for itself. A passing run means nothing we know how to detect is wrong; it is not evidence that any success criterion is met.
  • The documentation site has not been audited against the standard it publishes. See This site's accessibility.
  • No user testing with disabled people has taken place.

Feedback and enforcement

If something on this site is inaccessible to you, report it through Community. We do not operate a formal enforcement or escalation procedure; if your jurisdiction requires one from a supplier, opsinjs is not currently a supplier that can satisfy it, and that is worth knowing before you build on it.

Updates to this page

This statement is reviewed every three months while the system is pre-release, and re-issued with a new date whenever a claim in it changes. The previous version is in the changelog.

Last read through against the system on 2026-09-20. Due for review every 3 months; expiry is reported by pnpm run check:freshness.

Edit this page

On this page