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
   

   View Slide

2. View Slide

3. Most important thing
   Be careful how we
   put the pieces together
   

   View Slide

4. Steve Barnett
   Currently: Technical Digital
   Accessibility Analyst at Xero
   Previously: FEDUX at Totara
   naga.co.za
   

   View Slide

5. ⚠
   Caution
   Flawed and overused
   analogy is approaching
   

   View Slide

6. A design system
   is a bit like
   a box of Lego
   

   View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

11. Lego:
    Make the thing with
    bricks and instructions;
    Check the thing against the picture;
    Improve the product with feedback.
    

    View Slide

12. Design system:
    Make the thing with components and
    documentation;
    Check the thing against examples;
    Improve the system with feedback.
    

    View Slide

13. Agenda
    1. a11y going forwards (make)
    2. a11y going backwards (check)
    3. a11y going onwards (improve)
    

    View Slide

14. Make with Lego:
    use the right bricks
    in the right place
    

    View Slide

15. Make with a design system:
    use the right components
    Use semantic elements:
    buttons for actions, links for
    navigation, form elements for data
    

    View Slide

16. Make with a design system:
    use components in the right place
    Put groups in helpful containers
    Be careful with nesting
    

    View Slide

17. Make with Lego:
    follow the instructions
    

    View Slide

18. Make with a design system:
    follow the documentation
    Help on good button and link text
    Prefer labels over aria-labels
    

    View Slide

19. Agenda
    1. a11y going forwards (make) ✔
    2. a11y going backwards (check)
    3. a11y going onwards (improve)
    

    View Slide

20. Check with Lego:
    compare to the picture
    

    View Slide

21. Check with a design system:
    compare to the examples
    Check our accessible names, roles
    Run an automated test
    (good for errors and omissions)
    

    View Slide

22. View Slide

23. View Slide

24. Check with Lego:
    find where the problem is
    The bricks?
    The instructions?
    We decided not to make a duck?
    

    View Slide

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?
    

    View Slide

26. Agenda
    1. a11y going forwards (make) ✔
    2. a11y going backwards (check) ✔
    3. a11y going onwards (improve)
    

    View Slide

27. Improve with Lego:
    contact Customer Service
    Broken or missing bricks
    Unclear instructions
    

    View Slide

28. Improve with a design system:
    give feedback on the components
    Report any bugs we find
    Offer suggestions for fixes
    

    View Slide

29. Improve with a design system:
    give feedback on using the
    components
    Say what was easy and what was hard
    Offer suggestions for improvements
    

    View Slide

30. Improve with a design system:
    give feedback on the documentation
    Let them know what was most
    helpful, what could be expanded on
    

    View Slide

31. Recap
    1. a11y going forwards (make) ✔
    2. a11y going backwards (check) ✔
    3. a11y going onwards (improve) ✔
    

    View Slide

32. Most important thing
    Be careful how we
    put the pieces together
    

    View Slide

33. Thank you!
    !
    

    View Slide

34. Appendix 1
    What makes a good accessible name?
    

    View Slide

35. Buttons do things
    A good accessible name tells us
    what happens when we use the
    button
    

    View Slide

36. Links go places
    A good accessible name tells us
    where we go when we follow the link
    

    View Slide

37. Inputs accept data
    A good accessible name tells us
    what data to enter
    

    View Slide

38. Grouping combines form elements
    A good accessible name tells us
    the context for the choice
    

    View Slide

39. Appendix 2
    What makes an accessible design
    system?
    

    View Slide

40. Automated tests
    Unit tests and end-to-end tests
    relating to accessibility
    

    View Slide

41. Manual tests
    Keyboard support, Assistive
    Technology (like screen readers) that
    the team have tested with
    

    View Slide

42. Standards
    The documentation talks about WCAG,
    what version and level the design
    system meets
    

    View Slide

43. Inclusive
    People with Disabilities were
    involved in research, design,
    development, and testing
    

    View Slide

44. Process
    A backlog of prioritised a11y issues
    Ideally a roadmap for fixing them
    

    View Slide