How to Accessibility if You’re Mostly Back-End
summary
Back-end engineers can improve accessibility with concrete practices: use avoid abbreviations and pronounceable names, run linters like RuboCop to enforce ~75–100 character lines, and prefer clear variable naming (e.g., replace CB = message.gsub("\n","") with message.delete("\n")). Stats cited: 16% of people have a disability, 20% dyslexia, 8% men color blind, ~1 in 50 developers have vision issues, 10% have concentration disorders. Also add text code samples, Zoom auto-transcripts or captions, test with Hemingway/LanguageTool, and allow tool/IDE customization.
AI-written summary · about
chapters (20)
- 0:00Intro
- 0:50Why
- 1:13Statistics
- 3:17What is Accessibility
- 5:53Avoid abbreviations and acronyms
- 6:39Readability naming and lenters
- 7:48How to make our code readable
- 8:05Failed and old
- 8:58Let
- 10:01linters
- 11:27line length
- 13:35preference is global
- 14:34Documentation
- 17:17Video Documentation
- 20:18Paraphrase Tool
- 23:33Engineering Policies
- 24:15Vendors
- 24:27K9s
- 24:57Conclusion
- 25:39Outro
related talks
45mHow to Accessibility if You’re Mostly Back-End
30mHow to Accessibility if You’re Mostly Back-End
45mHow to Accessibility if You’re Mostly Back-End
36mThe Human Side of Accessibility
14mAccessible Accessibility
41mTales of Accessibility Failures
26mDon't Develop Just for Yourself - A Developer's Checklist to Accessibility
42mA Glimpse Into Accessibility