A11y on the back end
summary
Argues that accessibility must include back-end code, CI and tooling not just HTML and ARIA, and shows concrete examples: running a screen reader + PHPStorm demo that struggles with modern PHP syntax, comparing bracketed arrays vs array() and why WordPress enforces tabs, snake_case and long names. Points to surprising scale: WordPress supports ancient PHP versions because it powers ~30% of sites and preserves 50+ legacy function interfaces. Offers a checklist: document-first, consistent style, avoid cleverness, and fix build/UI signals like colored CI badges.
AI-written summary · about
chapters (31)
- 0:00Start
- 1:18Accessibility
- 3:32Principles and Designs of Being Inclusive Creating Inclusive Designs
- 4:14Alt Tags
- 5:01Consider the Situation
- 8:50Prioritize Content
- 11:37Who Does Use Your Software
- 22:21Authoring Tool Accessibility Guidelines
- 25:14Wordpress Coding Standards
- 27:48Initializing Arrays
- 31:16Coding Standard
- 36:52Wordpress Accessibility Standards
- 38:28International Developers
- 41:18Wordpress Needs To Support 12 Year Old Websites
- 43:27Wordpress 6
- 47:04Blindness and Low Vision
- 47:48Color Blindness
- 48:08Subtitles on Videos
- 49:52Motor Impairments
- 1:00:04Communication Feedback Strategy
- 1:01:13Stand-Up Meeting
- 1:02:01Feedback Loop
- 1:02:58Merge Conflicts
- 1:04:48Losing Track of Deadlines
- 1:05:31Work-Life Balance
- 1:05:59Object Permanence
- 1:09:28Asynchronous Feedback
- 1:10:24Adhd Superpower
- 1:12:04Making the Software Accessible
- 1:13:19Back-End Accessibility
- 1:14:40Document First
related talks
33mAccessibility on the backend
29mProgramming for Accessibility
30mHow to Accessibility if You’re Mostly Back-End
26mAccessibility Is a Marathon, not a Sprint
29mBuilding Accessibility Testing into Your Workflow
43mWalking Down the A11Y Road - Lessons Learnt From...
56mAccessibility Testing 101
44mTesting Web Accessibility