Lab · 11
Can AI easily build an accessibility widget?
This one tests itself: ask AI to build an opt-in accessibility widget for the site — text size, higher contrast, reduced motion, underlined links — and see how much back-and-forth it actually takes.
Hypothesis
AI can easily build an accessibility widget.
Finding
AI quickly and easily made an accessibility feature for the website. Hypothesis proven.
Built and shipped in a single session across two commits; the first pass needed one follow-up correction — shrinking a tall vertical-text tab into a compact icon button — before it was considered finished. Not yet tested with real assistive-tech users or run through a full WCAG audit of its own.
Method
Scope
Defined four opt-in controls — text size, higher contrast, reduced motion, underlined links — as a single self-contained widget rather than editing per-page markup.
Build
Wrote the localStorage-backed preference state, the injected toggle panel, and the CSS that retints the site’s shared design tokens for contrast mode and rescales the root font size for text size.
Ship
Shipped site-wide in one commit — no per-page template changes needed, since the widget injects itself via the shared script on every page.
Polish
One follow-up commit replaced the initial tall vertical-text tab with a compact icon button after review — same session, no rebuild of the underlying logic.
Tech
The experiment
Two commits, same session: one to build the whole thing, one to fix the one thing that needed fixing.
AI handled
- Designing the four controls and their interactions
- Writing the localStorage read/write logic defensively, with a private-mode/storage-disabled fallback
- Building the toggle panel markup, open/close behavior, Escape-to-close, and focus return
- Writing the contrast-mode CSS by retinting the site’s existing shared design tokens rather than overriding elements one by one
- Redesigning the tab into a compact icon button after review
Dr. Paul handled
- Requesting the widget and which controls to include
- Reviewing the first build and asking for the tall vertical tab to be replaced with a compact icon button
- Approving both commits before considering it done
- Declaring the hypothesis proven
Worked: A fully working, self-contained accessibility widget — state persistence, live DOM updates, keyboard support — shipped in a single commit, then a design issue was correctly diagnosed and fixed in a second, same session, with no redo of the underlying logic.
Constraint: The first pass shipped with a design choice — a tall vertical tab — that needed a same-session correction rather than landing right the first time. It hasn’t been checked against real assistive-tech users or an independent WCAG audit of its own.
Finding
AI quickly and easily built the accessibility widget — hypothesis proven.
The whole feature — UI, state persistence, and site-wide integration — shipped in a single commit, with no per-page edits required.
The one thing that needed fixing — the tab’s design — was corrected in a second commit the same session, not a rebuild.
Implication
Building an accessibility widget isn’t usually the hard part — deciding to prioritize it is. This experiment suggests that once someone asks for it, AI can close most of the distance between deciding and shipping in a single sitting, including catching and fixing its own design missteps along the way.
AI quickly and easily made an accessibility feature for the website. Hypothesis proven.
Next Question · 12
What’s next is still open.
A few ideas already on the table: testing the widget with real assistive-tech users, or running it through a full WCAG audit of its own.
Back to the Lab