How to Accessibility if You’re Mostly Back-End
summary
Back-end work changes accessibility in concrete ways: 16% of people have a disability, 20% have dyslexia, 8% of men are color blind, and over 10% of programmers report concentration or memory disorders, so naming, API field consistency and avoid abbreviations matter. Use linters like RuboCop and ESLint for predictable style, prefer underscores in API names, keep lines ~75–100 chars, and use linters to enforce rules. Add tests as specs, run UI accessibility checks, keep Confluence current with 15‑minute monthly edits, capture video captions via Zoom (it works pretty well) and prefer k9s or accessible tools over raw kubectl.
AI-written summary · about
chapters (19)
- 0:00Accessibility for back-end engineers
- 1:48Why accessibility matters
- 5:40Code readability and naming
- 9:12Writing readable code
- 11:17Using linters for predictability
- 13:25Indentation and screen readers
- 15:56Value of code comments
- 17:22API design and docs accessibility
- 19:54Accessible tests and specs
- 21:36DRY vs WET in tests
- 23:02Accessible documentation
- 26:34Simplify documentation
- 29:43Testing readability levels
- 31:31Link text tips
- 33:40Avoid cultural assumptions
- 36:06Small inclusive practices
- 37:53Engineering policies
- 40:23Front-end considerations
- 41:47Key takeaways
related talks
30mHow to Accessibility if You’re Mostly Back-End
26mHow to Accessibility if You’re Mostly Back-End
36mThe Human Side of Accessibility
14mAccessible Accessibility
29mHow to bring accessibility into your teams
26mDon't Develop Just for Yourself - A Developer's Checklist to Accessibility
45mTips from the Trenches: Accessibility Testing
41mTales of Accessibility Failures