Nine WCAG AAA criteria. Two peer standards. Engineered at the token layer.
A 4–6 week engagement that brings your component library up to AAA-bucket conformance for the 9 component-shippable WCAG 2.2 AAA Success Criteria + 2 industry-consensus peer standards. Per-criterion evidence, not a single AAA claim. Anchored on HELiX, our open-source healthcare component library.
$35,000–$65,000 Four to six weeks · T&M with cap
A token-pipeline schematic — primitive tokens (color, type, spacing) → semantic tokens (focus-ring-color, target-touch-min) → component CSS custom properties → 9 numbered SC chips lighting up as the pipeline traces through to the rendered component. Reads as "AAA happens at the token layer, not the page layer."AAA isn't a checkbox. It's a per-criterion ladder you can climb on tokens.
Most accessibility programs treat AAA as a single conformance claim — and run aground on the 19 AAA Success Criteria that don’t engineer at the token / component layer (sign-language video interpretation, reading-level rewrites, abbreviation expansion). They then either claim AAA incorrectly (and get an OCR letter or a procurement reject), or abandon the AAA-bucket entirely and ship at AA when several specific AAA criteria were within reach.
The 9 component-shippable AAA SCs + 2 peer standards engineer at the token layer. Contrast, focus appearance, focus-not-obscured, target size, animation reduction, keyboard contracts, forced-colors support, APG keyboard pattern conformance — all of these are token-and-component concerns, validatable in CI, defensible in procurement, and stable across consumers.
What you get from D1 is per-criterion AAA-bucket conformance for the 9 + 2 — the language your procurement counterparty can verify, your engineering team can maintain, and your accessibility lead can audit against without trusting BST’s word for it. Anchored on HELiX, the open-source healthcare component library where this contract was first productized.
The 9 + 2 — engineered, evidenced, signed
-
1.4.6 — Contrast (Enhanced)
Visual presentation of text and images of text has a contrast ratio of at least 7:1 (4.5:1 for large text). Engineered at the color-token layer: every foreground/background pair in the token graph passes 7:1 by construction, validated by axe-core color-contrast-enhanced + computed-style audit in CI.
-
1.4.9 — Images of Text (No Exception)
Images of text are only used for pure decoration or where a particular presentation is essential. Component contract: no rasterized text labels; icon-only components carry an aria-label or visually-hidden text node. CI audit confirms via DOM snapshot.
-
2.1.3 — Keyboard (No Exception)
All functionality is operable through a keyboard interface, with no specific timing for individual keystrokes. Per-component Playwright walkthrough: every interactive state reachable, no mouse-only timing, no path-based input. Failure blocks the component from shipping.
-
2.3.3 — Animation from Interactions
Motion animation triggered by interaction can be disabled, unless essential. Every transition / animation in the component CSS respects @media (prefers-reduced-motion: reduce). Validated with PRM-emulated Playwright runs in CI.
-
2.4.12 — Focus Not Obscured (Enhanced)
When a UI component receives keyboard focus, no part of the component is hidden by author-created content. WCAG 2.2 addition (added 2023-10-05). Playwright assertion: focus each interactive element under sticky-header / sticky-footer / overlay scenarios; assert no occlusion via getBoundingClientRect + elementFromPoint.
-
2.4.13 — Focus Appearance
Focus indicator has at least a 2 CSS px perimeter and 3:1 contrast ratio between focused and unfocused states. WCAG 2.2 addition. Engineered at the focus-ring-color + focus-ring-width token layer; the token contract is what guarantees the threshold, not per-component overrides.
-
2.5.5 — Target Size (Enhanced)
Pointer-input targets are at least 44×44 CSS pixels (with documented exceptions). We hold to the AAA bar at 44×44 — explicitly NOT the AA-level 2.5.8 (Minimum) at 24×24 added in WCAG 2.2. Engineered at the target-touch-min token; component minimum sizes derive from it, never from per-component magic numbers.
-
3.2.5 — Change on Request
Changes of context are initiated only by user request, or a mechanism is available to turn off such changes. No surprise navigations on focus, no auto-submit on selection change, no time-based re-renders without explicit opt-in. Audited per-component.
-
3.3.6 — Error Prevention (All)
For pages that cause information submission, submissions are reversible, checked for errors, or confirmable. Form components ship with the confirm-before-submit pattern when the action is non-reversible; data-loss-class actions surface a confirmation step before commit.
-
Forced Colors Mode Support (peer standard)
Industry-consensus peer standard (not a WCAG SC). Components remain operable and legible under Windows High Contrast / forced-colors-active. CSS uses system color keywords (CanvasText, ButtonText, Highlight, etc.) inside @media (forced-colors: active) blocks. Validated with forced-colors emulation in Playwright.
-
APG-Aligned Keyboard Contract (peer standard)
Pattern conformance with WAI-ARIA Authoring Practices Guide. Each component implements the keyboard contract documented in APG for its widget pattern (combobox, listbox, dialog, tabs, menu, etc.) — Tab, Arrow, Home / End, Escape, Enter / Space behavior matches the spec. Pattern conformance, not WCAG SC.
How it works
-
Token graph audit
Week 1Deliverable Per-criterion baseline matrix + token-graph diff
We read your existing token graph (W3C DTCG, Style Dictionary, Tailwind config, Material design tokens, or hand-rolled custom properties — your stack, not ours) and produce a per-criterion baseline matrix: which of the 9 + 2 are reachable from the current tokens, which require new tokens, which require token-shape changes. The diff drives the rest of the engagement.
-
Token-layer engineering
Week 2–3Deliverable Token additions + rename plan + framework adapter updates
New tokens authored where the criterion requires (focus-ring-color, focus-ring-width, target-touch-min, motion-reduce-* family). Existing tokens renamed where the contract was wrong (e.g. "color-text-primary" was misused as a focus indicator in 18 components). Framework adapters (CSS custom properties, Tailwind, Style Dictionary outputs) regenerated.
-
Component contract migration
Week 3–5Deliverable Components migrated to the new token contract + per-criterion CI fixtures
Each component in scope migrated to the new token contract. Per-component CI fixtures added: axe-core color-contrast-enhanced, prefers-reduced-motion emulation, forced-colors emulation, Playwright keyboard walkthrough, focus-not-obscured occlusion check. Components that can't pass within the engagement window are flagged explicitly and scoped to the closeout matrix.
-
Conformance matrix + signoff
Week 6Deliverable Per-criterion conformance matrix + principal-engineer-signed report
Final per-criterion conformance matrix produced. Each criterion lists: the components in scope, the test fixture proving conformance, the link to the W3C / MDN / APG source, the engineer who signed off. Signed under principal-engineer attestation through Clarity House LLC. The matrix is the deliverable — the components are the evidence.
Pricing
Engagement model Time & materials with not-to-exceed cap
Compact tier ($35K–$45K, 4 weeks): single existing component library, single brand, 9 SCs only. Standard tier ($45K–$55K, 4–5 weeks): existing library + multi-brand token mapping, 9 SCs + forced-colors peer standard. Complex tier ($55K–$65K, 5–6 weeks): greenfield component library or significant token migration, full 9 + 2 peer standards, principal-engineer-signed conformance matrix.
Anchor pricing reflects typical engagement ranges. Actual fees are scoped per engagement under time-and-materials with a not-to-exceed cap. Pricing shown does not constitute a binding offer.
Frequently asked questions
Why are there only 9 WCAG AAA SCs in scope, not all 28?
What are the 2 peer standards and why are they in scope?
Does this give me an "AAA-conformant" claim I can put on my site?
How is this different from buying HELiX?
Will my procurement counterparty accept the conformance matrix?
What if my library is built on Tailwind / Material UI / Chakra / Radix?
How do you handle components we can't bring up to AAA-bucket within scope?
Can you sign the per-criterion conformance under a BAA?
When D1 isn't the right shape on its own
-
Single Property Accessibility Audit
When A1's findings on the consuming property are mostly token-layer regressions (focus, contrast, target size). D1 closes the gaps; A1's closeout re-audit measures the conformance delta.
-
VPAT 2.5 / ACR Production
When the procurement counterparty asks for AAA-bucket conformance language. D1 produces the engineering evidence; B1 converts it into the signed procurement-grade artifact.
-
Accessibility cluster overview
When the buyer is comparing across the cluster (A1 / B1 / D1 / G1) before scoping. The cluster page lays out the per-tier decision matrix.
Ready to engineer AAA-bucket into your tokens?
Four to six weeks. Per-criterion conformance matrix. Signed under principal-engineer attestation. Anchored on the HELiX reference implementation.