Accessible Roots Grow A Healthy Framework.
summary
A concrete case study of baking accessibility into a design system: a product team arrives with 111 defects blocking release, a migration to the framework closes 56% of them automatically, and a proposed toast component is pulled—toast pulled from alpha—when timing, content and persistent-message behavior proves inaccessible. The workflow enforces feature intake, cross‑functional review, design and code sprints, dedicated accessibility QA, and a new mandatory gate between alpha and testing so accessibility work does not become a bottleneck.
AI-written summary · about
chapters (7)
- 0:00Start
- 4:45What is a Design System?
- 11:36robust accessibility documentation on components & patterns
- 22:48Discuss any ally changes to the Design Team -Share any changes with the Ally QA team -Educate UX department on updates & answer any questions
- 27:22To have an accessible Design System you need Accessibility Designers involved in every step of the process
- 28:16Design Systems are a product & you can't slack on the service side of your product if you hope to scale
- 28:57Documentation is your biggest ally when making any changes to a system. The "why" is as important as the "what"
related talks
49mScaling Accessibility An Accessibility Design Manager’s Tale
53mAccessing Accessible Accessibility
47mFrom Parts to Whole – Beyond Design System
21mBuilding an Accessibility Culture
22mAccessibility: The Sprint Filler Way
32mBuilding Empathy and Accessible Apps
45mTips from the Trenches: Accessibility Testing
59mImproving Accessibility Through Design Systems