How to get the most (accessibility) out of a design system

A good design system helps nudge us towards more accessible choices. How firm that nudge is depends on the component(s), the flexibility of the system, and more.

We’ll ask:

- how do make sure we build an accessible thing? (a11y going forwards)
- how do we check we’ve built an accessible thing? (a11y going backwards)
- how do we help improve the design system? (a11y going more backwards but/and forwards. Uh.. onwards?)

Transcript

1. How to get the most (accessibility) out of a design system
3. Most important thing Be careful how we put the pieces together
4. Steve Barnett Currently: Technical Digital Accessibility Analyst at Xero Previously: FEDUX at Totara naga.co.za
5. ⚠ Caution Flawed and overused analogy is approaching
6. A design system is a bit like a box of Lego
11. Lego: Make the thing with bricks and instructions; Check the thing against the picture; Improve the product with feedback.
12. Design system: Make the thing with components and documentation; Check the thing against examples; Improve the system with feedback.
13. Agenda 1. a11y going forwards (make) 2. a11y going backwards (check) 3. a11y going onwards (improve)
14. Make with Lego: use the right bricks in the right place
15. Make with a design system: use the right components Use semantic elements: buttons for actions, links for navigation, form elements for data
16. Make with a design system: use components in the right place Put groups in helpful containers Be careful with nesting
17. Make with Lego: follow the instructions
18. Make with a design system: follow the documentation Help on good button and link text Prefer labels over aria-labels
19. Agenda 1. a11y going forwards (make) ✔ 2. a11y going backwards (check) 3. a11y going onwards (improve)
20. Check with Lego: compare to the picture
21. Check with a design system: compare to the examples Check our accessible names, roles Run an automated test (good for errors and omissions)
24. Check with Lego: find where the problem is The bricks? The instructions? We decided not to make a duck?
25. Check with a design system: find where the problem is A bug in the design system? Our usage of the design system? Our implementation?
26. Agenda 1. a11y going forwards (make) ✔ 2. a11y going backwards (check) ✔ 3. a11y going onwards (improve)
27. Improve with Lego: contact Customer Service Broken or missing bricks Unclear instructions
28. Improve with a design system: give feedback on the components Report any bugs we find Offer suggestions for fixes
29. Improve with a design system: give feedback on using the components Say what was easy and what was hard Offer suggestions for improvements
30. Improve with a design system: give feedback on the documentation Let them know what was most helpful, what could be expanded on
31. Recap 1. a11y going forwards (make) ✔ 2. a11y going backwards (check) ✔ 3. a11y going onwards (improve) ✔
32. Most important thing Be careful how we put the pieces together
33. Thank you! !
34. Appendix 1 What makes a good accessible name?
35. Buttons do things A good accessible name tells us what happens when we use the button
36. Links go places A good accessible name tells us where we go when we follow the link
37. Inputs accept data A good accessible name tells us what data to enter
38. Grouping combines form elements A good accessible name tells us the context for the choice
39. Appendix 2 What makes an accessible design system?
40. Automated tests Unit tests and end-to-end tests relating to accessibility
41. Manual tests Keyboard support, Assistive Technology (like screen readers) that the team have tested with
42. Standards The documentation talks about WCAG, what version and level the design system meets
43. Inclusive People with Disabilities were involved in research, design, development, and testing
44. Process A backlog of prioritised a11y issues Ideally a roadmap for fixing them