Built with AI

The Problem

Accessibility takes time. It requires knowing the WCAG specification, understanding how screen readers work, thinking about keyboard navigation, writing ARIA attributes, and testing with actual assistive technology. Most development teams have one accessibility advocate who fights for attention among competing priorities — and when deadlines hit, accessibility gets cut.

For blind developers, this creates a compounded problem. The people most motivated to build accessible software often lack the development bandwidth to ship features quickly, while sighted teams have the bandwidth but lack the sustained attention or lived experience to do it right.

The result is predictable: the tools that blind users need most are built by sighted people who test them last.

Why AI Changes This

A language model trained on documentation, specifications, and open-source code can hold the entire WCAG 2.2 specification in context while writing code. It doesn't get distracted. It doesn't deprioritize accessibility because it "takes too long." It doesn't forget that form inputs need labels or that modals need focus traps.

When used as a full development partner — not as autocomplete, but as a collaborator that understands both the goal and the specification — AI compresses the time between "this needs to be accessible" and "this is accessible."

The 1,089-line Node-RED accessibility layer on this site was built in a single session. Not because it was easy — Node-RED's canvas-based editor is genuinely complex — but because the AI could hold the full scope of the problem (canvas node labels, dialog focus management, palette keyboard navigation, live region announcements, tab bar accessibility) simultaneously, without dropping threads.

That kind of sustained, specification-aware attention is exactly what accessibility work demands and exactly what most development processes fail to provide.

The Workflow

Every project follows the same core loop:

1. Identify the problem with VoiceOver. Navigate the interface with a screen reader and note exactly what gets announced, what gets skipped, and where focus goes. A blind developer doing this already knows what's wrong — the problem is always felt before it's described.
2. Describe the problem precisely. Not "this isn't accessible" but: "When I tab to the palette item, VoiceOver announces the SVG element's bounding box coordinates instead of the node's label. There is no role, no aria-label, and focus is never returned to the palette after a dialog closes." Concrete description produces concrete fixes.
3. Generate the conformant implementation. Claude writes the fix — ARIA roles, keyboard event handlers, focus management, live regions — with the WCAG success criterion in context. The output is reviewed, not blindly applied.
4. Test with VoiceOver. Deploy to the live environment and navigate with a screen reader. Note what changed and what didn't. This step requires a human with a working screen reader — AI cannot substitute for lived experience here.
5. Iterate. Describe the delta between what VoiceOver announced and what it should have announced. Repeat until correct. Most fixes require two to four iterations.

The critical insight is step two. The more precisely you can describe what a screen reader experiences, the better the generated output. Blind developers have a structural advantage here: they already know exactly what's wrong, in the terms that matter.

What "VoiceOver-First" Means

VoiceOver-first is not the same as accessible. It means designing the user experience specifically for VoiceOver navigation before thinking about the visual presentation. In practice:

• Content structure is defined by headings, not by visual layout. If the page doesn't make sense as an outline, the structure is wrong.
• Interactive elements are designed around keyboard events and ARIA states, not around click handlers and visual indicators.
• Feedback is delivered via live regions that announce changes to screen reader users, not via color changes or icon swaps that only sighted users see.
• Labels are written for what VoiceOver will announce — then the visual copy is made to match, not the other way around.
• Every new component is tested with VoiceOver before it is considered done. Accessibility is not a post-ship audit.

The sighted experience is built on top of the accessible structure. When you start with a screen-reader-navigable document, adding visual polish is straightforward. The reverse — retrofitting screen reader support onto a visually-designed interface — is where most accessibility debt comes from.

The Collaboration Model

Every project on this site was built using Claude Code — Anthropic's CLI AI tool — as the primary development partner. Claude Code maintains full conversation context across an entire session, can read and edit files, run builds and tests, and reference external documentation.

For accessibility work specifically, this means:

• WCAG specification knowledge is available at every code decision, not just when someone remembers to check
• VoiceOver behavior can be described in plain English and translated directly to conformant ARIA markup
• Accessibility requirements established early in a session are applied consistently to every component that follows
• Entire accessibility audits can be run against any file or component mid-session, without context switching

This is different from using AI as a code generation shortcut. The collaboration happens at the architecture level — deciding what should be accessible, why, and what a correct implementation looks like for this specific interface. The AI brings specification knowledge and implementation speed. The blind developer brings lived experience and ground-truth testing.

Neither is sufficient alone. Together, they ship software that works.

Results

• Node-RED Editor — 1,089-line accessibility layer covering canvas nodes, dialogs, palette, tab bar, and Manage Palette. Built and deployed in a single session. Filed as GitHub issue #5505.
• wxaccess — VoiceOver-first Swift + MapKit app making NEXRAD Level 2 radar data accessible to blind users. Built from scratch with NWS alert integration.
• TS-890 Pro — VoiceOver-first macOS ham radio control app. KNS TCP auth, LAN audio, WDSP noise reduction, FreeDV, WSJT-X, EX menu, 100+ unit tests. Multi-radio support for TS-590, TS-890S, TS-990S.
• AetherSDR — Upstream accessibility contributions including PR #899 (merged), adding VoiceOver labels, focus management, and keyboard navigation to the SDR application.
• open890 — Accessibility contributions to an Elixir/Phoenix ham radio web application, including screen reader-compatible bandscope and meter displays.

Want to Try It?

The Examples page has working accessibility patterns — skip links, live regions, focus-managed dialogs, accessible forms, and more — that you can use as test cases for your own screen reader testing or as starting points for accessible components.

All code is plain HTML and CSS. No frameworks, no dependencies. Copy what's useful.