Selects synthetic constraints, inspects mapped controls, and owns implementation and follow-up testing.
Inclusive Experience Repair Lab
A deterministic teaching and inspection tool that turns selected interface constraints into explicit repair controls, combined-condition warnings, and a replayable local record—without pretending to simulate a disabled person or prove accessibility.
RELEASE DECISIONREVISE
Keep as the second flagship, but retire “simulator” as the lead promise. Launch only after disabled-participant and assistive-technology review.
01 / EXACT QUESTION
What is this prototype trying to learn?
Can a product team make its accessibility, language, bandwidth, motion, color, and density assumptions visible as inspectable interface controls—then understand why enabling controls is only the beginning of validation?
What exists now
- A working A-route repair lab and interactive B-route exist.
- The engine and mapping versions are explicit and deterministic.
- The export contains original state, derived state, evidence, privacy, limitations, and replay.
- The false-assurance label Repaired was replaced by MAPPED CONTROLS PRESENT.
- Automated behavior, keyboard, export, and 320px fixtures exist.
02 / PEOPLE + AUTHORITY
Who does what—and who is allowed to decide?
Provide experience the engine cannot infer. They are research partners, not generated profiles.
Combines standards knowledge, manual inspection, assistive-technology testing, and participant findings.
Evaluates language, cultural context, expansion, reading level, and target-market meaning.
Implements controls, preserves semantics and performance, and links changes to an accountable trace.
Applies declared mappings and two interactions. It does not diagnose, personalize, represent lived experience, or certify repair.
Authority boundary
- The engine may report missing declared controls and invalid evidence metadata.
- It cannot decide that an interface is accessible, inclusive, localized, usable, legally compliant, or repaired.
- Release authority must combine standards evaluation with disabled-user, assistive-technology, device, network, language, and cultural testing.
03 / TECHNICAL SYSTEM
From input to output, without magic.
Transient selection
Seven checkboxes describe synthetic interface conditions: low vision, color-independent, keyboard-only, reduced motion, low bandwidth, plain language, and reduced density.
Control state
Nine toggles represent text scaling, contrast, non-color cues, focus, target size, motion, lightweight delivery, plain language, and density.
Evidence validation
Every source needs a unique ID, title, HTTPS URL, allowed scope, valid review date, no future date, and ≤366-day freshness.
Mapping engine
Selected conditions produce missing-control findings from a disclosed lookup table. No model, diagnosis, telemetry, or personalization is involved.
Interaction pass
Two declared combinations add warnings: low vision plus low bandwidth; keyboard-only plus reduced density.
Status and replay
Failures block; gaps report MAPPED GAPS; otherwise MAPPED CONTROLS PRESENT. Export preserves inputs, findings, versions, evidence, privacy, and replay.
Exact decision procedure
- Order selected conditions using fixed NEED_ORDER.
- Block when demonstration consent is absent, persistence is true, the change trace is blank, or the assessment date is invalid.
- Validate evidence identity, title, HTTPS source, scope, uniqueness, review date, freshness, and future dating.
- For each selected condition, emit a finding for every disabled mapped control.
- Evaluate only two registered cross-condition interactions; do not infer others.
- Order enabled controls using fixed REPAIR_ORDER.
- Return CONTROL BLOCKED for control/evidence errors, MAPPED GAPS for remaining findings, otherwise MAPPED CONTROLS PRESENT.
- Always return limits: synthetic fixture, controls do not prove outcomes, and manual testing remains required.
State model
CONTROL BLOCKEDConsent, privacy, trace, date, or evidence integrity is invalid.
MAPPED GAPSAt least one declared mapping or interaction remains unresolved.
MAPPED CONTROLS PRESENTEvery declared mapping is enabled. This deliberately does not say Repaired.
EXPORTEDThe visitor downloaded original and derived state, versions, evidence, limits, and replay input.
04 / TRUTH BOUNDARIES
What is real, synthetic, missing, or prohibited?
A versioned pure engine, seven conditions, nine controls, two interactions, evidence validation, UI transformations, keyboard flow, and replay exist.
The fixture and selections are invented interface conditions—not a person, disability, diagnosis, identity, culture, device, or lived experience.
The lookup table, interactions, fixture, statuses, and sequence are RN product design. WCAG does not prescribe this engine.
No disabled-participant study, assistive-technology matrix, physical-device matrix, language evaluation, network field test, or efficacy evidence.
Do not claim disability simulation, empathy simulation, WCAG conformance, compliance, localization quality, usability, accessibility, or proven repair.
Selections remain component-local; persistence blocks and export is explicit.
Known failure modes
False empathy from simulationLead with repair lab and explain that no configuration reproduces lived experience.
Checklist becomes certificationUse MAPPED CONTROLS PRESENT and require independent evaluation.
Mappings oversimplify needsTreat them as a scaffold and revise with disabled participants.
Interaction explosionOnly two are known. Add interactions with evidence and tests.
Visual change lacks semanticsTest keyboard order, names, roles, announcements, and assistive output separately.
Plain language becomes localizationRequire target-language and cultural review.
Lightweight mode becomes network proofMeasure actual payloads and field conditions.
05 / PRIMARY EVIDENCE + COUNTEREVIDENCE
What each source supports—and where it stops.
W3C — Web Content Accessibility Guidelines 2.2 ↗
Exact locator: Guidelines 1.3, 1.4, 2.1–2.5, 3.1, 3.3; Conformance §5
Used for: Criteria for adaptable content, contrast, keyboard, focus, targets, motion, readable content, and input assistance.
Does not establish: WCAG does not simulate disability, prescribe this mapping engine, or make toggles conformant.
W3C WAI — Making Content Usable for People with Cognitive and Learning Disabilities ↗
Exact locator: Objectives, design patterns, document status, and scope
Used for: Guidance for understandable content, assistance, focus, and cognitive burden.
Does not establish: Not a conformance claim and not representative of every cognitive or learning disability.
W3C WAI — Involving Users in Evaluating Web Accessibility ↗
Exact locator: Introduction; range of evaluation; throughout development
Used for: Counterevidence to the idea that standards inspection or simulation replaces disabled participants.
Does not establish: Participant work complements standards evaluation; one participant cannot represent everyone.
W3C WAI — Using Combined Expertise to Evaluate Web Accessibility ↗
Exact locator: Introduction and types of expertise
Used for: Combining technical, disability, usability, and other perspectives.
Does not establish: It does not validate this prototype or specify these mappings.
06 / VERIFICATION
What has been tested, and what has not.
Automated and inspectable checks
- Initial fixture reports MAPPED GAPS and says selections are not a person or diagnosis.
- All mappings report MAPPED CONTROLS PRESENT and never render Repaired.
- Low-vision plus low-bandwidth emits the declared interaction warning.
- Export verifies engine 030.2.0, ordering, derived status, mapping 030-map-2, privacy, and replay.
- 320px has no horizontal overflow and retains seven native checkboxes.
- B-route forward/backward sequence works by keyboard with live, honest status.
Human research ledger
COMPLETEMapping behavior, evidence validation, deterministic replay, privacy guard, automated keyboard, and 320px fixture.
NOT CONDUCTEDObserved sessions with disabled participants.
NOT CONDUCTEDManual screen-reader and assistive-technology matrix.
NOT CONDUCTEDPhysical touch-device, zoom, and constrained-network field testing.
NOT CONDUCTEDRepresentative-language and cultural-context evaluation.
NOT CONDUCTEDUnderstanding of “mapped controls present” versus “accessible.”
NO INVENTED RESEARCH
An automated test can prove deterministic behavior. It cannot prove that a first-time visitor understands the language, that a reviewer resists automation bias, or that a repair works for disabled people. Those gates remain open until observed sessions exist.
07 / RECONSTRUCTION GUIDE
Rebuild the capability step by step.
- Define a small list of interface conditions; never label them diagnoses or personas.
- Define observable repair controls separately.
- Write and version an explicit condition-to-control table.
- Declare interactions individually; never imply completeness.
- Fail closed on framing consent, persistence, trace, date, and evidence metadata.
- Return states separating invalid context, unresolved mappings, and complete declared mappings.
- Render a synthetic fixture while testing semantics separately.
- Keep selections transient and export explicit.
- Export original input, findings, ordering, versions, evidence, privacy, and limits.
- Test incomplete, complete, interaction, invalid evidence/privacy, keyboard, motion, and narrow width.
- Run manual assistive-technology, device, network, language, and cultural tests.
- Evaluate the model with disabled participants before launch.
08 / PRODUCTION + STORY
What must happen before this becomes a launch story.
Production requirements
- Rename the public artifact Inclusive Experience Repair Lab; retain the historical title only in the record.
- Recruit and pay disabled participants with varied access methods to test premise, categories, controls, and result language.
- Review relevant WCAG criteria and document technique, result, and scope.
- Test keyboard, two screen-reader/browser pairs, 200–400% zoom, reflow, targets, forced colors, reduced motion, and status announcements.
- Measure transfer size and interaction on constrained networks and lower-powered devices.
- Test plain language separately from translation and cultural adaptation.
- Revise or delete misleading or falsely reassuring mappings.
- Version participant-informed changes and rerun all tests.
- Only then compare creative territories and launch around visible assumptions—not simulated disability.
Three future creative territories—not designs
These are briefs to test only after the product and human-research gates above are complete. No carousel direction is selected here.
THE ASSUMPTION GRID — hidden defaults occupy a rigid Dutch-modernist grid; each tested condition interrupts it.
ONE INTERFACE, MANY CONDITIONS — one object is recomposed through input, bandwidth, language, motion, contrast, and density.
PRESENT ≠ PROVEN — enabled controls confront validated experience; the gap is the hook.
Open release gates
- Disabled-participant evaluation.
- Assistive-technology and device matrix.
- Mapping completeness and interaction review.
- Localization and cultural-context evaluation.
- Public rename and canonical-title treatment.
- Creative territory comparison and selection.