# Open Source Accessibility What You're Getting Wrong > [!info] Deep-read port — Readwise notes field already contained a full 18-section analysis. > Ported from the existing deep-read (Refactor Appendix). A corporate strategy announcement from an interested party (GitHub's Head of Accessibility) — the three goals are stated without cost, timeline, or accountability mechanism beyond a five-year horizon. > [!question] Lingering Questions > - There's no CVE equivalent for accessibility defects in dependencies — no identifiers, no advisory database, no automated alerting. What would that infrastructure look like and who would run it? > - No baseline measurement exists for open source accessibility, which makes the five-year pledge unfalsifiable. Will the new org publish a measurement methodology or only a roadmap? > [!tip] Article Ideas > - Bring the WordPress accessibility-ready theme review to gh.io/open-source-accessibility as a "bright spot" case study — one of the very few accessibility enforcement mechanisms in any open source ecosystem, live via the 30 September re-review deadline. > [!link] Cross Reference > - [[3. Resources/MOCs/Open Source Governance MOC]] — dependency-graph propagation of quality attributes (security, accessibility, license) as a general governance problem > - [[3. Resources/MOCs/DevRel MOC]] — contribution-process accessibility as a career-economics issue, not a hospitality one > [!quote] Vocabulary > - *Census II* — the Linux Foundation's study estimating 70-90% of a typical modern application's code arrives via open source dependencies > - *NVDA* — NonVisual Desktop Access, the open source screen reader started by two blind developers in Australia, now serving 250,000+ blind users free ## Author's thesis Open source accessibility is a supply chain problem, structurally identical to open source security — if 70-90% of an application's code comes from dependencies, those dependencies bound the accessibility of everything built on them, regardless of how carefully the application layer is built. ## Key arguments (≤3) 1. Accessibility inherits through the dependency graph the same way security does — verification has to happen where the dependency enters, not just at the application layer. 2. Inaccessible contribution processes (issue trackers, review tooling, community spaces) exclude disabled developers from a credential — 51% of surveyed companies weigh open source contribution in hiring — making contribution accessibility an economic issue, not a courtesy. 3. Disabled developers already build the assistive technology they need themselves (NVDA: two blind developers, now 250,000+ users) — the strongest funding and existence-proof argument in the talk. ## Claim atoms ### Accessibility propagates through dependencies like security does > [!quote] ID: rw_ossa11y_h1 > It's a supply chain issue. Same is true for security, right? ... need to make sure they're secure. Okay, let's make sure they're accessible as well. The talk's most portable idea — converts accessibility from a moral appeal into a dependency-management question engineering teams already have a process for. ### Inaccessible contribution processes cost disabled developers careers > [!quote] ID: rw_ossa11y_h2 > what if you were excluded through no fault of your own from participating in the open source communities to get that valuable learning experience Reframes inaccessible tooling and spaces as economic exclusion with a measurable stake, not a courtesy failure. ### Accessibility is a built-environment property, assistive technology is personal > [!quote] ID: rw_ossa11y_h3 > Accessibility is a property of things that we build ... applications, websites, conferences like this one, buildings like this one, presentations like this one. Corrects a persistent, expensive confusion — teams that conflate the two try to "support screen readers" instead of building correct semantics. ### Disabled developers build the assistive technology they need > [!quote] ID: rw_ossa11y_h4 > there's two be two blind people in Australia who started that project as an open source project. Now, there's more than 250,000 blind people around the world using this open source assisted technology for free. An existence proof against the implicit doubt that disabled people can build production assistive technology — Summers uses NVDA to read his own slides while telling the story. ### Redundant response channels make audience participation multimodal > [!quote] ID: rw_ossa11y_h5 > that gives people who cannot see — I can hear the response — and of course people who cannot hear can see the raising of hands. That's why it's a multimodal accessibility hack. Zero-cost, immediately adoptable at any meetup or WordCamp. Teaches redundant-channel design by demonstration. ## Permanent candidates - **Dependency properties become product properties regardless of application effort** — strongest, most general candidate. Promoted below. - **Excluding people from contribution excludes them from the career it confers** — strong economic-framing candidate. Promoted below. ## Processing checklist - [ ] Retrieve the primary Census II figure and confirm the unit (lines of code vs. packages vs. transitive dependencies) before citing the 70-90% figure - [ ] Watch for a published measurement methodology from GitHub's five-year accessibility pledge, not just a roadmap - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — dependency-graph propagation of accessibility as a governance and supply-chain problem - [[3. Resources/MOCs/DevRel MOC]] — contribution-process accessibility as advocacy and career-pathway work - [[3. Resources/Readwise/Articles/Open Source Accessibility What You're Getting Wrong]] — source document, full deep-read