What if Your API Spoke Accessibility?
summary
Proposes embedding accessibility metadata into GraphQL so schemas carry labels, tokens and sentence templates that clients fetch alongside data, implemented with custom directives and a wiring plugin (GitHub demo). Claims: one source of truth prevents duplicated string-building, yields dynamic summaries per instance, and produces an accessibility block with human‑readable sentences consumed by Android, iOS and web. Provides data points (1.3 billion people with disabilities, ~16% global, 71% find inaccessible pages, 3–5% fully accessible) and shows consistent cross‑platform screen reader output.
AI-written summary · about
chapters (12)
- 0:00Accessible API design
- 1:09Accessibility matters
- 2:57API accessibility failures
- 4:20Cost of scattered logic
- 8:27Shift accessibility left
- 9:51Encoding semantics
- 11:37Accessibility directives in practice
- 14:47Dynamic summaries
- 15:53Client-side integration
- 17:40Single source of truth
- 19:05Open questions
- 20:33Summary
related talks
23mInclusive APIs: How to Extend OpenAPI for Accessibility
30mHow to Accessibility if You’re Mostly Back-End
51mIts Spelled Accessibility not Disability
42mAccessibility is for everyone, including you!
38mAccessibility vs latest Web APIs. Can’t we just get along?
25mBuilding empathy and accessible apps
03mIt's spelled "accessibility," not "disability"
29mProgramming for Accessibility