Open Source Accessibility What You're Getting Wrong

Open Source Accessibility: What You're Getting Wrong ![rw-book-cover](https://i.ytimg.com/vi/sV1KwNkEO0o/maxresdefault.jpg) 🔗 **Source:** [Open Source Accessibility: What You're Getting Wrong](https://www.youtube.com/watch?v=sV1KwNkEO0o) > [!note]+ Document Notes > tags: [open-source-accessibility, assistive-technology, supply-chain, disability-inclusion, github-strategy] > author: Ed Summers > source: All Things Open > reference: https://www.youtube.com/watch?v=sV1KwNkEO0o > date created: 2026-07-28 12:45 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Open source accessibility: What you're getting wrong >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Talk video — All Things Open](https://www.youtube.com/watch?v=sV1KwNkEO0o) - [Open Source Accessibility organization on GitHub](https://gh.io/open-source-accessibility) - [NVDA — NonVisual Desktop Access screen reader](https://www.nvaccess.org/) - [Linux Foundation Census II of Free and Open Source Software](https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries) - [State of Open — OpenUK report series](https://openuk.uk/stateofopen/) - [All Things Open — Inclusion & Diversity in Open Source 2025 playlist](https://youtube.com/playlist?list=PL6kQg8bP1Ji5wnMSKevYD2PgfShpcPw_4) ## 📝 Summary - **What happened.** Ed Summers, Head of Accessibility at GitHub, delivered a roughly ten-minute closing talk at All Things Open presenting the results of a six-month accessibility strategic planning process and the three-goal public pledge GitHub took in May to improve the accessibility of open source at scale. The talk was structured around two audience polls, both answered with a multimodal hand-raise-and-say-"I" mechanism that Summers explains as an accessibility technique in itself. - **Why it matters.** The central reframe is that open source accessibility is a **supply chain problem**, structurally identical to open source security. Citing the Linux Foundation's Census II, Summers puts 70 to 90% of the code in a typical modern application in its open source dependencies. If those dependencies are inaccessible, the applications built on them inherit that inaccessibility regardless of how carefully the application layer is built. This shifts accessibility from a per-product remediation task to an ecosystem-level dependency question. - **Key stakeholders.** GitHub as convener rather than leader — Summers is explicit on this point; maintainers of widely-depended-upon open source projects; developers with disabilities currently excluded from the contribution process; companies hiring on the basis of open source contribution; the assistive technology projects, exemplified by NVDA, that are themselves open source. - **Risks and tradeoffs.** The talk is a corporate strategy announcement delivered by an interested party, and the three goals are stated without cost, timeline, or accountability mechanism beyond a five-year horizon and a GitHub organization. The statistics are used in a persuasive quiz format that produces agreement rather than scrutiny. The pledge's success depends on community uptake that GitHub explicitly cannot mandate, which is both the design's integrity and its central risk. - **Bottom line.** Three goals: make mainstream open source dependencies accessible (the supply chain argument); make open source communities and contribution processes accessible so disabled developers are not excluded from the career benefit contribution confers; and support open source as a platform for people with disabilities to build their own assistive technology. The third is illustrated with NVDA — two blind developers in Australia whose open source screen reader now serves more than 250,000 blind users worldwide for free, and which Summers is using to read his own slides during the talk. ## 📖 Main Content - **Scope of the role, stated up front.** Summers describes his remit as everything accessibility-related at GitHub, internal and external — company operations, products, and events. The talk presents the output of a six-month strategic planning process with a five-year horizon and four priorities, one of which is the accessibility of open source itself. That framing matters: this is not a product accessibility talk, it is an ecosystem strategy talk. - **The scale premise.** GitHub is characterized as the place where technology gets built: 150 million developers, 4 million organizations, 90% of the Fortune 100. The mission statement attached is two-sided and the second side is the substantive one — that people with disabilities should both *benefit from* the human progress technology drives and, "perhaps most importantly," be able to *contribute to the creation* of that technology. Consumption parity is the familiar framing; production parity is the harder and less-discussed one. - **The polling method as content.** Before the first poll, Summers explains the mechanism: he is blind, so he asks the audience to both raise hands and say "I" aloud. Hearing the response serves people who cannot see; seeing the raised hands serves people who cannot hear. He names it "a multimodal accessibility hack." This is the talk's most efficient teaching moment — it demonstrates redundant-channel design in the room rather than describing it on a slide, and it costs nothing. - **Poll one — the supply chain argument.** The question: what proportion of the source code in a typical modern application, counting dependencies, originated in open source projects? Options offered were 30–50%, 50–70%, and 70–90%. The answer given is 70–90%, attributed to the Linux Foundation's Census II survey. The inference: if those dependencies are accessible, the resulting websites and products are far more likely to be accessible. Summers makes the analogy explicit — this is a supply chain issue in the same sense security is. You already check whether your dependencies are secure; check whether they are accessible. - **Poll two — the exclusion argument.** The question, sourced to the State of Open survey in the UK: what percentage of companies consider open source contribution when evaluating developer talent? Options were 22%, 45%, and 51%. The answer is 51%. The argument follows directly: if contributing to open source is a material career asset for roughly half of hiring decisions, then people excluded from open source communities through no fault of their own are excluded from that asset. This converts inaccessible contribution processes from a courtesy failure into an economic exclusion with measurable stakes. - **Goal two, stated.** Empower people with disabilities to participate in and contribute to open source. Summers is specific that this covers both the outputs and "the contribution process, the communities themselves" — issue trackers, review tooling, chat platforms, documentation, and events, not just the shipped artifact. - **The accessibility versus assistive technology distinction.** This is the talk's clearest conceptual contribution. **Accessibility** is a *property of things humans build* — applications, websites, conferences, buildings, presentations — meaning people with a wide range of abilities can enjoy what is offered. **Assistive technology** is *personal to an individual*, an extension of the person: eyeglasses, contact lenses, a white cane, a wheelchair, a guide dog. Summers illustrates with characteristic humor that his guide dog is "organic assistive technology" that, unlike a white cane, "can lick you in the face." The distinction has practical consequence: accessibility is something a project owes its users; assistive technology is something an individual selects and owns. - **Goal three and the NVDA case.** Open source is presented as an unusually good venue for people with disabilities to build their own assistive technology — because they can find others facing the same barriers, build community around a shared solution, and expand the circle of beneficiaries without a commercial gate. NVDA (NonVisual Desktop Access) is the worked example: started by two blind developers in Australia, now used by more than 250,000 blind people worldwide, free. Summers notes he is listening to NVDA in his earbuds during the talk, reading the slides interactively — the example is running while he describes it. The audience response is audible applause and cheering, the only such moment in the recording. - **The convening posture.** Summers is explicit that GitHub is not leading the effort: "GitHub's not leading this effort. We're creating the space." The first deliverable of the pledge is the Open Source Accessibility Summit running concurrently at the conference — the first of its kind — with three stated aims: bring dispersed communities together, surface existing best practices and "bright spots," and define a roadmap for improving open source accessibility. Results are to be published openly in a GitHub organization created for the purpose, at gh.io/open-source-accessibility, as the start of an ongoing community-driven global virtual collaboration. - **Uncertainties and contested claims.** The Census II figure is a real finding but the precise phrasing matters — it concerns the proportion of code in typical applications attributable to open source dependencies, and different Census II analyses report the statistic differently depending on whether the unit is lines of code, packages, or transitive dependency count. The 51% hiring figure is from a UK survey and its generalization to other labor markets is unstated. The talk gives no baseline for current open source accessibility, no measurement methodology, and no accountability structure beyond publishing to a repository. The "we're not leading" posture is genuine in intent but sits in tension with GitHub setting the goals, convening the summit, and hosting the org. ### 🗒️ Notes #### ⏱️ [00:05](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=5) Opening and scope of the accessibility remit - Summers is Head of Accessibility at GitHub, responsible for accessibility "both inside our four walls" and externally, including products and events. "My remit is all of it." - The talk presents outputs of a six-month strategic planning process with a five-year horizon. - Opens with a joke about being the last speaker of the day — sets an informal register that persists throughout and does real work in keeping a statistics-heavy talk warm. #### ⏱️ [00:52](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=52) Scale and the two-sided mission - 150 million developers, 4 million organizations, 90% of the Fortune 100 on GitHub. - The mission has two halves: people with disabilities should benefit from technology-driven human progress, and — flagged as "perhaps most importantly" — should be able to contribute to creating it. - Four strategic priorities; accessibility of open source is one, on grounds that open source is "such an integral part for technology as a whole." #### ⏱️ [01:42](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=102) The May pledge and the polling mechanism - In May, GitHub took a public pledge to help improve the accessibility of open source at scale; the All Things Open appearance is part of delivering on it. - Summers explains the poll mechanism before using it: raise your hand *and* say "I." He is blind and can hear the response; people who cannot hear can see the hands. - Names it explicitly: "that's why it's a multimodal accessibility hack." Demonstrating redundant channels in the room is more persuasive than any slide about redundant channels. #### ⏱️ [02:30](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=150) Poll one — how much of your application is open source - Question: of all code contributing to a typical website or application, including dependencies, how much originated in open source projects? - Options: 30–50%, 50–70%, 70–90%. Audience response builds across the options. - Answer: 70–90%, attributed to the Linux Foundation's Census II survey. #### ⏱️ [03:18](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=198) Goal one — accessibility as a supply chain issue - Goal one: increase the accessibility of mainstream open source projects being incorporated into everyday products and websites. - The mechanism: accessible dependencies greatly increase the chance the resulting product is accessible. - The analogy is stated directly — this is a supply chain issue, the same as security. You verify dependencies are secure; verify they are accessible too. This is the talk's most portable idea. #### ⏱️ [04:05](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=245) Poll two — open source contribution and hiring - Sourced to the State of Open survey in the UK: do companies consider open source contribution when evaluating developer talent? - Options: 22%, 45%, 51%. Answer: 51%. - The argument: open source contribution is "a huge plus for your resume and your ability to get a job." Being excluded from that experience through no fault of your own is an economic exclusion, not merely a social one. #### ⏱️ [05:44](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=344) Goal two — accessible contribution processes - Goal two: empower people with disabilities to be part of open source and contribute. - Scope explicitly includes "both the outputs and the contribution process, the communities themselves" — tooling, events, and community spaces, not just shipped software. - The framing is "accessible and welcoming to everyone," pairing a technical property with a social one. #### ⏱️ [05:44](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=350) Accessibility versus assistive technology - Accessibility is a property of things humans build: applications, websites, conferences, buildings, presentations. It means people with a wide range of abilities can enjoy what is offered. - Assistive technology is personal, "kind of an extension of your person": eyeglasses, contact lenses, white canes, wheelchairs. - Summers's guide dog is "organic assistive technology" — the joke that a white cane "cannot lick you in the face" lands the distinction better than a definition would. "We're a team." - A wheelchair is offered as the low-tech, no-tech example, which usefully widens the category beyond software. #### ⏱️ [07:21](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=441) Goal three and the NVDA story - Open source is "an amazing place for people with disabilities to build their own solutions for their access challenges in the form of assistive technology." - The pattern: find others facing the same barriers, build community around the solution as an open source project, expand the circle of people who benefit. - NVDA — NonVisual Desktop Access — started by two blind people in Australia. More than 250,000 blind people worldwide now use it, free. - Summers is listening to NVDA in his earbuds during the talk: "what you see on the screen, I'm reading it in my earbud interactively." - The only cheering and applause in the recording follows this segment. #### ⏱️ [08:11](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=491) The summit and the convening posture - The Open Source Accessibility Summit is running concurrently at the conference — the first one, and the pledge's first deliverable. - Explicit disclaimer of leadership: "GitHub's not leading this effort. We're creating the space for people in the community." - Participants named: people with disabilities, developers, people from companies. - The goal is to find what is already working across the ecosystem and accelerate it, rather than to start something new. #### ⏱️ [09:01](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=541) Summit goals and how to get involved - Three summit goals: bring dispersed communities together to meet and share current best practices and "bright spots"; discuss challenges; and — "most importantly" — define a roadmap for improving open source accessibility. - Results published openly in a new GitHub organization, "open source accessibility," as the beginning of a community-driven global virtual collaboration. - Entry point: gh.io/open-source-accessibility, words separated by hyphens, or the QR code on screen. - Closes on time with evident satisfaction: "I crushed it. Like 10 minutes. Boom." ## 📚 References - [Ed Summers — Improving Accessibility Of Open Source Software, All Things Open](https://www.youtube.com/watch?v=sV1KwNkEO0o) - [Open Source Accessibility org on GitHub](https://gh.io/open-source-accessibility) - [NV Access — NVDA screen reader](https://www.nvaccess.org/) - [Linux Foundation — Census II of Free and Open Source Software](https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries) - [OpenUK — State of Open reports](https://openuk.uk/stateofopen/) - [All Things Open 2026](https://2026.allthingsopen.org/) - [WCAG 2.2 — W3C Recommendation](https://www.w3.org/TR/WCAG22/) ## 🗣️ Paraphrase - **Opening.** Summers introduces himself as GitHub's Head of Accessibility with responsibility for everything accessibility-related, internally and externally, and offers the results of a six-month strategic planning process. - **Scale and mission.** GitHub hosts 150 million developers, 4 million organizations, and 90% of the Fortune 100. The technology built there drives human progress, and the accessibility mission is that people with disabilities both benefit from that progress and — most importantly — can contribute to creating it. - **The pledge.** One of four five-year priorities is the accessibility of open source, and in May GitHub publicly pledged to help improve it at scale. The conference appearance is part of that. - **The polling method.** Summers is blind, so he asks the audience to raise hands and say "I" aloud — he hears the response, and people who cannot hear can see the hands. He calls this a multimodal accessibility hack. - **The supply chain figure.** Asked what share of a typical application's code comes from open source dependencies, the answer is 70 to 90%, per Linux Foundation Census II. - **Goal one.** Increase the accessibility of the mainstream open source projects being built into everyday products. Accessible dependencies make accessible products far likelier. This is a supply chain issue in exactly the way security is — you check that dependencies are secure, so check that they are accessible. - **The hiring figure.** Per the UK State of Open survey, 51% of companies consider open source contribution when assessing developer talent. - **Goal two.** Since contribution is a substantial career asset, excluding people from open source communities through no fault of their own excludes them economically. So both open source outputs and the contribution process — the communities themselves — must be accessible and welcoming, including to people with disabilities. - **The distinction.** Accessibility is a property of things humans build — applications, websites, conferences, buildings, presentations — meaning people with a wide range of abilities can enjoy what is offered. Assistive technology is personal, an extension of the individual: glasses, contacts, white canes, wheelchairs. A guide dog is organic assistive technology, and unlike a white cane it can lick you in the face. - **Goal three.** Open source is an excellent venue for people with disabilities to build their own access solutions, find others facing the same barriers, form communities around those solutions, and widen the circle of beneficiaries. - **NVDA.** Two blind developers in Australia started the NonVisual Desktop Access screen reader as an open source project. More than 250,000 blind people now use it worldwide for free. Summers is using it to read his slides as he speaks. - **The summit.** The first Open Source Accessibility Summit is happening at the conference as the pledge's first deliverable, but GitHub is not leading it — it is creating space for community members, developers, people with disabilities, and companies to convene. - **Summit aims and next steps.** Bring dispersed communities together, share existing best practices and bright spots, discuss challenges, and define a roadmap. Publish everything openly in a new GitHub organization as the start of an ongoing global collaboration, reachable at gh.io/open-source-accessibility. ## 📰 Newsletter **Accessibility is a supply chain problem.** That single reframe from Ed Summers, GitHub's Head of Accessibility, is worth the ten minutes this talk runs. Linux Foundation Census II data puts 70 to 90% of the code in a typical application in its open source dependencies. You already ask whether those dependencies are secure. Summers's argument is that you should be asking whether they are accessible, because if they are not, no amount of care at your application layer will save you — you inherited the problem at install time. For the WordPress world this lands with unusual force this month. The Themes team just extended its accessibility-ready re-review deadline to 30 September, with delisting on the table for authors who do not at least engage the process. That is the same supply chain logic applied one layer up: if the theme is inaccessible, every site built on it starts inaccessible. Worth reading the two stories together. The second statistic is the one I keep thinking about. Per the UK State of Open survey, 51% of companies weigh open source contribution when they evaluate developer talent. So when a contribution process is inaccessible — the issue tracker, the review tooling, the chat, the WordCamp — the exclusion is not a courtesy failure. It is an economic one, and it compounds over a career. Best moment in the talk: Summers explains his audience poll before running it. Raise your hand *and* say "I" — he is blind and can hear you, and anyone who cannot hear can see the hands. He calls it a multimodal accessibility hack. It costs nothing, it works in any room, and it teaches redundant-channel design better than any slide could. Steal it for your next meetup. Also worth knowing: NVDA, the screen reader a quarter of a million blind people use for free, was started by two blind developers in Australia as an open source project. Summers was listening to it read his own slides while he gave the talk. If you want a single answer to "why does open source accessibility matter," that is it. The Open Source Accessibility org is at [gh.io/open-source-accessibility](https://gh.io/open-source-accessibility), and the summit outputs are published there. [Talk is here](https://www.youtube.com/watch?v=sV1KwNkEO0o). ## ✅ Action Items #### DevRel - Developer advocacy: adopt the supply chain framing in accessibility talks — it converts accessibility from a moral appeal into a dependency-management argument that engineering audiences already know how to act on. - Education: teach the accessibility-versus-assistive-technology distinction explicitly; conflating them is why teams try to "support screen readers" instead of building accessible semantics. - Developer experience: audit your own contribution path end to end with a screen reader — issue templates, CONTRIBUTING docs, CI output, review interface. The output being accessible does not mean the process is. - Developer marketing: cite the 51% hiring figure when making the business case for accessible community spaces; it reframes inclusion as talent-pipeline economics. - Community management: adopt the multimodal poll technique at every event, and write it into the organizer handbook — it costs nothing and demonstrates the principle in the room. - Internal/external/cross-project: join the Open Source Accessibility org and contribute existing practices rather than waiting for the roadmap to be finished. #### OSPO - Policy & Governance: add accessibility to dependency review policy alongside license and security review — the supply chain argument makes this a natural extension of existing gates rather than a new process. - License Compliance: not applicable to this source directly, though the same review checkpoint can carry both checks. - Security Management: the security analogy is the talk's rhetorical engine; reuse the existing vulnerability-intake pattern for accessibility defects in dependencies, including a disclosure and triage path. - Software Inventory: extend SBOM thinking to record accessibility conformance status for critical dependencies — currently nobody does this and the tooling gap is the reason. - Developer Support: provide assistive-technology testing environments as shared infrastructure; individual teams will not each stand one up. - Community Engagement: fund the open source assistive technology projects your organization depends on — NVDA is used by 250,000 people and is chronically under-resourced relative to that reach. - Strategic Alignment: set a measurable accessibility target for your top-N dependencies rather than for your own products alone. #### Community - Maintainers: publish an accessibility conformance statement for your project, even if it says "unknown" — the baseline is currently unmeasured everywhere and stating that honestly is the first useful step. - Contributors: file accessibility issues against widely-used dependencies, not just against applications; the leverage is far higher upstream. - Sponsors: fund accessibility work in dependencies rather than only in flagship products, and report on it. - Ecosystem: participate in the roadmap being defined at gh.io/open-source-accessibility rather than building a parallel effort. #### WordPress - Core: apply the dependency framing to bundled libraries and the packages Core ships — Core's accessibility is bounded by theirs. - Core Performance: not applicable to this source. - Core AI: ensure AI-generated markup meets accessibility requirements before it reaches users; generation without an accessibility gate reproduces the supply chain problem at speed. - **Core Program Team:** add accessibility conformance to the cross-team dependency review that already happens for security and licensing. - Mobile: audit the mobile app contribution process, not just the app, against the goal-two standard. - Playground: Playground is an unusually good venue for accessibility education — a reproducible environment where contributors can practice with assistive technology without local setup. - Community: adopt the multimodal poll technique in meetup and WordCamp organizer kits; add it to speaker mentorship as a default practice. - Training: build a lesson on the accessibility-versus-assistive-technology distinction — it is a persistent conceptual confusion and a short, high-value lesson. - Marketing: use the supply chain framing rather than compliance framing; compliance framing produces minimum-viable effort. - Support: document assistive technology compatibility for common workflows so support can answer confidently. - Design: apply the redundant-channel principle the poll demonstrates to design system components generally — never convey information through one channel alone. - Documentation: audit docs for screen reader navigability, and document the contribution process from an assistive technology user's perspective. - Photos: require and review descriptive alt text as a submission criterion, not a nice-to-have. - TV: caption quality is the direct analogue of goal two — an inaccessible archive excludes people from learning material that supports contribution. - Polyglots: accessibility guidance needs translation; the goal-two exclusion compounds for non-English-speaking disabled contributors. - Accessibility: bring the accessibility-ready theme work to the Open Source Accessibility summit as a "bright spot" — the WordPress theme review process is one of the few enforcement mechanisms that exists anywhere in open source, and the ecosystem should know about it. - Meta: audit .org contributor tooling — Trac, make blogs, Slack — against goal two; the contribution process is the product here. - CLI: ensure CLI output is screen-reader friendly, including progress indicators and tabular output. - Hosting: not applicable to this source directly. - Tide: consider an accessibility dimension in plugin scoring — this is exactly the supply chain check Summers is asking for, and Tide is the existing mechanism. - Openverse: ensure media metadata supports accessible reuse, including alt text provenance. - Themes: the accessibility-ready guidelines and the 30 September re-review deadline are the ecosystem's strongest existing implementation of goal one; document the process as a reusable model. - Plugins: extend accessibility review to plugins, where no equivalent of the accessibility-ready standard currently exists — this is the largest single accessibility gap in the WordPress supply chain. #### The WPOCC - Programs: fund a fellowship for a disabled contributor working on accessibility in widely-depended-upon projects, addressing goals two and one simultaneously. - Projects: run a documentation sprint producing an accessibility conformance statement template that any open source project can adopt. - Funding experiments: pilot microgrants for accessibility fixes in high-dependency-count packages, with a transparent ledger showing downstream reach per grant. ### FAIR - Technical independence: accessibility conformance metadata is exactly the kind of provenance signal FAIR's model already carries — add it as a field rather than building a separate system. - Policies and covenants: an accessibility covenant is a natural companion to existing funding-transparency covenants and is currently missing from every governance template in circulation. - Productized governance artifacts: ship an accessibility conformance scorecard alongside the existing operator agreement templates. ## 🧪 Hypotheses - **H1.** Applications whose top dependencies conform to WCAG 2.2 AA achieve accessibility conformance at materially lower remediation cost than applications with equivalent effort applied only at the application layer. - **H2.** Open source projects whose contribution processes are screen-reader navigable attract and retain a higher proportion of contributors with disabilities than comparable projects that are not. - **H3.** The 51% hiring figure understates the effect for entry-level roles, where portfolio evidence substitutes for professional experience and open source contribution carries proportionally more weight. - **H4.** Assistive technology projects built by their own users — the NVDA pattern — achieve higher usability ratings from disabled users than equivalent projects built for them by non-disabled developers. - **H5.** Publishing an accessibility conformance statement, even one reporting non-conformance, increases the rate of accessibility issue reports and contributions a project receives. - **H6.** Accessibility defects in transitive dependencies persist substantially longer than security defects of comparable severity, because no equivalent of the CVE and advisory pipeline exists for accessibility. ### 📊 Methodology - **For H1 (comparative cost study).** Recruit teams remediating comparable applications, stratified by whether their major dependencies are already conformant. Measure engineer-hours to reach a defined conformance level and the count of defects traced to dependency versus application code. The confound to control is team accessibility expertise, which likely correlates with dependency choice; measure it directly rather than assuming it away. - **For H2 (observational plus survey).** Audit a sample of projects' contribution processes with automated and manual assistive technology testing, then survey their contributor bases on disability status using validated, voluntary, anonymous instruments. Self-selection and disclosure reluctance are serious limitations here and must be reported rather than glossed — disabled contributors have well-founded reasons not to disclose. - **For H3 (hiring study).** Survey hiring managers with a factorial design varying candidate seniority and presence of open source contribution, measuring interview callback intent. A resume audit study would be stronger but raises ethical issues with real employers that would need review. - **For H4 (usability testing).** Compare user-built and externally-built assistive technology in the same category on task completion and satisfaction with disabled users. Matching on maturity and funding is essential and difficult, since user-built projects are systematically under-resourced. - **For H5 (natural experiment).** Track issue and contribution rates before and after conformance statement publication across projects that adopt one, using projects that do not as a comparison. Announcement effects will confound the immediate window; measure at 90 days. - **For H6 (longitudinal defect tracking).** Compare time-to-resolution for accessibility versus security defects in the same dependency set. The infrastructural asymmetry is the point: security has CVE identifiers, advisory databases, and automated alerting, and accessibility has none of these. Documenting the resulting resolution gap would be the strongest available argument for building that pipeline. - **On the source statistics.** Both figures should be retrieved from primary sources before reuse. Census II reports open source proportion under several different unit definitions, and the 70–90% band depends on which is used. The State of Open figure is UK-specific and its generalization is unstated. ### ❓ Questions - What would an accessibility equivalent of the CVE pipeline look like, and who would operate it? - Can accessibility conformance be automatically detected in dependencies well enough to gate a build, or does it irreducibly require manual assessment? - What proportion of open source projects have ever been tested with a screen reader, and how would we find out? - Does GitHub's "we're creating the space, not leading" posture survive contact with the roadmap, where someone must decide priorities? - How should accessibility work in dependencies be funded when the beneficiaries are downstream and diffuse and the maintainer is unpaid? - What is the current accessibility baseline for open source contribution tooling, and why has nobody measured it? - Does the WordPress accessibility-ready theme review process — one of the few enforcement mechanisms anywhere in open source — generalize to other ecosystems, and what would it take to port it? - Where is the line between accessibility as a project's obligation and assistive technology as an individual's choice, in cases like keyboard-only operation that sit between the two? ### 🔮 Future Research - **The accessibility advisory pipeline.** Security solved dependency-defect propagation with identifiers, databases, and automated alerting. Accessibility has none of this infrastructure. Designing it is the highest-leverage open problem the talk implies without naming. - **Baseline measurement of open source accessibility.** No credible ecosystem-wide baseline exists. Without one, the pledge's five-year progress claim is unfalsifiable, which is a weakness worth fixing early rather than late. - **The contribution process as accessibility surface.** Research overwhelmingly examines accessibility of software outputs. The tooling by which software gets made — issue trackers, review interfaces, CI logs, chat, conferences — is nearly unstudied and is precisely what goal two targets. - **Economic modeling of the exclusion.** The 51% hiring figure supports estimating the lifetime earnings cost of exclusion from open source participation for developers with disabilities. That number does not exist and would change funding conversations. - **User-built assistive technology as a design paradigm.** The NVDA pattern — those affected building the solution and expanding the circle — is under-theorized relative to its success and may generalize well beyond disability. - **Enforcement mechanism comparison.** The WordPress accessibility-ready review is a rare case of an open source ecosystem enforcing accessibility as a directory condition. Comparative study of what makes such mechanisms work, and what they cost the community in review labor, would inform every ecosystem attempting goal one. ### 💡 Implications - **Practice.** The immediately actionable item is adding an accessibility check to the dependency review you already perform for security and licensing. This requires no new process, only a new question at an existing gate. - **Policy.** Accessibility procurement requirements — already legally binding for many public-sector buyers — flow through to dependencies whether or not the requirement mentions them. Organizations subject to those requirements have an unexamined compliance exposure sitting in their package manifests. - **Security.** The analogy runs both ways and the asymmetry is instructive: security built identifiers, advisories, and automated alerting to solve exactly the propagation problem accessibility now faces, and the accessibility field can copy that architecture rather than inventing one. - **Education.** The accessibility-versus-assistive-technology distinction is a small conceptual correction with large downstream effects on how teams scope work. It belongs early in any curriculum, and its absence explains a common category of well-intentioned mistakes. - **Funding models.** Assistive technology built by its own users — NVDA serving 250,000 people — is a public good with no revenue model. The funding gap between reach and resourcing is the starkest example in the talk of open source's general sustainability problem, sharpened by the fact that the users most dependent on it have the least market power. - **Equity.** The talk's strongest argument is the one about production rather than consumption: excluding disabled developers from contribution excludes them from a career asset that half of employers value, and that exclusion compounds across a working life. Consumption parity has been the accessibility field's default framing for decades; production parity is the harder and more consequential goal, and it is the one that determines who gets to decide what accessible technology looks like. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level approximately 8–9 for the spoken transcript; Flesch Reading Ease approximately 62. Conversational register with short sentences, direct address, and deliberate repetition of key terms. Domain vocabulary is minimal and defined where used. Genuinely accessible to a non-specialist audience, which for a talk about accessibility is appropriate rather than incidental. #### 👀 Visual learners - Present: slides with the three goals and a QR code linking to the GitHub organization; Summers offers "you can snap a photo of that." - Improve: the talk is delivered by a blind speaker who cannot verify his own slides, and the transcript suggests visual content is minimal. A published slide deck with the statistics, sources, and the accessibility-versus-assistive-technology distinction as a diagram would help visual learners without compromising the talk's design. The supply chain argument in particular wants a dependency-tree diagram. #### 🔊 Aural learners - Present: excellent. This is a spoken talk with a natural conversational cadence, audible audience participation, and laughter and applause that mark the emotional beats. - Improve: nothing significant. A standalone audio release would serve this content well, since it loses almost nothing without video. #### 🗣️ Verbal learners - Present: outstanding — the talk's strongest dimension. The accessibility-versus-assistive-technology distinction is built entirely through verbal definition and analogy, and the guide dog joke ("white canes cannot lick you in the face") makes an abstract taxonomy memorable in one line. - Improve: define "multimodal" once; it is used as a technical term after being demonstrated, and the demonstration carries most of the meaning for anyone who was in the room but not for a transcript reader. #### 🧩 Kinesthetic learners - Present: strong and unusual. The audience physically participates in two polls, and the poll mechanism is itself the lesson. The QR code provides an immediate next action. - Improve: a "test your own project" exercise — install a screen reader, navigate your CONTRIBUTING file — would extend the participation past the room. The summit provides this for attendees; remote viewers get only a URL. #### 🧠 Logical learners - Present: clear structure — three goals, each introduced by a statistic that motivates it. The supply chain analogy to security is a well-formed argument by structural similarity. - Improve: no baseline, no metrics, and no timeline are given for the five-year plan, which leaves the strategic claims unfalsifiable. Sources are named verbally but not cited precisely enough to check. State the measurement approach even briefly. #### 🧑‍🤝‍🧑 Social learners - Present: exceptional. The entire third act is about convening — a summit, a community roadmap, an open organization, explicit invitation to participate. The NVDA story is fundamentally about community formation among people sharing a barrier. - Improve: name the specific ways to contribute beyond visiting a URL; "get involved" is an invitation without a first task attached. #### 🧘‍♀️ Solitary learners - Present: the QR code and short URL provide a self-directed entry point, and the talk is short enough to absorb in one sitting. - Improve: reflection prompts — "which of your dependencies have you ever tested with assistive technology?" — would convert a talk into a personal audit. Published summit outputs partly fill this gap. #### 🌿 Naturalistic learners - Present: the supply chain and ecosystem framing throughout; the guide dog as "organic assistive technology" is a genuinely naturalistic framing of a technical category. - Improve: the sustainability angle is available and unused — NVDA serving 250,000 users on volunteer effort is an ecosystem-health story as much as an accessibility one, and connecting them would strengthen both. ### 📊 Accessibility Assessment *Assessing the talk as delivered and as published on YouTube.* #### Screen reader semantics - Present: not directly applicable to a video, but notable that the speaker uses NVDA live and the presentation is designed around non-visual operation. - Improve: the YouTube description provides chapter markers, which is good structural practice. The linked GitHub organization should be verified for screen reader navigability — a repository is the wrong venue for a roadmap if the roadmap is about accessibility and the venue is not tested. Maps to WCAG 2.2 AA 1.3.1 Info and Relationships. #### Keyboard navigation - Present: not applicable to the video artifact itself. - Improve: the QR code as a primary call to action is a keyboard-and-screen-reader-hostile pattern; Summers mitigates this well by reading the URL aloud and spelling out the hyphenation, which is exactly the right redundancy. Worth naming as the model practice. Maps to WCAG 2.2 AA 2.1.1 Keyboard. #### Contrast and readability - Present: unassessable from the transcript; slide contrast unknown. - Improve: a blind speaker cannot self-verify slide contrast, which is a structural reason to have slides reviewed by a sighted colleague — and a good illustration that accessibility is a team property. Maps to WCAG 2.2 AA 1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast. #### Text resizing and reflow - Present: YouTube's player supports zoom and responsive layout. - Improve: if slide text is small, mobile viewers lose it entirely; the spoken content carries the argument, which is fortunate but should be by design. Maps to WCAG 2.2 AA 1.4.4 Resize Text. #### Media and captions - Present: automatic captions are available in English, and the description includes timed chapter markers. - Improve: automatic captions only — no human-reviewed caption track. For a talk about accessibility this is a meaningful gap, and auto-captions demonstrably mangle proper nouns and technical terms. No audio description track, and no published transcript. Maps to WCAG 2.2 AA 1.2.2 Captions (Prerecorded) and 1.2.5 Audio Description (Prerecorded). #### Forms and interactions - Present: the audience poll is the interaction, and it is deliberately designed to be multimodal. - Improve: none for the poll — it is the exemplar. The QR code is the only other interaction and is already mitigated by the spoken URL. Maps to WCAG 2.2 AA 3.3.2 Labels or Instructions. #### Standards reference - The most consequential gap is the absence of human-reviewed captions and a published transcript (WCAG 2.2 AA 1.2.2, 1.2.5) on a talk about accessibility. The audience poll technique is a genuine exemplar of redundant-channel design that no WCAG criterion captures because it operates in physical space. ### 🌍 DEIB Assessment #### Cultural breadth - Present: two of the three cited data sources are non-US — the UK State of Open survey and the Australian origin of NVDA — and NVDA's 250,000 users are explicitly global. - Improve: the framing is otherwise US-centric, with GitHub scale expressed via the Fortune 100. Accessibility law, assistive technology availability, and disability social models vary enormously across regions, and cost of assistive technology is a determining factor in much of the world. The pledge's global ambition would be better served by naming that variation. #### Inclusive language - Present: strong. Person-first and identity-first language used appropriately — "people with disabilities" alongside Summers's own direct "I'm blind," which is his to choose. "People with a wide range of abilities" avoids the deficit framing common in this material. - Improve: minimal jargon and what exists is defined. "Multimodal" is the only unexplained term. This is among the most linguistically accessible talks in the corpus. #### Neurodiversity support - Present: clear numbered structure (three goals), consistent signposting, short duration, and explicit recaps — "just a quick recap of the goals here." - Improve: pace is fast by the speaker's own admission ("I'm going to move on really fast"), and the two polls introduce interaction density that some attendees will find taxing. Published slides and a transcript would let people process at their own pace, and their absence disproportionately affects this group. #### Representation - Present: exceptional, and the talk's defining feature. A blind speaker presents on accessibility using the assistive technology in question, live. The NVDA story centers two blind developers as builders rather than beneficiaries. Goal three is explicitly about people with disabilities creating their own solutions — agency rather than service delivery. Summers's guide dog is present in the framing as a team member. - Improve: disability is represented almost entirely through blindness. Deaf, motor, cognitive, and psychiatric disability perspectives are absent except in the poll design, which does account for deaf attendees. The talk's brevity explains but does not remove this. #### Psychological safety - Present: notably strong. Humor is self-directed and warm, never at anyone's expense. The poll design ensures nobody is excluded from participating. Summers models disability disclosure comfortably and matter-of-factly, which does more for safety than any stated policy. The framing consistently locates the problem in built environments rather than in people. - Improve: no content warning needed. The talk could acknowledge that disclosing disability in professional and open source contexts carries real risk — the goal-two argument about exclusion implies it but stops short of saying so, and contributors weighing whether to disclose would benefit from hearing it named. ### ✅ Logical Validity #### Strong reasoning - **Analogical reasoning from security to accessibility.** The talk's central argument and its best one: open source dependencies constitute most of the code in a typical application, therefore dependency properties propagate to the product, therefore accessibility — like security — must be verified at the dependency layer. The analogy is structurally sound because the propagation mechanism is genuinely identical, and it borrows a mental model the audience already holds. This is why the argument lands in ten minutes. - **Valid conditional inference on exclusion.** If open source contribution materially affects hiring (51% of companies), and if contribution processes are inaccessible, then people with disabilities are excluded from a material career asset. The conditional is well-formed and the conclusion follows. Summers strengthens it with "through no fault of your own," which correctly locates responsibility in the environment rather than the individual. - **Argument by existence proof.** NVDA answers the implicit objection "can people with disabilities actually build production assistive technology?" with a running counterexample serving 250,000 users — and the speaker is using it as he asks. An existence proof is logically decisive against a universal doubt, and this one is unusually vivid. - **Well-constructed conceptual distinction.** The accessibility-versus-assistive-technology division is drawn on a real dimension — property of a built thing versus personal extension of an individual — and is immediately consequential for who owes what to whom. The examples span technology levels (eyeglasses, wheelchairs, guide dogs, screen readers), which tests the distinction rather than merely illustrating it. - **To clarify further:** the supply chain argument would be stronger with a stated baseline. "Dependencies matter" is established; "dependencies are currently inaccessible at rate X" is asserted only implicitly. #### Fallacies - **Loaded question format in the polls.** Location: both audience polls. The answer options are constructed so the correct answer is the extreme of the offered range (70–90% for the code question; 51% as the highest of 22%/45%/51%). Audiences reliably underestimate against such a scale, which manufactures a surprise that feels like a revelation. **Fix:** offer options bracketing the true value symmetrically. The pedagogical effect is real but the persuasive mechanism is the option design, not the finding. - **Ambiguity in the headline statistic.** Location: "how many lines of code are have been open source apart from an open source project?" — the question is asked in terms of lines of code, but Census II's findings are typically reported in terms of package and dependency composition. The 70–90% figure is real but shifts meaning depending on the unit. **Fix:** state the unit precisely; the argument survives either way, so the imprecision buys nothing. - **Hasty generalization from a UK survey.** Location: the 51% hiring figure, sourced to "the state of open in the UK," presented to a US audience as a general claim about "technology professionals." Hiring practices around open source contribution vary substantially across labor markets. **Fix:** name the scope, then argue the direction generalizes even if the magnitude does not. - **Appeal to scale (weak relevance).** Location: "150 million developers, 4 million organizations, 90% of the Fortune 100." These figures establish GitHub's reach but do no work in the accessibility argument; they function to establish authority to convene. **Fix:** harmless as framing, but it is persuasion by position rather than by evidence, and worth recognizing as such. - **Unfalsifiable strategic claim.** Location: the pledge to "improve the accessibility of open source at scale" over five years, with no baseline, metric, or timeline. Without a measurement, no future state can count as failure. **Fix:** publish the baseline measurement methodology alongside the roadmap. This is the single most important improvement available to the initiative. - **Tension between disclaimer and structure (not strictly a fallacy).** Location: "GitHub's not leading this effort. We're creating the space." GitHub set the goals, took the pledge, convened the summit, created the organization, and owns the platform. The disclaimer is sincere and the convening posture is genuinely better than a directive one, but the structural asymmetry is real and unacknowledged. **Fix:** name the asymmetry and describe how roadmap decisions will be made, which is where it will actually bite. #### Tone of voice - Warm, brisk, and self-deprecating, with humor doing structural work rather than decorating the edges. Summers uses jokes to make taxonomies memorable ("white canes cannot lick you in the face," "organic assistive technology") and to manage his own authority ("the last speaker is always the best speaker," "I crushed it. Like 10 minutes. Boom."). The register is inclusive by construction — the poll mechanism is explained rather than assumed, which signals to the room that being unable to see or hear is planned for rather than accommodated after the fact. Corporate strategy content is delivered without corporate distance; the mission language ("technology drives human progress") is the only stretch of conventional company register, and it is brief. Notably, the emotional peak of the talk is not about GitHub at all — it is the NVDA story, which is the only moment that draws applause. ### 🛡️ DARVO Analysis - **Deny:** Not present. The talk makes no denial or minimization move. It states an unflattering premise about the current state of open source accessibility — that it needs improvement at scale — without deflecting responsibility onto users, standards bodies, or anyone else. - **Attack:** Not present. No party is criticized. Notably, the talk does not attack projects or companies for poor accessibility, framing the problem structurally instead. Whether that restraint reflects diplomacy required of a convener or genuine analysis is not determinable from the talk, but the effect is that no one in the audience is put on the defensive — which is likely the right choice for a convening posture. - **Reverse victim/offender:** Not present. The framing is consistently that built environments exclude people, which places responsibility on builders — including, implicitly, the audience and GitHub itself. This is the opposite of a victim-offender inversion. - **Emotional cues and rhetoric:** The persuasive devices are the poll surprises, the guide dog humor, and the NVDA story, which carries the talk's only real emotional charge — the applause is genuine and it lands on a story about disabled people building for themselves rather than on any GitHub commitment. The relevant fallacies are the loaded poll construction and the appeal to scale, both ordinary presentation technique rather than defensive maneuvering. - **Assessment:** No DARVO pattern present. This is a strategy announcement and community invitation, not a defense against accusation, so the framework has no target. The appropriate critical lens is corporate-interest disclosure: GitHub is an interested party convening an ecosystem effort that will shape norms it must itself meet, and the talk is transparent about GitHub's role while somewhat understating its structural power. Noted rather than omitted, per template requirements. ## 🎯 Conclusion - **Bottom line.** Accessibility in open source is a supply chain property, not a per-application task. With 70 to 90% of a typical application's code arriving through dependencies, accessibility must be verified where security already is — at the dependency layer. The second argument is equally sharp and less often made: with roughly half of employers weighting open source contribution in hiring, an inaccessible contribution process is an economic exclusion that compounds across a career. The third is the one that draws applause — open source is where people with disabilities build their own assistive technology, and NVDA serving 250,000 users for free is the proof. - **The conceptual correction is portable.** Accessibility is a property of what we build; assistive technology is personal to the individual. Teams that conflate these end up trying to support particular tools rather than building correct semantics, and the distinction is a two-sentence fix to a persistent and expensive confusion. - **The weakness is measurement.** A five-year pledge with no baseline, no metric, and no timeline cannot fail, which means it also cannot demonstrably succeed. The most valuable thing the new Open Source Accessibility organization could publish first is not a roadmap but a baseline measurement methodology. - **Next steps for readers.** 1. Add one question to the dependency review you already run for security and licensing: has this been tested with assistive technology? Most answers will be "unknown," and knowing that is the start. 2. Navigate your own project's contribution path — CONTRIBUTING file, issue template, review interface — with a screen reader. Goal two is about the process, and almost nobody has checked theirs. 3. Adopt the multimodal poll technique at your next meeting or meetup. Raise a hand *and* say it aloud. It costs nothing and teaches redundant-channel design better than a slide. 4. Fund or contribute to the open source assistive technology you depend on. NVDA's reach and its resourcing are not in the same order of magnitude. 5. Bring existing "bright spots" to gh.io/open-source-accessibility rather than waiting for a roadmap — the WordPress accessibility-ready theme review is one of the few enforcement mechanisms in open source anywhere, and that ecosystem should know it exists. ## 🔄 Refactor Appendix — Open source accessibility: What you're getting wrong > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) ### [H1] Accessibility propagates through dependencies like security does > [!quote] > It's a supply chain issue. Same is true for security, right? If you're building an application or website, you're using open-source projects, you need to make sure they're secure. Okay, let's make sure they're accessible as well. **Context & use**: - [03:18](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=198), immediately after the poll establishing that 70–90% of a typical application's code comes from open source dependencies. - The talk's most portable idea. Converts accessibility from a moral appeal into a dependency-management question engineering teams already have a process for, which is why it can be adopted at an existing gate rather than requiring a new one. **Tags**: #xref #share  ### [H2] Inaccessible contribution processes cost disabled developers careers > [!quote] > what if you were excluded through through no fault of your own excluded from participating in the open source communities to get that valuable learning experience **Context & use**: - [04:54](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=294), following the poll result that 51% of companies weigh open source contribution in hiring. - Reframes inaccessible issue trackers, review tooling, and community spaces as economic exclusion with a measurable stake rather than a courtesy failure. The strongest available argument for auditing the contribution path, not just the shipped product. **Tags**: #xref #articleseed  ### [H3] Accessibility is built-environment property, assistive technology is personal > [!quote] > Accessibility is a property of things that we build, things that humans create, applications, websites, conferences like this one, buildings like this one, presentations like this one. **Context & use**: - [05:44](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=344), opening the third goal. - Corrects a persistent and expensive confusion. Teams that conflate the two try to "support screen readers" instead of building correct semantics. The complement — assistive technology as an extension of the person, including a guide dog — is what makes the distinction stick. **Tags**: #xref #aphorisms  ### [H4] Disabled developers build the assistive technology they need > [!quote] > 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. **Context & use**: - [07:21](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=441), the NVDA story — the only moment in the talk drawing applause. - An existence proof against the implicit doubt that disabled people can build production assistive technology, made vivid by the speaker using NVDA to read his own slides as he tells it. Also the clearest funding argument in the talk: 250,000 users, volunteer origins. **Tags**: #xref #share  ### [H5] Redundant response channels make audience participation multimodal > [!quote] > that gives people who cannot see I can hear the response and of course people who cannot hear can see the raising your hands. That's why it's a multimodal accessibility hack. **Context & use**: - [02:30](https://www.youtube.com/watch?v=sV1KwNkEO0o&t=150), explaining the poll mechanism before running it. - Zero-cost, immediately adoptable at any meetup, WordCamp, or meeting. Teaches redundant-channel design by demonstration rather than description — the single most stealable thing in the talk. **Tags**: #xref #aphorisms #share  ### 🧠 Permanent Candidates (H4) #### [P1] Dependency properties become product properties regardless of application effort **Claim** (one sentence, Courtney's voice): Any quality attribute that propagates through a dependency graph — security, accessibility, license obligation, performance floor — must be verified where the dependency enters, because no amount of care at the application layer can recover it afterwards. **Evidence pointer**: [[#H1]] — 70–90% of a typical application's code arrives through open source dependencies, so their accessibility bounds the product's. **Scope & conditions**: - Holds when: the attribute is genuinely inherited rather than merely influenced — true of accessible semantics in shipped UI components, security defects in executed code, and copyleft obligations. - Breaks when: the application layer fully wraps or replaces the dependency's contribution to that attribute, which is possible for accessibility in some component libraries but expensive and rarely done. **Links**: - [[Supply-chain-security]] — because extends - [[SBOM]] — because applies-in inventory and provenance practice - [[WordPress-accessibility-ready-themes]] — because evidence-for an ecosystem enforcing this one layer up - [[Shift-left]] — because contrasts on where in the lifecycle verification belongs **Optional**: `proof_state: working` ## Tests / falsifiers - If applications with non-conformant dependencies reach conformance at the same remediation cost as those with conformant dependencies, the claim is refuted for accessibility specifically. - If automated wrapping at the application layer proves cheap and reliable, the practical force of the claim disappears even if it remains formally true.  #### [P2] Excluding people from contribution excludes them from the career it confers **Claim** (one sentence, Courtney's voice): When participation in a community is a recognized credential, any barrier to participating is a barrier to the career that credential unlocks, which makes community accessibility an economic obligation rather than a hospitality one. **Evidence pointer**: [[#H2]] — 51% of surveyed companies weigh open source contribution in evaluating developer talent. **Scope & conditions**: - Holds when: participation is genuinely legible to employers as a credential — strongest in software, where contribution history is public and verifiable. - Breaks when: the community's work is invisible or unattributed, in which case exclusion harms the person but not their marketability, and the argument must rest on other grounds. **Links**: - [[Open-source-as-credential]] — because extends - [[Contribution-process-accessibility]] — because applies-in tooling and event design - [[Volunteer-labor-economics]] — because contrasts on who can afford to participate at all - [[Underrepresented-in-tech]] — because evidence-for the general pattern across other excluded groups  ### ✏️ Fleeting Queue - [F1] Retrieve the primary Census II figure and check the unit — lines of code, packages, or transitive dependencies. The 70–90% band shifts meaning depending on which, and the talk asks it as "lines of code." https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries #fleeting #inbox - [F2] Open question: there is 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? Highest-leverage gap the talk implies without naming. #articleseed #fleeting #inbox - [F3] Bring the WordPress accessibility-ready theme review to gh.io/open-source-accessibility as a "bright spot" — it is one of the very few accessibility enforcement mechanisms in any open source ecosystem, and the 30 September re-review deadline makes it live. #share #fleeting #inbox - [F4] Steal the multimodal poll (raise hand + say "I") for the next meetup and organizer handbook. Zero cost, teaches by demonstration. #aphorisms #fleeting #inbox - [F5] No baseline measurement exists for open source accessibility, which makes the five-year pledge unfalsifiable. Watch whether the new org publishes a measurement methodology or only a roadmap. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Navigate one project's full contribution path with a screen reader — CONTRIBUTING, issue template, review UI — and write up what breaks #things - [ ] Add "tested with assistive technology?" as a question in the dependency review checklist alongside license and security #things  📄 **Full text:** [[Full Document Contents/Articles/Open Source Accessibility What You're Getting Wrong.md|Open Source Accessibility: What You're Getting Wrong by Ed Summers]] ## Highlights - that gives people who cannot see I can hear the response and of course people who cannot hear can see the raising your hands. That's why it's a multimodal accessibility hack. ([View Highlight](https://read.readwise.io/read/01kymv8wb5279ymyd9m3w3a34v)) - Note: H5 — Zero-cost and immediately stealable for any meetup or WordCamp. Teaches redundant-channel design by demonstration rather than description. [~2:40] - Tags: atom/literature/h2, atom/fleeting/f1 - supply chain issue. Same is true for security, right? If you're building an application or website, you're using open-source projects, you need to make sure they're secure. Okay, let's make sure they're accessible as well. ([View Highlight](https://read.readwise.io/read/01kymv87fn9d9cne8jfndysa30)) - Note: H1 / P1 — The talk's most portable idea. Converts accessibility from a moral appeal into a dependency-management question teams already have a process for, so it can be adopted at an existing gate rather than needing a new one. [~4:07] - Tags: atom/zettel/z1, atom/literature/h1 - your ability to get a job. And what if you were excluded through through no fault of your own excluded from participating in the open source communities to get that valuable learning experience. Right? That's why ([View Highlight](https://read.readwise.io/read/01kymv96j6t1f774p2b9gv26vt)) - Note: H2 / P2 — Reframes inaccessible issue trackers and community spaces as economic exclusion with a measurable stake (51% of companies weigh OSS contribution in hiring), not a courtesy failure. [~5:18] - Tags: atom/literature/h1, atom/zettel/z1 - one. Right? Accessibility is a property. means that people with disabilities or people with a wide range of abilities including disabilities can enjoy everything that's being offered. Now, assist of technology is different. Assisted technology is very personal to individuals. It's like it's like part of ([View Highlight](https://read.readwise.io/read/01kymv9hece3np069st99ba2xn)) - Note: H3 — Corrects a persistent and expensive confusion. Teams that conflate the two try to "support screen readers" instead of building correct semantics. Accessibility is owed by the builder; assistive technology is chosen by the person. [~6:10] - Tags: atom/literature/h1 - 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. And that's why, [cheering] right? ([View Highlight](https://read.readwise.io/read/01kymv9sxs8atrf8kwhv3wqqzs)) - Note: H4 — NVDA: an existence proof against the doubt that disabled people can build production assistive technology, told while the speaker uses it to read his own slides. The only applause in the talk. Also the clearest funding argument: 250k users, volunteer origins. [~8:00] - Tags: atom/literature/h1