Commit to Change: How to Increase Accessibility in Your Favorite Open Source Projects
summary
Argues that accessibility must start upstream by removing barriers for disabled contributors and recommends concrete actions: add accessibility docs (status, known issues, compatibility with screen readers), add an accessibility issue template/label on GitHub, and improve technical docs—alt text that conveys an image’s function, informative link text, logical headings, concise language. Suggests visualization packages change default color palettes for colorblind users, warns against overlay tools like accessiBe, and links materials and example PRs (Jupyter alt-text).
AI-written summary · about
chapters (6)
- 0:00NASA tampon miscalculation
- 1:50Accessibility starts with devs
- 3:53Improving open source accessibility
- 8:46Documentation barriers
- 13:42Commit to change
- 16:11Q&A
related talks
30mDocs For All: Improving Open Source Accessibility
46mEmbracing Accessibility in Open source
43mA11y Need Is Love (But Accessible Docs Help Too)
45mHow to Accessibility if You’re Mostly Back-End
30mHow to Accessibility if You’re Mostly Back-End
21mBuilding an Accessibility Culture
24mWeb Accessibility Strategies for Non-Accessible Projects
19mAccessibility isn't hard; getting people to see it's easy can be with Sarrah Vesselov