Case Studies
GOV.UK Design System — Semantic HTML as the Component API
Government Digital Service, United Kingdom
GOV.UK runs on a design system that deliberately treats semantic HTML as the accessibility API for every component. The team documented that 4.5% of GOV.UK users rely on screen readers — a number large enough to represent millions of sessions across a government estate of thousands of services.
Their component API isn't defined in JavaScript or TypeScript. It's defined in HTML semantics. A notification banner component exposes its state through role="region" and a visible heading. A tabs component uses native <details> as a fallback. Error summaries use role="alert". The contract between the component and the screen reader is the markup itself.
The design principle behind this is explicit: if the semantic HTML doesn't communicate the component's state and purpose, the component is broken — regardless of how it looks. Visual design is layered on top of a conformant accessibility structure, not the other way around. This is the correct architecture. It's also the hard one to sell to teams that prototype visually first.
Twitter v2 API, 2016 launch — reminder feature added 2022
In 2016, Twitter added an alt_text field to the media object in its API. This was a significant architectural decision: image descriptions became a first-class field in the data model, not a UI feature layered on top. Every application built on the Twitter API could read and write alt text using the same mechanism as any other media property.
The impact of where you put a field in an API is hard to overstate. When alt text lives in the API contract, every client automatically gets access to it. When it's a UI-only affordance, only the native app ever exposes it, and every third-party client — including the accessible clients that blind users often build or rely on — never gets it at all.
In 2022, Twitter added an opt-in reminder that prompts users to add alt text before posting an image. This is the UI surface. But the feature only works because the API already had the field. The lesson: accessibility infrastructure in an API enables accessibility features in UIs. You can't build the reminder feature if the field doesn't exist in the data model.
Highcharts Accessibility Module — The Chart Data IS Available
Highcharts AS — accessibility module shipped as core since v7.1
Charts are one of the hardest accessibility problems on the web. A bar chart is visually intuitive. Described as a canvas bitmap to a screen reader, it's completely opaque. Highcharts solved this at the API level: every chart automatically generates a hidden accessible data table in the DOM, representing the same data the chart visualizes. VoiceOver can navigate that table as it would any other HTML table.
What makes this architecturally interesting is how the accessible table gets populated. Highcharts exposes chart data through a JavaScript API: chart.series[0].data returns the data points as an array of objects. The accessibility module reads that same API and renders the table from it. The accessible representation and the visual representation share a single source of truth — the chart data API.
ARIA live regions fire when chart data updates asynchronously, announcing the change to users who aren't looking at the chart area. The entire accessibility layer is built on top of the programmatic data API, not scraped from the visual output. This is the pattern every charting library should follow.
U.S. Federal Section 508 — Accessible Data at api.weather.gov
2018 Section 508 Refresh — WCAG 2.0 Level AA for federal ICT
The 2018 Section 508 refresh extended the accessibility requirement beyond web pages to all Information and Communications Technology — including APIs and data services. Federal data APIs at data.gov, api.census.gov, and api.weather.gov must serve accessible data, meaning the data they return has to be usable by assistive technology-dependent applications.
The National Weather Service API at api.weather.gov is a concrete example of this done well. A request to the /gridpoints/{office}/{grid_x},{grid_y}/forecast endpoint returns structured JSON where each forecast period includes a detailedForecast field: a human-readable plain-text description of the weather. "Tonight: Mostly clear, with a low around 68. South wind 5 to 10 mph." That field is machine-readable, screen reader-ready, and requires zero post-processing to present accessibly.
This is what accessible API design looks like in practice. Not just numeric values that a developer has to decode and narrate — but labeled, structured, plain-language data alongside the raw numbers. My wxaccess project uses exactly this field to surface NWS forecasts to VoiceOver users who can't read a radar map.
Apple UIAccessibility Protocol — Literally the API is the UI
iOS / macOS — UIAccessibility (iOS) and NSAccessibility (macOS)
Apple's platform accessibility model is the cleanest implementation of the "API is the UI" principle I know of. On iOS, every UIKit and SwiftUI view that VoiceOver can interact with must conform to the UIAccessibility informal protocol. VoiceOver doesn't render the view — it queries the accessibility API. The properties it reads — accessibilityLabel, accessibilityValue, accessibilityTraits, accessibilityHint — are the interface.
When a developer sets accessibilityLabel = "Volume slider" on a custom control, that string is literally what VoiceOver announces. There's no visual parsing, no heuristic inference, no fallback to coordinates. The label in the API is the label in the experience. If the developer doesn't set it, VoiceOver announces nothing useful and the control is inaccessible.
On macOS, the same principle holds via NSAccessibility. VoiceOver queries each element's accessibility role, description, and value through this protocol. Custom AppKit views that don't implement the protocol correctly are invisible to VoiceOver — regardless of how they look on screen. This is why I build TS-890 Pro VoiceOver-first: if the accessibility protocol properties aren't right, the app doesn't work for me, and no amount of visual refinement changes that.