Accessibility Standards & Principles

Standards are what make accessibility arguments end. Without them, every threshold is a preference and every exclusion is a trade-off someone can defend. With them, "the text must clear 4.5:1" is not a position to negotiate but a fact to encode—and the entire architecture of this system (validators, tokens, contracts) exists to turn those facts into defaults.

Standards also carry a second, subtler value: they arelearned ignorance—distilled findings about what fails for whom, written by people who studied the failures so you do not rediscover them in production. Knowing which criterion teaches which lesson turns compliance from paperwork into curriculum.

This page maps the standards onto the system: each principle and threshold, and the specific place here that encodes it—because a standard a system cannot point to its own implementation of is a standard it is quoting, not following.

POUR: The Four Principles

WCAG organizes all criteria under four principles—content must be Perceivable, Operable, Understandable, and Robust—and the principles do real work as a debugging taxonomy:

• Perceivable: information and UI components must be presentable to users' senses. The home of contrast, text alternatives, captions, and reflow.
• Operable: every interaction must work by multiple means. The home of keyboard access, target sizes, motion sensitivity, and timing.
• Understandable: content and operation must be comprehensible. The home of readable text, predictable behavior, and input assistance.
• Robust: content must survive interpretation by a wide range of user agents—the assistive-technology principle, and the reason semantics are a foundations concern rather than a component-by-component courtesy.

The taxonomy's practical use: when something fails, POUR names the failure class before the fix does. A dialog that cannot be closed by keyboard is not a "bug "—it is an operability failure with a criteria number.

The Numeric Thresholds, Encoded

The criteria this system computes live as constants and tokens—each with its citation:

// utils/accessibility/tokenValidator.ts — WCAG_LEVELS
AA_NORMAL: 4.5   // SC 1.4.3 — body text
AA_LARGE:  3.0   // SC 1.4.3 — large text; SC 1.4.11 — UI parts
AAA_NORMAL: 7.0  // enhanced contrast
AAA_LARGE:  4.5

// Encoded elsewhere in this repo:
dimension.tapTargetMin: 44px    // SC 2.5.5 (AAA) / 2.5.8 (2.2, AA)
dimension.actionMinHeight: 36px // control height floor
320px reflow                     // SC 1.4.10 — reflow
prefers-reduced-motion          // SC 2.3.3 — animation from
                                //   interactions (the motion
                                //   system's dual contract)

Conformance levels matter for what they make negotiable: A is the must-not-ship-without floor, AAA is aspiration where achievable (and provably impossible for some criteria—WCAG says so itself). The system posture: encode AA as hard gates, treat AAA as a target where the physics permits (the secondary-text pair clears AAA at ≈7.5:1; the accent as text does not, and the color page says so honestly).

ARIA: The Semantics Layer

WAI-ARIA is not HTML-plus-decorations; it is a vocabulary for expressing semantics HTML cannot. The design system's stake in it is Robustness: AT consumes a name/role/value tree, and components are where that tree is either well-formed or broken. The contract files carry the obligation as fields—a11y.role, labeling, keyboard, apgPattern—so a component's semantic surface is declared, reviewable, and testable, not folklore in its JSX.

The first rule of ARIA governs usage throughout: prefer the native element (button over role="button"), and reach for ARIA only where native semantics cannot express the pattern. The Icon component's binary—labeled role="img" or hidden aria-hidden—is the smallest possible example of correct usage.

Where Standards Are Heading

• APCA (part of WCAG 2.2's future and beyond) models perceptual contrast better than WCAG 2.1's relative luminance—especially on dark surfaces. This repo computes 2.1 ratios today and says so; the validator is where the math will change when the standard does.
• WCAG 2.2 adds focus appearance (SC 2.4.11), dragging movements (2.5.7), and target size at AA (2.5.8, 24px)—the last a loosened cousin of the 44px this system enforces, which remains the safer default.

The posture toward all of it: standards are the floor that learns. Encode them tightly enough to be enforced, loosely enough to be updated—the constants are data, the citations are comments, and the validators are the only code that has to change.

Design Impact

Designers inherit POUR as a review taxonomy and the thresholds as brief data: which pairs clear AA, which targets clear the floor, per mode. The design-side checkers compute the same numbers the validator does.

Engineering Impact

Engineers inherit the encoding duty: every threshold either has a home (constant, token, check) or is on the unencoded list. The standards page is the map of homes.

Governance Impact

Governance inherits conformance claims: what level, for which parts, with what evidence—and the honesty rule that a claim without a check behind it is marketing.

The team adopts WCAG 2.2's focus-appearance guidance (2.4.11): focus indicators must be large enough and contrastive enough to see. Walk the encoding:

1. Extract the computable parts: indicator area (≥ 2px perimeter equivalent) and 3:1 change against adjacent colors. Both are numbers; both are therefore encodable.
2. Find the homes: the size pairs with control.border.focusWidth (already the thick 2px step); the contrast joins the border pair ledger with a focus role entry.
3. Wire the check: the pair validator gains the focus-on-background pair per mode; the component contract's a11y block records the indicator expectation for interactive components.
4. Update the map: this page's table gains its row—because the table is the accountability surface: a criterion without a row here is either inapplicable or unencoded, and readers deserve to know which.

• Strictness vs coverage: enforcing 44px (2.5.5, AAA-level in 2.1) exceeds the AA floor and buys the safe default; teams with hard density constraints may bind to 2.5.8's 24px knowingly.
• Current math vs future math: locking 2.1 luminance makes results stable and comparable; APCA is more predictive. Validator-as-single-point keeps the switch cheap when it is time.
• Conformance claims vs evidence: claiming a level requires the checks to exist and be green; otherwise the claim is a liability with a deadline.

1. Standards as decoration

Citing WCAG in values documents while thresholds live nowhere in the build. The test is this page's table: criterion → file, or admit the gap.

2. Level shopping

Choosing the level per feature (AA here, aspiration there) quietly produces neither. Levels are set per product claim, and the exceptions are explicit.

3. ARIA as absolution

<!-- Bad: Roles stapled over broken semantics -->
<div role="button" onclick="…">Sign up</div>
<!-- Good: The native element IS the semantics -->
<button>Sign up</button>

4. Freezing on the current standard

2.1-only systems age into their own exceptions. The constants-as-data posture (one file to change) is the hedge.

• WCAG 2.1 — the normative text (https://www.w3.org/TR/WCAG21/)
• WAI-ARIA Authoring Practices — the pattern vocabulary the contracts reference (https://www.w3.org/WAI/ARIA/apg/)
• Token-level accessibility — where these thresholds live in the system (/blueprints/foundations/accessibility/tokens)
• The sources — utils/accessibility/tokenValidator.ts, ui/designTokens/core/dimension.tokens.json, any contract's a11y block