Scope the checklist before running it
Don't start with a generic box labelled "accessibility reviewed." Start with a named verification unit. A useful scope identifies the requirement, design-system artifact, artifact version, component release, supported states, consuming product, product release, and test environments. When one of those changes, the record should make clear whether the old evidence still transfers.
For a component change, the scope might be: "Search input 3.4.1, default, focus, populated, invalid, disabled, and loading states, tested in the component fixture and Product A's global search flow." For a foundation change, it might be: "Focus and foreground tokens from kit release 2.1, in light and dark modes, tested on the shared button and input plus checkout and account consumers."
- Requirement source: the standard, policy, acceptance criterion, or documented product need being checked.
- Shared artifact: the token set, typography definition, component, pattern, or documentation page.
- Versions: the exact source, package, generated output, and product release under review.
- Supported scope: states, variants, modes, browsers, viewports, input methods, and assistive-technology contexts the team has committed to support.
- Named consumers: representative product surfaces where composition and content can alter the result.
- Exclusions: untested combinations and deferred work, stated plainly so silence is not mistaken for coverage.
Limits of this workflow
This checklist helps teams gather and preserve release evidence. It doesn't replace a standard, provide legal advice, execute an audit, or certify accessibility. Record the governing requirement and involve qualified reviewers when the risk or obligation calls for them.
Keep three evidence states separate
Accessibility claims become unsafe when the evidence travels farther than the test. Keep three evidence states separate. Each answers a different question and belongs to a different release boundary.
| Documented intent | Isolated system evidence | Product-context evidence | |
|---|---|---|---|
| Question answered | What should the system support? | What did this artifact do in the recorded fixture? | What happened in this named product context? |
| Typical evidence | Requirements, usage guidance, supported states, and known limits | Keyboard results, semantic inspection, announcements, zoom behavior, and screen-reader observations | A completed user path with real content, composition, routing, validation, modes, and local overrides |
| Primary owner | Design-system and accessibility policy owners | Component or foundation maintainer | Consuming product team |
| Reusable when | The requirement remains current and applies to the consumer | The artifact version, state, method, environment, and relevant dependencies still match | The named product context and release remain materially unchanged |
| Does not prove | That an implementation follows the intent | That every consumer preserves the behavior | That other products, flows, or untested combinations behave the same way |
Moving from one state to the next takes new evidence. Documentation can specify an expected accessible name, but only an implementation test can observe the computed result. An isolated test can show that a menu returns focus in its fixture. Only a product test can show whether overlays, routing, and local composition preserve that behavior in a real flow.
Evidence is reusable only while its artifact, conditions, and claim stay the same.
Assign ownership across the release chain
Accessibility work crosses team boundaries, so assign an owner to each transition from intent to product behavior. Several teams may collaborate, but the correction and release decision still need named roles.
| What it owns | Required handoff | |
|---|---|---|
| Foundations | Semantic color roles, typography constraints, focus treatment, modes, spacing guidance, and documented limits | Versioned tokens or guidance, supported combinations, exceptions, and change notes |
| Components | Names, roles, states, keyboard interaction, focus behavior, announcements, and content constraints | Versioned component evidence, supported variants, known limits, and consumer retest requirements |
| Documentation | Current usage instructions, prohibited uses, content expectations, and stated test status | Traceable links between requirements, examples, evidence, and the released artifact |
| Distribution and release | Package, registry, export, dependency, and release integrity | Exact artifact versions received by consumers, migration notes, and retest triggers |
| Consuming product | Local composition, routes, content, overrides, task completion, and production-like behavior | Named product-context evidence and an accept, revise, or block decision |
A failure belongs at the narrowest authoritative layer that can correct it. If every consumer receives an incorrect focus token, fix the foundation. If the shared dialog has a broken keyboard contract, fix the component. If one page detaches the component and changes its markup, fix that implementation. If a technically valid control receives an ambiguous label, route it to the content owner.
Foundation checks establish whether the system supplies usable inputs and honest constraints. They don't establish product conformance. Test combinations that components are actually allowed to consume, including light and dark modes when both are supported.
- Semantic communication: meaning does not rely on color, position, shape, or typography alone. Guidance names any required text, label, pattern, or programmatic relationship.
- Color roles and modes: evaluate foreground-background pairs, controls, boundaries, status treatments, and focus indicators in supported combinations rather than as isolated swatches.
- Typography resilience: check supported families, weights, sizes, line heights, and spacing rules with representative content, resizing, reflow, user text-spacing changes, and relevant fallback conditions.
- Focus treatment: the system defines a visible treatment and states which layer owns placement, clipping, contrast, and exceptions.
- Layout and spacing: guidance permits reflow, magnification, and longer content instead of treating a fixed screenshot as the contract.
- Motion and effects: documentation identifies behavior that needs an alternative, user control, or product-level decision.
- Known limits: unsupported or unverified combinations appear beside the artifact instead of being hidden in release notes.
Consistency check · No dark-mode parity
The same plan card, built two ways in Ambient Sage.
Pricing
Everything a small team needs to ship a branded UI.
Pricing
Everything a small team needs to ship a branded UI.
Semantic tokens clarify intent; verification still follows
A role such as foreground, destructive, or ring communicates intent better than a raw color name. It doesn't prove that a component consumes the role correctly, that the rendered pairing works under actual conditions, or that status is communicated without color.
Pass one continued: check components in isolation
Use an isolated fixture to exercise the component's own contract without unrelated product code. USWDS states the boundary plainly on its component test page: isolated testing doesn't remove the consuming site's responsibility to test the component in context.
- 1
Name the supported variants and states
List only combinations the release claims to support. Include relevant default, hover, focus, active, selected, expanded, disabled, read-only, invalid, loading, empty, and success states.
- 2
Check semantics and communication
Inspect the accessible name, role, value, state, relationships, instructions, errors, and changes that require announcement. Visible and programmatic information should agree.
- 3
Run the keyboard path
Reach the component in a logical order, operate each supported action, dismiss temporary UI, and confirm where focus moves. Check the reverse path and unintended traps.
- 4
Inspect visible focus
Check each interactive state and boundary for clipping, obscuring, loss against adjacent surfaces, or local styles that suppress the shared treatment.
- 5
Stress content and layout
Use short, typical, long, localized, empty, invalid, and restricted content as applicable. Test supported zoom or magnification conditions and narrow layouts.
- 6
Use the declared assistive-technology environments
Run the combinations named by the support contract. Record the exact environment and observation instead of writing "screen reader passed."
- 7
Record exceptions before release
An exception needs a reason, owner, affected scope, review condition, and product impact. An undocumented exception is still an unknown, not an acceptance.
Automation handles repeatable checks well, but keep each result attached to the method that produced it. A successful automated rule doesn't replace keyboard use, screen-reader observation, content judgment, or completion of the actual product task.
Keep the test matrix bounded
Cover the environments named by the support contract and representative high-risk consumers. If that contract is missing, route the gap to the policy or product owner instead of inventing an unlimited obligation during release review.
Start from a versioned system, then verify it
Identity Forge kits can supply semantic light and dark tokens, typography, spacing, layout guidance, DESIGN.md, and implementation exports. Treat those artifacts as upstream intake, then record separate component and product evidence.
Record every result in an evidence register
Checkboxes age badly because they hide what was tested. Use one row per checkable claim. The register should let another reviewer reproduce the observation, identify what changed, and decide whether the evidence still applies.
Requirement source:
Requirement or expected behavior:
Evidence state: documented intent | isolated system | product context
Shared artifact and version:
Component, variant, and supported states:
Generated or distributed artifact version:
Consuming product and release:
Representative surface or user path:
Method:
Environment: browser, viewport, input, zoom or magnification, assistive technology
Fixture or content:
Expected observation:
Actual observation:
Evidence reference:
Exception or known limit:
Correction owner:
Retest trigger:
Disposition: accept | revise | block
Reviewer and date:Keep expectations and observations in different fields. "Focus returns to the button that opened the dialog after dismissal" is an expectation. "In Product A checkout, closing with Escape moved focus to the browser chrome" is an observation. Separating the fields prevents the desired behavior from being copied into the result.
Attach enough evidence to support the claim without collecting screenshots for their own sake. Depending on the check, that may be a test result, short recording, accessibility-tree capture, issue reference, fixture identifier, or concise observation. The register is the index. Each attachment remains tied to an exact row.
Pass two: retest representative product consumers
The second pass asks whether the consuming product preserved the component's behavior. Choose consumers by risk and difference, not convenience. Include surfaces likely to expose distinct failures: dense composition, overlays, validation, long content, narrow layouts, important task paths, local theming, and both supported modes.
- Confirm that the product received the reviewed component, token, documentation, and dependency versions.
- Check whether local CSS, wrappers, detached copies, event handlers, routing, or state management alter the shared contract.
- Repeat the complete keyboard path through the surrounding task, including entry, operation, cancellation, success, error, and recovery where applicable.
- Verify names, instructions, errors, status changes, and announcements with the product's real content and data states.
- Test supported zoom or magnification, narrow layouts, modes, and representative assistive-technology contexts inside the product.
- Inspect interactions between components, including focus movement across dialogs, menus, notifications, validation summaries, and route changes.
- Complete the user task. Individually operable components can still produce a flow that is impossible to finish.
Check protected surfaces too. A shared correction may fix the target and break another consumer. Name at least one materially different consumer that should remain stable, then record what happened after the update.
Sample by failure mode
Sampling one page per product is weak when every page uses the component in the same way. Prefer consumers with different composition, content, mode, viewport, or interaction conditions. The point is to challenge the boundary of the shared evidence.
Set retest triggers before evidence goes stale
State when evidence expires. A date alone is a weak trigger because a result can remain valid for months without change or become obsolete the next day after a dependency update.
- The shared component, foundation, token mapping, typography rule, or documentation contract changes.
- A generated export, registry item, package, framework adapter, or relevant dependency changes.
- A supported state, variant, mode, browser, viewport, input method, or assistive-technology environment changes.
- The product changes local composition, wrappers, routing, validation, content structure, or overrides around the component.
- A defect appears in another consumer and may share the same source.
- The governing requirement, product policy, or support contract changes.
- An exception reaches its review condition or expiry.
You don't need to repeat every test for every trigger. Trace the change's reach, identify the evidence rows that depend on it, and rerun those rows plus representative protected consumers. If you can't determine the reach, broaden the retest or repair the dependency record.
Route failures to the owner of the correction
| Likely owner | Next check | |
|---|---|---|
| The same state fails in every consumer | Shared foundation or component owner | Reproduce it in isolation and trace the governing token, markup, behavior, or guidance |
| Only one product implementation fails | Consuming implementation owner | Inspect version drift, wrappers, overrides, event handling, routing, and detached copies |
| Behavior works, but the label or instruction is unclear | Content or product owner | Compare visible language, accessible name, instructions, error text, and the intended action |
| Two accessible components fail when composed | Local composition owner, with component maintainers as needed | Trace focus, reading order, announcements, layering, and shared state across the boundary |
| The expected behavior is undefined | Requirement or accessibility policy owner | Define the supported outcome before asking an implementation team to choose one |
| Evidence cannot identify the shipped version | Distribution or release owner | Resolve artifact provenance before accepting inherited results |
Route each failure to the layer that can correct it. When the shared source is responsible, make one correction there. Keep product-specific behavior with the product. Retain the original observation, link the correction, and record the retest instead of replacing the failure with a clean final note.
Use Ambient Sage v1 as upstream intake only
Ambient Sage v1 provides a concrete, versioned upstream example. Its public kit uses a near-white warm-sage canvas, a tonal card surface, a vivid yellow accent used sparingly, Plus Jakarta Sans for interface typography, and JetBrains Mono for technical strings. Identity Forge can also provide semantic light and dark tokens, typography, spacing, layout guidance, DESIGN.md, and implementation exports.
Token specimen · real values
Ambient Sage
Live renderAmbient Sage's actual tokens — the same values its exports use.
An intake record can cite Ambient Sage v1, the retrieved artifact, token export, typography roles, and supported mode data. It can't mark keyboard behavior, accessible names, focus order, announcements, reflow, or screen-reader output as passed. Those facts require tests on a named component or product.
Source artifact and version: Identity Forge kit / ambient-sage / v1
Source facts recorded: semantic light and dark tokens; Plus Jakarta Sans for body and heading roles; JetBrains Mono for technical strings; compact-product typography scale
Evidence state: documented intent / upstream intake
Isolated component evidence: unresolved until a named component and version are tested
Product-context evidence: unresolved until a named consumer and release are tested
Owner: component maintainer for isolated behavior; product owner for consumer verification
Retest trigger: source artifact, component, dependency, content contract, or consumer context changes
Disposition: revise until required component and product rows are completeChoose accept, revise, or block
Match the release decision to the recorded scope. Don't use "pass" to imply more than the evidence covers.
- Accept when every required row has reproducible evidence for the named artifact and product contexts, no blocking observation remains, exceptions are approved and owned, and shipped versions match reviewed versions.
- Revise when the defect is bounded and correctable, ownership is clear, and the affected release can wait for correction and retest. Keep the failed observation in the record.
- Block when a required path cannot be completed, keyboard focus is lost or trapped, necessary information is unavailable, a critical change is not communicated, the shipped artifact cannot be identified, or missing evidence leaves the risk unbounded.
- Accept with an exception only when governance permits it and the record names affected users and surfaces, the reason, owner, mitigation, review condition, and product impact. Record the exception as visible debt instead of treating it as a silent pass.
Complete one evidence row for one shared component in one real consumer. If you can't name the artifact version, expectation, environment, observation, owner, and retest trigger, repair the evidence boundary before making a release claim.
Sources
- Accessibility - Carbon Design System: Carbon frames accessibility as a design-system concern spanning the needs of people with visual, auditory, physical, and cognitive disabilities.
- Design system checklist | Webflow University: Webflow places accessibility alongside foundations, reusable styles, components, documentation, launch, and maintenance in the design-system lifecycle.
- Accessibility Overview - Utah Design System: The Utah Design System provides practical checks for visual communication, forms, sequential keyboard navigation, visible focus, focus order, and keyboard traps.
- List accessibility tests | U.S. Web Design System (USWDS): USWDS states that components tested in isolation still need testing in the context of the consuming site, including zoom, magnification, and screen-reader checks.
- AI UI review checklist: Identity Forge's broader UI review workflow separates evidence tracks, uses representative states, routes findings to responsible layers, and distinguishes pass, revise, and block decisions.
- Ambient Sage Design Kit: The published Ambient Sage v1 kit documents semantic visual decisions, Plus Jakarta Sans for interface typography, and JetBrains Mono for technical strings.