Testing Web Accessibility
summary
Covers concrete testing workflow: claim that automated tools find only about 20–30% of issues and must sit inside a larger process, demos of axe, pa11y, and Lighthouse across editor, browser, CLI and CI, plus browser extensions and screen‑reader simulation. Shows unit tests invoking axe, GitHub Actions that block merges, and practical items like contrast ratios, tab order mapping, and screenshots for reporting so viewers know exactly what gets built and what actually finds problems.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:46Accessibility (a11y)
- 2:07Web Accessibility (ally)
- 3:09Types of impairment
- 8:02Use the development tools of the browser
- 13:39Lighthouse
- 14:56GitHub Actions
- 18:39Screen Readers Screen readers are software programs that allow blind or visually impaired users to read the text that is played on the computer screen with a speech
- 19:31axe chrome extension
- 20:13ARC Toolkit
- 20:47Accessibility Insights
- 22:24WAVE (web accessibility evaluation tool)
- 23:02Chrome Development Tools
- 23:41Firefox Development Tools
- 24:56Introduction to Web Accessibility
related talks
44mTesting Web Accessibility
33mAutomated Accessibility Testing
56mAccessibility Testing 101
35mAutomated Accessibility Testing
31mDecoding web accessibility through testing
29mBuilding Accessibility Testing into Your Workflow
45mTips from the Trenches: Accessibility Testing
43mLucky Nkosi: A11y Beyond the Theory: Integrating Accessibility Testing into Your Workflow