LAKA accessibility model
WCAG determines the required accessibility outcome. LAKA determines how to diagnose, change, measure and maintain the system. Never trade away a required outcome because another LAKA cell improved.
Five levels × ten internal variables
Baseline is observation, not permission to ship an inaccessible baseline. Choose the least disruptive level capable of addressing the root cause, but expand the repair when a local defect is systemic.
| Internal variable | Baseline | Minor Change | Major Change | Structural Change | Paradigm Change |
|---|---|---|---|---|---|
| Object | Inventory pages, components and journeys. | Repair one affected instance. | Replace a defective component. | Repair shared primitives and content models. | Redesign the interaction model around equivalent ways to complete a task. |
| Conditions | Record role, state, device, input, locale and preferences. | Correct one failing state or breakpoint. | Cover the entire component state machine. | Establish shared environment and coverage contracts. | Preserve task access across different input and presentation modes. |
| Actions | Reproduce the barrier and affected task. | Adjust an attribute, token or handler. | Rebuild the interaction sequence. | Require accessibility checks throughout delivery. | Generate implementations from explicit accessible task contracts. |
| Tools | Inventory scanners, browsers and manual methods. | Apply a targeted inspection or test. | Create component-level automated and manual protocols. | Integrate evidence collection and gates into delivery tooling. | Use a versioned rules-to-tests toolchain with human verification. |
| Resources | Identify owners, fixtures, assistive technology and evidence gaps. | Allocate a small repair and independent retest. | Fund component redevelopment and user testing. | Maintain an accessibility owner, training and supported test matrix. | Make accessible-task delivery a funded product capability. |
| Outcomes | Measure observed failures and unresolved checks. | Remove one confirmed barrier. | Complete the affected journey across required states. | Prevent recurrence across consuming applications. | Offer independently usable equivalent routes to the same outcome. |
| Feedback | Capture reproduction steps and user reports. | Add a regression test for the repaired case. | Use task observations to improve the component. | Route regressions back to shared owners and root causes. | Version the grammar based on evidence and emerging user needs. |
| Constraints | Record platform, security, content and supplier limits. | Resolve local constraints without weakening another requirement. | Replace a limiting component or dependency. | Put accessibility obligations into architecture and procurement. | Reconsider business assumptions that make access unnecessarily difficult. |
| Value | Identify the task and the people prevented from completing it. | Restore one interaction. | Restore a complete customer or staff task. | Increase consistent access across the product family. | Make independent access a core measure of product value. |
| Failure mode | Record observed exclusion; do not assume a scanner is complete. | Avoid cosmetic patches that hide the symptom. | Avoid new barriers in redesigned states. | Avoid organization-wide propagation of a faulty primitive. | Avoid adaptive experiences that remove information, agency or parity. |
Fourteen measurement lenses
These are project-defined measurement prompts. They are not validated predictors or weighted WCAG scores. Use explicit units, time windows, denominators and confidence notes.
| Meta-variable | Question | Measurement guidance |
|---|---|---|
| Magnitude | How much does this aspect change? | Count changed properties and affected task steps; report barrier reduction separately. |
| Rate | How quickly does it change? | New confirmed barriers per release or week, using a fixed scope. |
| Direction | Does the change improve or worsen independent access? | Trend in task barriers and successful completion; name the desired direction. |
| Scope | How broadly does it apply? | Unique affected routes, roles, components and journeys. |
| Depth | At what system layer does it occur? | Instance, component, shared primitive, architecture or product model. |
| Duration | For how long does the condition or barrier persist? | Time present per interaction and age of unresolved finding; label which is measured. |
| Frequency | How often does it occur? | Affected encounters divided by observed eligible encounters. |
| Acceleration | Is its rate increasing or decreasing? | Change in barrier-arrival rate across comparable time windows. |
| Variability | How different is behavior across contexts? | Differences across themes, viewports, locales and input/assistive-technology combinations. |
| Detectability | How reliably can it be found? | Detection method and, when measurable, pre-release discoveries divided by all subsequently known findings for that release. |
| Reversibility | Can the change or action be safely undone? | Verify user recovery and deployment rollback separately; record successful trials. |
| Propagation | Where can a local change spread? | Trace consumers and descendants of the changed primitive or content field. |
| Amplification | How much additional impact can one source create? | Downstream task failures attributable to one source defect, without double counting. |
| Accumulation | What builds up over time? | Unresolved confirmed backlog and its change over comparable releases. |
Volumetric use
Five change levels × ten internal variables × fourteen lenses = 700 addressable analysis cells. The exported JSON provides every coordinate. Most projects should instantiate a relevant subset, not manufacture 700 arbitrary findings. An empty coordinate means unexamined, not compliant.
Overlay actual product contexts: component × state × action × input method × viewport/zoom × role × locale × theme/preference × assistive-technology/browser combination. This overlay is separate from the 700 LAKA planning cells.
Root-cause decision rule
IF a local change removes the barrier AND introduces no regression
THEN choose Minor Change.
ELSE IF the component model causes the failure
THEN choose Major Change.
ELSE IF shared architecture, tokens, content schemas or delivery policy propagate it
THEN choose Structural Change.
ELSE IF the task itself depends on an unnecessarily exclusive interaction model
THEN examine Paradigm Change.
ALWAYS reproduce, retest the repaired task, and review affected consumers.Example: a drag-only dashboard can receive move buttons at Major Change; a shared reorderable-list contract is Structural Change; a task-command interface with equally capable visual controls is a possible Paradigm Change. These are proposed designs, not measured outcomes.