Accessibility Architecture

Six weeks before a launch an audit returns 200 findings across eleven applications. The automated checks were green all year. Most findings are the same eight defects repeated: a clickable div, a custom dropdown with no keyboard support, focus left at the top of the document after a route change, an input with a placeholder and no label.

Eight root causes, repeated by eleven teams, is an architecture result, not a diligence result. The pattern recurs because each team re-derives the same behaviours, and nothing in the path from commit to production notices when one of them is missing.

Why it matters

The remediation economics are brutal. The same defect fixed once in a shared primitive costs hours; fixed in eleven applications it costs weeks and reopens the next time someone builds a dropdown. Retrofitting also arrives with a deadline attached: the European Accessibility Act became enforceable on 28 June 2025 for consumer services including e-commerce and banking, with EN 301 549 as the harmonised standard referencing WCAG level AA, and public-sector procurement in several jurisdictions requires a conformance statement before a contract is signed.

There is a harder constraint behind the legal one. Roughly a third to a half of common findings cannot be detected by any automated tool, because they are questions of meaning: whether an alternative text describes the image's purpose, whether a focus order matches the visual order, whether an error message says what to do. A strategy built on scanning will keep producing green builds and failing audits.

Implementation patterns

• Put the behaviour in primitives. One button, one dialog, one menu, one field — each carrying role, keyboard handling, focus management and naming. Forty applications then inherit six behaviours they would each have had to implement.
• Own the application-level concerns centrally too, because they live outside components: a route change must move focus and announce the new view, a skip link must exist, landmark structure must be one per page.
• A regression gate in the pipeline, combining an automated rule set with a named manual pass for the categories tools cannot see. The gate fails the build, which is the only mechanism that holds under deadline pressure.
• Keyboard-only and screen-reader passes on the critical flows, scripted and assigned, not left as a virtue.
• Procurement rules for third-party widgets — a chat bubble, a payment iframe, a cookie banner — since these are routinely the least accessible elements on a page and the ones the team cannot patch.
• A published conformance statement maintained as a living document, so the gap list is known rather than discovered.

Industry example

The standards themselves draw the line this practice is built on: WCAG 2.2 became a W3C Recommendation on 5 October 2023, and criteria such as 1.3.2 Meaningful Sequence and 2.4.3 Focus Order are about programmatic structure — exactly the properties that a shared component and a shared router can guarantee and that a per-team checklist cannot. The EU's harmonised standard EN 301 549 points at the same criteria, which is why one investment satisfies both the legal and the engineering requirement.

Failure scenarios

• A design system that covers 60% of the interface, while the other 40% is bespoke and carries most findings.
• An automated gate treated as sufficient, producing a year of green builds and a 200-finding audit.
• A single accessibility specialist as the bottleneck, so reviews are skipped when a deadline is close.
• A design decision that makes conformance impossible — low-contrast brand colours, a layout whose visual order cannot match source order — discovered in engineering rather than in design review.
• Overlay products bought as a remedy, which change the rendered page at runtime and have repeatedly produced litigation rather than conformance.
• A conformance statement written once and quietly falsified by the next two quarters of releases.

Trade-offs

Centralising conformance means a platform team owns a cross-cutting quality attribute, with the funding and staffing argument that implies, and product teams lose some freedom: refusing a prop or a layout on accessibility grounds is a real constraint on design. Gates also add release friction, and a gate that blocks a hotfix will be bypassed unless it has a documented override with an expiry.

The counterweight is that the alternative is not cheaper, only later: the same work plus coordination across every team plus a deadline someone else set.

When not to use it

A single application with one team does not need an architecture for this — it needs a checklist, native elements and one keyboard pass before release, and building a governance structure around that is overhead that will not be maintained. The practice earns its cost from roughly the third or fourth consuming application onward, or from the first contract that requires a conformance statement. And central ownership never removes local responsibility: a shared dialog cannot stop a team writing a label that says "Click here".

Interview question

Q: You have eleven applications, one design system used by three of them, and a legal deadline in nine months. Sequence the work, and tell me what you would deliberately not do.

What a strong answer covers: audit to find the repeated root causes rather than the full finding list; fix them in the primitives first; drive design-system adoption for the critical flows only, since adoption is the long pole; add the regression gate before fixing the long tail, so progress does not regress; handle third-party components by procurement pressure or replacement. Deliberately not done: a full remediation of low-traffic internal screens, and any overlay product.

Quick check

Quiz: Why does a green automated check not predict an audit result? A substantial share of findings are semantic — alternative text quality, focus order against visual order, error message usefulness — which no tool can evaluate.

Flashcard: What is the signal that accessibility is a structural problem rather than a diligence problem? — The same small set of defects repeats across many teams, which means each team is re-deriving behaviours that belong in a shared primitive.