Accessibility on the backend
summary
Claim: backend code and processes block real users — developers, juniors, non‑English readers, and temporarily disabled folks — from doing work. Evidence: WordPress publishes coding standards (long array syntax, tabs) to improve readability; NVDA and JAWS struggle to speak condensed code; reduce is inaccessible and NVDA and JAWS read code poorly; SSHing on a phone with Vim or being forced to use PHPStorm breaks access. Actionable payoff: prefer explicit, line‑by‑line code, relax tool mandates, and small style rules improve productivity.
AI-written summary · about
chapters (19)
- 0:00What is Accessibility?
- 0:50Who Are the Users?
- 2:30Why Make Allowances for Developers?
- 5:14Identifying Inaccessibility
- 8:57WordPress Accessibility Standards
- 12:19Broad User Base for Accessibility
- 13:38Defining Disability
- 16:46Disabilities Can Be Temporary
- 17:43Accessibility is Empathy
- 21:28Comparing Code Readability
- 23:39Reduce Function Is Not Accessible
- 25:38Screen Readers Struggle with Code
- 26:10Processes Matter Too
- 27:16Identifying Inaccessibility
- 29:36Dictating Tools Restricts Accessibility
- 30:57Meeting Accessibility Standards
- 31:31Explaining the Shirt Graphic
- 32:14Improving Accessibility Costs Little
- 32:51The Answer to Regex
related talks
01h 16mA11y on the back end
30mHow to Accessibility if You’re Mostly Back-End
45mHow to Accessibility if You’re Mostly Back-End
45mHow to Accessibility if You’re Mostly Back-End
26mHow to Accessibility if You’re Mostly Back-End
49mProgramming for Accessibility
15mWe Can't See You...
23mI See: Overcoming Challenges in Software Development