Perceivable
Content and UI can be perceived through more than one sense.
- Body text meets 4.5:1 contrast (1.4.3).
- Meaningful images carry descriptive text alternatives (1.1.1).
Context
Launch accessibility breaks where ownership is unclear.
Most teams agree accessibility matters and still ship inaccessible products. The failure is rarely intent — it is timing and ownership. Requirements arrive late, get translated loosely from design to code, and land on QA in the final week with no shared definition of what "accessible enough to ship" means.
This engagement treats a representative B2B SaaS application and asks a narrower question: what would it take to make accessibility a gate the release cannot pass without clearing? I scoped the work around the journeys where a barrier is most costly.
- Authentication
- Onboarding
- Core task flow
- Billing / checkout
Problem
A passing automated scan is not a passing product.
The most common shortcut is to equate "we ran axe and it's green" with conformance. It is not. Automated tooling is necessary but partial, which is exactly why a credible gate has to put humans on the criteria machines cannot judge.
30–40%
The share of WCAG issues automated tools can detect, by widely cited industry estimates. The remaining majority — meaningful alt text, logical focus order, sensible screen-reader output, keyboard operability of custom widgets — needs a person. The gate is built around that gap, not against it.
My role
Design-led accessibility owner.
- Role
- Defined and owned the accessibility gate end to end — design through sign-off.
- Standard
- WCAG 2.2, target Level AA, scoped per success criterion and per platform.
- Deliverable
- A reusable launch checklist, design-handoff annotations, and component accessibility contracts.
- Definition of done
- All blockers resolved; high-priority items resolved or carrying a dated, documented remediation plan.
Process
POUR, run as a system rather than a slogan.
The checklist is organised around WCAG's four principles, with each one expressed as concrete criteria a designer or engineer can act on. Below, one headline per principle plus two representative criteria; the full set lives in the filterable checklist further down.
Operable
Every function works by keyboard, with time and input under the user's control.
- All functionality is keyboard-operable, no traps (2.1.1, 2.1.2).
- Focus order is logical and always visible (2.4.3, 2.4.7).
Understandable
Interfaces read clearly, behave predictably, and help users recover from errors.
- Inputs have visible labels and instructions (3.3.2).
- Errors are described in text and tied to their field (3.3.1).
Robust
Markup exposes correct name, role, value and state to assistive technology.
- Custom components expose name, role, value, state (4.1.2).
- Prefer native HTML; use ARIA only where it adds meaning.
Depth · Design-phase handoff
Accessibility decided in the design file, not retrofitted in QA.
The design-led difference is moving these decisions upstream: contrast, focus indication, semantic structure, and component behaviour are specified and annotated before code exists. Color is the clearest example — and the easiest to get wrong, because a vivid brand palette can fail on its own canvas.
Before / after: measuring contrast, not asserting it
Boron's brand greens and red read fine to a designer's eye yet fail AA as small text on the cream canvas. Toggle the fix to swap in the AA-safe text aliases; the ratios beside each row are computed live from the rendered colors, not typed in.
Secondary / sage label
Success message text
Error / danger text
Practicing what I preach. I ran this same check on the case study's own presentation layer. Vivid hues are reserved for large and non-text use; every small label, link, and body string uses an aliased value that clears 4.5:1. The closing Final QA re-measures it live.
Depth · Component contracts
Every custom component ships with an accessibility contract.
Reusable components are where accessibility either scales or silently breaks. Each one carries a contract: its accessible name, role and value; its keyboard model; and its focus behaviour. Here is the dialog contract, with a working demo you can drive entirely from the keyboard.
Modal / dialog contract
- Role & name
role="dialog",aria-modal="true", labelled by its heading. - Focus inMoves to the dialog on open.
- Focus trapTab and Shift+Tab cycle within the dialog.
- DismissEsc closes; so does the close control.
- Focus returnReturns to the trigger on close.
- SC covered2.4.3 2.1.2 4.1.2
Live demo
Built on the native <dialog> element — native HTML first, ARIA only to fill gaps.
Try it with the keyboard: open, then Tab through, then press Esc. Focus returns here.
Depth · Verification model
A verification plan, not "we ran a scanner."
Conformance is claimed against a standard, per criterion, at a point in time — and only after a human has confirmed the things tooling cannot. The gate splits verification into four methods and names the assistive-technology matrix every critical flow is tested across.
- A Automated scanner
- M Manual check
- SR Screen reader
- KB Keyboard only
| Screen reader | Browser | Platform | Tier |
|---|---|---|---|
| NVDA | Firefox / Chrome | Windows | Primary |
| JAWS | Chrome | Windows | Primary |
| VoiceOver | Safari | macOS | Primary |
| VoiceOver | Safari | iOS | Primary |
| TalkBack | Chrome | Android | Primary |
| Narrator | Edge | Windows | Secondary |
Also in scope where applicable: screen magnification, voice control (Dragon, Voice Access, Voice Control), and switch access. Where possible, testing includes people with disabilities — the strongest signal there is.
The artifact
The launch checklist, as a living, filterable thing.
Every item from the checklist is here — filter by principle and area, priority, or verification method, and mark items as you clear them. Counts update live. This is the working artifact; the sections above are the parts I feature at depth.
Focus order
Focus order is a design decision you can see.
Logical focus order (2.4.3) and a visible focus indicator (2.4.7) are the difference between a keyboard user gliding through a form and getting lost in it. I annotate the intended tab path at handoff. Toggle the overlay to see the order on this sample form — then Tab through it for real; the current stop is outlined as you go.
Focus stop: none. Press Tab to move through the form.
Outcomes / impact
What the gate buys — each claim with its caveat.
This is a methodology artifact, so the honest framing is what the gate is designed to produce, paired with the limit of each claim. Real project numbers slot into the marked fields.
-
01 A shared definition of done
Accessibility becomes a release gate with explicit blocker, high, and medium tiers — not a subjective late-stage opinion. Teams can say, per criterion, whether a build clears.
Caveat A gate only holds if leadership lets it block a launch; without that authority it degrades into a checklist nobody enforces.
-
02 Issues caught upstream, where they are cheaper
Design-phase annotation moves contrast, focus, and semantics before code, reducing rework. ‹REPLACE: e.g., "defects found in design review rose from X% to Y% across two releases"›
Caveat Upstream catch depends on designers and engineers actually using the annotations; the artifact enables the shift but does not guarantee adoption.
-
03 Verifiable conformance, honestly scoped
A WCAG 2.2 AA target verified across six assistive-technology configurations with a documented known-issues list. ‹REPLACE: e.g., "N blockers and M high-priority issues resolved before launch"›
Caveat Conformance is to a standard at a point in time. It is not a claim that the product is "fully accessible" or barrier-free for every user.
-
04 Durable governance after launch
An accessibility statement, a feedback channel, named ownership, and acceptance criteria in the definition of done keep the gate standing for future work.
Caveat Governance decays without a named owner and triage budget; a statement with no one behind it is worse than none.
Reflection
What I would weigh again.
The hardest tradeoff was scope versus depth. A gate that lists every success criterion feels thorough but stalls a team; a gate that only lists blockers ships faster but lets real barriers through. I landed on a tiered model — block on the few things that exclude users outright, schedule the rest with dates — because a gate that is never cleared is just a document. The part I trust most is the verification model: measuring contrast and tabbing through flows on real assistive technology surfaced issues no scan reported. The part I would keep pressure on is governance, because every accessibility win quietly erodes the moment no one owns it.
Designer's note · David Paterni
Final QA
This page audits itself.
A case study about accessibility that fails its own checks would refute itself. These six checks are read from the live DOM when the page loads — what you see is the actual result, not a screenshot.