Posts on Accessibility.
7 posts tagged "Accessibility".
Six navigation phases, one client island: why the keyboard audit took half an hour
The learning hub's navigation plan ran six phases. Five shipped as pure RSC; the server knew the URL, and that was enough. The in-chapter TOC with IntersectionObserver scroll-spy was the only genuine client requirement, and keeping the client surface at one component made the accessible-by-default story apply to everything else.
Three words and an arrow: the learning spec's highest-value navigability fix
Seven phases of navigation work shipped across the learning hub. The spec rated P5 — a row of prerequisite chips at the chapter head — highest-value for navigability. It was the only phase designed to answer a question the reader didn’t know they had.
The first visible change to /learning/ arrived after the tests, the breadcrumb, and the JSON-LD
P2 of the learning-hub navigation was the first thing a visitor could see. By the time it shipped, the repo already had 37 passing fixture tests, a semantic breadcrumb, and a data model — none of it visible. The spec changed what shipped first, which changed what was easy to skip.
The accessibility gate that made stacking five motion effects into one PR survivable
Phase D of the Cursed Energy DNA landed sigil rotation, energy pulse, claim spark, level-up celebration, and streak milestones in a single PR alongside three other features. Accessibility review was a non-event — not because the PR was small, but because every motion effect owned its own gate.
Five animations, five accessibility gates: what Cursed Energy Phase D cost to ship correctly
Phase D of the Cursed Energy design system added five animated effects to bb finance: sigil rotation, energy pulse, claim spark, level-up celebration, and streak milestone overlays. Every one is gated by the SwiftUI Reduce Motion environment key. Gating from the start rather than retrofitting later cost extra environment reads on every animated view. What it bought was a WCAG 2.1 AA clean bill before any user encountered the animations.
accessibilityReduceMotion should be a contract. Phase D made it one.
Phase D of an iOS budget app Cursed Energy feature adds five animated layers across sigil, energy, claim, level-up, and streak milestone surfaces. Every one checks accessibilityReduceMotion before firing — a hard gate, not a hint. The uniformity was a rule established on the first addition and held through to the fifth.
Audits find what's wrong, not what's missing
A page-by-page audit ran for three days catching deprecated ARIA roles, fabricated copy, and missing hover-pause behaviour. Then I opened the site on my phone and the nav menu wasn't there. Not wrong. Just not there. That's a class of bug audits can't catch, and the fix isn't to audit harder.






