"Single Page Access"
summary
Shows concrete fixes: replace noninteractive spans with real buttons so keyboard users and assistive tech can focus; use ember-template-lint, react-a11y or a Protractor a11y plugin to prevent regressions; call element.focus or use ember-component-focus / react-focus-trap to restore focus to new content after UI swaps; add a route announcer (ember-a11y or React/Angular equivalents) so screen readers hear client-side navigations. Notes impact: accessible users may be 0–20% of traffic, fixes are a few lines or add-ons and dramatically improve real-world access.
AI-written summary · about
chapters (10)
- 0:00Introduction and background
- 3:12Front-end frameworks and accessibility
- 5:01Motor ability and semantic HTML
- 11:43Dynamic content and cursor position
- 16:58Screen reader access and announcements
- 23:37Next steps for accessibility
- 27:52Code is political and inclusive access
- 31:00Convincing stakeholders and legal aspects
- 32:25Testing with screen readers
- 33:49Open source contributions
related talks
17mAccessibility in Single Page Applications
28mMaking Single Page Apps accessible
23mAccessible navigation in single-page applications
52mMaking Single Page Apps Accessible: It's easier than you think
36mAccessibility in Ember: where we are, where we need to go, how to get involved
34mBuilding for Accessibility
30mAmbitious for All: Accessibility in Ember
22mBetter accessibility with a user-centric view