---
title: "For compliance reviewers"
description: "A curated twenty-minute path through the evidence, written to be printed and to be honest about what has not been evaluated."
url: "https://opsinjs.pensievelabs.org/accessibility/for-compliance-reviewers"
source: "https://opsinjs.pensievelabs.org/accessibility/for-compliance-reviewers.md"
section: "Accessibility"
kind: "accessibility"
reviewed: "2026-09-20"
reviewer: "design"
aliases: ["auditor", "procurement", "review path"]
---

> Elements written as `<PascalCase … />` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.

<PageTemplate kind="accessibility" />

## What we guarantee [#what-we-guarantee]

You have twenty minutes and a stack of vendor documentation that is mostly
marketing. This page is the opposite of that: a fixed route through the evidence,
with the conclusion stated first so that you can stop reading whenever you have
what you need.

**The conclusion, first.** opsinjs is a design system in early build. &#x2A;*Every one
of the sixty catalogue rows is implemented and installable, and every one has been
audited against WCAG 2.2 AA by the authors of the components, in a static source
pass and a rendered pass, with the findings fixed in the same change. That audit is
author-run, so it is not an independent review, and no clinical review has taken
place.** Nothing in this documentation should be read as a conformance claim: an
author auditing their own work raises a floor, it does not deliver a verdict, and
until a clinician signs a component it is not for a production health surface. See
[ADR 0025](../project/decisions/0025-the-audit-is-author-run.mdx) for the record.
The
[accessibility statement](./accessibility-statement.mdx) says the same thing in
the form your file probably needs, and the
[conformance report](./conformance-report.mdx) is an ACR skeleton in which every
criterion is still marked *Not Evaluated*, because a formal conformance evaluation
is exactly the independent assessment that has not happened.

What we do guarantee is the shape of the evidence you will be given when there is
some:

* Every measured number is generated by a named, committed script and is dated.
  No accessibility figure on this site is typed by a human.
* Every published claim has a page that states its scope, its check and its
  failure mode.
* Known gaps are published on the page that would otherwise imply they do not
  exist, not collected in an appendix.

<Callout>
  This page and everything it links to is designed to print. The site carries a
  real `@media print` stylesheet: navigation is removed, translucency and shadow
  collapse, external link targets are resolved into the text, and tables and safety
  callouts are prevented from splitting across a page break. See
  [Print and export](./print-and-export.mdx).
</Callout>

## What you own [#what-you-own]

The determination. We can tell you what was measured, by what, and when; we
cannot tell you whether that satisfies your obligation, because that depends on
the procurement standard you are working to (EN 301 549, Section 508, a national
public-sector regulation, or an internal policy) and on the product built with
this system rather than on the system itself.

Two things are specifically outside our scope and inside yours:

* **The conformance of the shipping product.** A design system is a set of parts.
  A product assembled from accessible parts can still be inaccessible; the
  reverse is also true.
* **Clinical safety.** opsinjs is not a medical device and confers no regulatory
  status. If your obligation includes DCB0129/DCB0160, EU MDR or FDA SaMD
  considerations, those attach to your product. See
  [Regulatory context](../health/regulatory-context.mdx) and
  [Safety, scope and limitations](../start/safety-scope-and-limitations.mdx).

## How to check [#how-to-check]

The twenty-minute path. Each stop tells you what to look for and what a bad
answer looks like.

<Steps>
  ### The scope claim (minutes 0 to 3) [#the-scope-claim-minutes-0-to-3]

  Read [Safety, scope and limitations](../start/safety-scope-and-limitations.mdx).
  You are checking that the vendor states plainly what the system is *not*. A
  health design system that does not disclaim device status, or that implies its
  components carry clinical validation, has told you something important in the
  first three minutes.

  ### The accessibility statement (minutes 3 to 7) [#the-accessibility-statement-minutes-3-to-7]

  Read [the statement](./accessibility-statement.mdx). Check that it is dated, that
  it names a standard and a version, that it distinguishes the system from products
  built with it, and that it contains a non-empty list of known gaps. A statement
  with no gaps is not a strong statement; it is an untested one.

  ### The conformance report (minutes 7 to 12) [#the-conformance-report-minutes-7-to-12]

  Open [the ACR](./conformance-report.mdx). Check the *remarks* column, not the
  conformance column. Every row currently says *Not Evaluated*, and the remarks say
  why. When rows begin to say "Supports", the remark must name the evaluation
  method and its date, or the row is unsupported.

  ### The measured evidence (minutes 12 to 16) [#the-measured-evidence-minutes-12-to-16]

  Open [Contrast conformance](./contrast-conformance.mdx). This is the one property
  of the system that a committed script measures today: token pairs. Component
  accessibility was audited against WCAG 2.2 AA by the authors, but that is a fixed
  set of findings rather than a generated number. Check that the contrast numbers
  carry a generation date and a script name, that both APCA Lc and WCAG 2.2 ratios
  are given, and that failures are shown rather than filtered out.

  ### The honesty test (minutes 16 to 20) [#the-honesty-test-minutes-16-to-20]

  Pick any two pages at random from
  [Accessibility](./index.mdx) and read only their *Known gaps* sections. You are
  checking whether the gaps are specific and uncomfortable ("`prefers-contrast` is
  not implemented") or generic and comfortable ("we are committed to continuous
  improvement"). This is the fastest available proxy for whether the rest of the
  documentation is trustworthy.
</Steps>

## Measured results [#measured-results]

<NoDataYet what="The conformance evaluation record" script="scripts/build-registry.mts">
  Nothing generates a conformance number on this site. No row of
  `registry/catalogue.ts` records an independent review, and `<A11yReport>` takes
  its counts as props rather than reading a measurement, so there is no generated
  evaluation table to publish and none is invented here. The author-run WCAG 2.2 AA
  audit is recorded in
  [ADR 0025](../project/decisions/0025-the-audit-is-author-run.mdx), not as a
  generated dataset.
</NoDataYet>

Every component has been audited against WCAG 2.2 AA by its authors, but nothing
has been through an independent evaluation against a success criterion, and no
clinical review has taken place. The one number a script produces is token-pair
contrast: it is generated, committed, and published on
[Contrast conformance](./contrast-conformance.mdx).

## Known gaps [#known-gaps]

* **No independent conformance evaluation has been performed.** There has been no
  third-party audit and no assistive technology testing. The WCAG 2.2 AA audit on
  record was run by the authors of the components, which raises a floor rather than
  delivering a verdict.
* **No clinical review has taken place, and it is still pending.** Until a
  clinician signs a component it is not for a production health surface.
* **No generated component-level conformance data exists.** Sixty components ship
  and every one has been audited against WCAG 2.2 AA by its authors, but not one
  has been independently reviewed, and no catalogue row records an independent
  review. Author-run findings are a floor, not third-party evidence, and nothing
  here treats installable code as evidence of conformance.
* **`prefers-contrast` is unimplemented,** which is a real gap against
  SC 1.4.11-adjacent expectations in high-contrast operating-system modes; see
  [Increased contrast](./increased-contrast.mdx).
* **The documentation site has not been audited against its own standard.** See
  [This site's accessibility](./this-site.mdx).

## Updates to this page [#updates-to-this-page]

<Reviewed />
