Accessibility and Open Source  ## Metadata - Author: [[Sheri Byrne-Haber, CPACC]] - Full Title: Accessibility and Open Source - Category: #articles - Document Note: --- tags: - #accessibility - #opensource - #wordpress Author: Sheri Byrne-Haber, CPACC Source: Medium article Reference: https://sheribyrnehaber.medium.com/accessibility-and-open-source-238e2b4986bf date created: 2025-08-23 00:00 --- # Title: Accessibility and Open Source ## 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-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Byrne-Haber, S. (2019). Accessibility and Open Source. Medium. https://sheribyrnehaber.medium.com/accessibility-and-open-source-238e2b4986bf - Bootstrap Accessibility (historical context): PayPal’s accessible Bootstrap v3 extensions ## 📝 Summary: The article argues that open source projects can significantly improve adoption and “spread the accessibility love” by ensuring base code is accessible to people with disabilities. It highlights that as more organizations consume and produce open source, accessibility is often overlooked, exacerbating two common open source pitfalls: underestimating total cost and skimping on usability. Using PayPal’s decision to make Bootstrap v3 accessible—and contributing those improvements back—as a case study, the author shows how aligning accessibility with open source values benefits both producers and consumers. Quoted highlights: - “Open Source projects can improve adoption and spread the ‘accessibility love’ if they make their base code work for people with disabilities.” - “Of the five most commonly cited issues associated with open source, two of them are directly related to accessibility: Underestimating cost… Skimping on usability.” ## 📖 Main Content: The central thesis is pragmatic: accessibility in open source is not only ethical; it’s economical and strategic. When organizations have legal or policy obligations for accessibility and adopt OSS that isn’t accessible, they face hidden costs—adapting, maintaining, and potentially diverging from upstream. The PayPal + Bootstrap example illustrates a virtuous cycle: solve accessibility for internal compliance, upstream the changes, and improve the ecosystem while reducing future maintenance burden. Key ideas: - Accessibility gaps inflate total cost of ownership for OSS adopters with compliance obligations. - Usability is inseparable from accessibility; skipping it hurts adoption and user satisfaction. - Contributing accessibility enhancements upstream aligns with open source principles and reduces long-term technical debt. - Visibility and recognition (e.g., branding on contributions) can motivate organizations without undermining community spirit. Personal insight: - Treat accessibility as a first-class acceptance criterion in OSS roadmaps and definition of done. This prevents downstream forks and aligns incentives between maintainers and adopters. - Establish governance (labels, checklists, CI tests) that normalize accessibility contributions so they aren’t “special” or delayed. ### 🗒️ Notes - Context and Problem - Growing enterprise OSS usage; accessibility often ignored. - Two pervasive issues tied to accessibility: - Underestimating cost - Hidden costs: retrofitting, audits, rework, training, maintenance of patches. - Opportunity costs: delayed releases, customer churn, legal risk. - Skimping on usability - Accessibility is usability for disabled users; neglect reduces adoption and satisfaction. - Case Study: PayPal and Bootstrap v3 - Need: Bootstrap not accessible enough for obligations. - Action: Implement accessibility improvements; share them back. - Outcomes: - Community benefit; ecosystem uplift. - Brand goodwill and “free advertising” acknowledged but still aligned with OSS ethos. - Reduced long-term maintenance by avoiding a deep fork. - Strategic Takeaways - Upstream early and often to minimize drift. - Bake a11y into contributor guidelines, code review, and CI. - Recognize contributors; visibility can drive corporate support. - Accessibility is a product growth lever (broader user base, better UX). - Practical Recommendations - Add accessibility issue labels and good first issues. - Provide testing matrices: keyboard-only, screen readers, color contrast. - Include a11y linting and automated checks in CI. - Document patterns (ARIA, focus management, semantics) and anti-patterns. - Maintain an a11y roadmap and changelog to signal commitment. ## 📖 References: - Primary: Sheri Byrne-Haber’s article (link above) - Supplemental concepts: WCAG 2.x/3, ARIA Authoring Practices, Bootstrap accessibility efforts historically ## 🗣️ Paraphrase: 1) Original idea: Organizations with accessibility obligations adopting inaccessible OSS must adapt it, as PayPal did with Bootstrap, then shared changes back for community benefit. Paraphrase: When a company that must meet accessibility standards chooses an open source tool that falls short, it’s often forced to retrofit it. That was PayPal’s situation with Bootstrap v3. They implemented accessibility enhancements and contributed them upstream, helping both their users and the broader community. 2) Original idea: Two common OSS issues—underestimating cost and skimping on usability—are directly tied to accessibility neglect. Paraphrase: Among the most cited challenges in open source, two have clear accessibility roots: teams misjudge the actual total cost when accessibility is missing, and they shortchange usability, which undermines the experience for disabled users and, ultimately, everyone. ## 📰 Newsletter: Learning web dev this week? Accessibility is your multiplier. As more orgs adopt open source, too many still forget a11y—until the invoices and legal obligations arrive. Case in point: PayPal once needed Bootstrap to work for all users, so they built accessible components for v3 and contributed them back. That’s the OSS spirit: fix it once, uplift the ecosystem, and avoid forking nightmares. Highlights: - Community: Spotlight on projects adding a11y CI checks and “good first issue: accessibility” labels. - New dev tips: Test keyboard-only flows, screen reader semantics, and color contrast early. - Plugins: Watch for WordPress components that ship with accessible patterns (focus states, ARIA, skip links). Further reading: “Accessibility and Open Source” by Sheri Byrne-Haber. For WordPress-specific guidance, review the WordPress Accessibility Handbook and WCAG 2.2. Build access in—don’t bolt it on. ## ✅ Action Items: Tailored prompt for your role (Developer Advocate, OSS/WordPress; aspiring OSPO director): - Map article insights to your advocacy: - Emphasize accessibility as TCO reduction and adoption driver in OSS pitches. - Curate WordPress contributor pathways featuring a11y-first issues and mentorship. - Advocate for upstreaming accessibility improvements from enterprise users back to Core/plugins. - Contributor engagement: - Launch a contributor cohort focused on a11y pair-testing (keyboard, SR) and docs. - Add “a11y acceptance criteria” to PR templates and demo checklists for WP components. - Education: - Design workshops on PHP/JS/HTML/CSS patterns for a11y (landmarks, ARIA, focus traps). - Create Git/GitHub labs on filing and triaging a11y issues; set up CI with axe-core/Pa11y. - Sustainable funding: - Propose sponsorship tiers earmarked for a11y audits, testing devices, and SR licenses. - Track ROI: reduced support tickets, improved conversions, compliance risk mitigation. - OSPO trajectory: - Draft an a11y governance policy: coding standards, review gates, release notes, metrics. - Publis - Summary: Open source projects have the potential to improve accessibility if they prioritize making their base code accessible to people with disabilities. However, many companies that consume or produce open source software do not consider accessibility, which can be a problem for both producers and consumers. Two of the most common issues associated with open source, underestimating the cost and skimping on usability, are directly related to accessibility. For organizations that have accessibility obligations and need a specific piece of open source software that is not accessible, their only choice may be to adapt the open source version themselves. PayPal is an example of a company that made their own accessibility modifications to Bootstrap and shared them with the open source community, benefiting many organizations and users. Skimping on usability is also a common problem in open source due to limited resources, such as contributors being students or having day jobs. - URL: https://sheribyrnehaber.medium.com/accessibility-and-open-source-238e2b4986bf #### Open Source projects can improve adoption and spread the “accessibility love” if they make their base code work for people with disabilities. Contributors can help.  More and more companies are either consuming or producing open source software. However, very few of them are thinking about accessibility. That creates a problem for both the producers (people making open source) and consumers (people using open source) Of the five most commonly cited issues associated with open source, two of them are directly related to accessibility: * Underestimating cost of open source software * Skimping on usability #### Open Source Problem #1: Underestimating the cost If your organization: * wants a particular piece of open source software * and the software isn’t accessible * and your organization has accessibility obligations THEN your organization’s only choice may be adapting the open source version to be accessible. That is the position that PayPal found themselves in with Bootstrap about five years ago. Paypal decided to make Bootstrap v3 accessible, then distributed their [Bootstrap accessibility modifications](https://paypal.github.io/bootstrap-accessibility-plugin/) back to the Bootstrap community to improve the experience for everyone. OK, so they did make it obvious that the Bootstrap accessibility additions were created by Paypal, rather than forking straight from the main Bootstrap project in Github. So, maybe there was a little bit of free advertising that motivated this decision. Regardless of the reasoning, it was in the spirit of open source for Paypal to make their accessibility changes available for the good of everyone. A lot of organizations that I have worked with (and those organization’s customers) have benefited from those extensions. #### Open Source Problem #2 — Skimping on usability Open Source folks are frequently creating stuff on a shoestring budget. * Many open source contributors are students or have day jobs, increasing the chance that they don’t themselves…, Accessibility and Open Source, Sheri Byrne-Haber, CPACC, 01hfq0hszj5v8ez121pt0cvd7t.