Introduction to accessibility

An interactive talk about accessibility, the social model of disability, standards (WCAG 2.1, Level AA), and checking and testing.

Transcript

1. Introduction to Accessibility (a11y for short)
2. Most important thing Small accessibility improvements help more people than we might think
3. Steve Barnett Currently: Technical Digital Accessibility Analyst at Xero Previously: FEDUX at Totara naga.co.za
4. Agenda 1. Accessibility and Disability 2. Standards and Compliance 3. Checks and Tests
5. “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” — Tim Berners-Lee
6. Agenda 1. Accessibility and Disability 2. Standards and Compliance 3. Checks and Tests
7. (Gentle!) activity A human uses the Web
8. A human using a mouse and Safari on a Mac uses the Web
9. A human using a mouse / trackpad / keyboard / switch control / puffer / magnification tool / voice control / screen reader and Safari / Chrome / Firefox / Edge on a Windows / Mac / Linux desktop / laptop / tablet / phone in light / dark mode / high contrast mode with reduced motion enabled with smaller / larger text size uses the Web
10. Delicious takeaway: Humans interact with our product in a very wide range of ways Any questions?
11. Many types of disability, for example: Auditory Cognitive Physical Visual
12. Social model of disability Disability = Ability + Barrier Mismatched interactions
13. (Gentle) activity time! Let's think about the visual category under the social model of disability
14. Do a reactji at me ✋ if you or someone you know is: blind
15. Potential barrier ! no text alternatives for non-text content
16. Do a reactji at me ✋ if you or someone you know has: low vision or poor eyesight (perhaps from old age)
17. Potential barrier ! no (or poor) responsive styles
18. Do a reactji at me ✋ if you or someone you know is: colour blind
19. Potential barrier ! using only colour to convey information
20. Do a reactji at me ✋ if you or someone you know has: been outside on a sunny day with a shiny screen
21. Potential barrier ! low colour contrast between text and the background
22. Delicious takeaway: Mismatched interactions can create barriers to access for many people Any questions?
23. Agenda 1. Accessibility and Disability ✔ 2. Standards and Compliance 3. Checks and Tests
24. Standards and Compliance How do we know what good looks like?
25. Web Content Accessibility Guidelines Perceivable, Operable, Understandable, Robust How to Meet WCAG (Quick Reference)
26. Most governments, big companies: "WCAG 2.1 Level AA compliance" This sets the minimum We set the maximum
27. Questions about accessibility standards?
28. Agenda 1. Accessibility and Disability ✔ 2. Standards and Compliance ✔ 3. Checks and Tests
29. Checks and Tests How do make accessible things? What are the first few steps?
30. QAC (Quick A11y Checks) 1. Headings (levels, nesting) 2. Keyboard (functionality, visibility) 3. axe DevTools (errors, omissions)
31. Tiny demo of QAC !
32. Questions about QAC? (Three flavours of QAC are in the appendix: Content creator, Designer, and Developer)
33. More than a QAC TPGi's ARC Toolkit Microsoft Accessibility Insights Test using a screen reader (Links included later, plus more details in the appendix)
34. Tiny demo of Voice Over (Screen Reader)
35. "It doesn't have to be perfect, just a little bit better than yesterday" — Léonie Watson
36. Recap 1. Accessibility and Disability ✔ 2. Standards and Compliance ✔ 3. Checks and Tests ✔
37. Most important thing Small accessibility improvements help more people than we might think
38. Thanks for your attention! More questions? !
39. Links WCAG Quick Reference ARC toolkit, Microsoft Accessibility Insights Testing with screen readers QAC for Developers QAC for Designers
40. Appendix 1 Quick A11y Checks
41. QAC for Content creators 1. Headings (levels, nesting) 2. Text alternatives (images, videos) 3. High quality text (links, buttons)
42. QAC for Designers 1. Headings (levels, nesting) 2. Accessible names (forms, links) 3. Unique text (links, buttons)
43. QAC for Developers 1. Headings (levels, nesting) 2. Keyboard (functionality, visibility) 3. axe DevTools (HTML errors)
44. Appendix 2 Slower A11y Checks
45. TPGi's ARC Toolkit This is a good tool to run to flag more errors. It provides an easy way of inspecting the accessibility of semantic structures such as headings, landmarks, links, buttons, form controls, and alt text.
46. Microsoft Accessibility Insights (Do the assessment option) This is a good tool to use next because it offers good coverage of the WCAG SC (Success Criteria). It’s a reasonably lengthy process, but gets faster with practice.
47. Test using a screen reader Check structure. Check interactions. Check alt text of images: does it convey the content and function of the image? Check form error handling. (Warning! This could get a bit hairy. ! )
50. Super secret appendix 3! Automated testing
51. The thing to search for is axe. Industry-leading testing engine, made by Deque, used inside lots of other tools.
52. Deque has many axe-related repos. Check for an axe package for your favourite unit or E2E framework. However! Please read the next few slides too !
53. Automated testing can pick up some of the common, obvious, issues. But it misses some stuff too. Let's look at some accessibility examples.
54. Does an automated test catch it? ✔ Missing alternative text for images ✖ Bad alternative for images
55. <!-- Missing alt text --> <!-- ✔ caught by automated test --> <img src="pup-pic-24.jpg"> <!-- Bad alt text: not actually a text alternative --> <!-- ✖ not caught by automated test --> <img src="pup-pic-24.jpg" alt="dog"> <!-- Great alt text: conveys the same information as the image --> <!-- passes automated test --> <img src="pup-pic-24.jpg" alt="Cute puppy frolicking in a field">
56. Does an automated test catch it? ✔ Empty links or empty buttons ✖ Bad link text or bad button text
57. <!-- Empty link text --> <!-- ✔ caught by automated test --> <a href="/edit/1/"> <img src="pencil.svg"> </a> <!-- Bad link text --> <!-- ✖ not caught by automated test --> <a href="/edit/1/">here</a>
58. Does an automated test catch it? ✔ Some HTML errors ✖ Weird HTML
59. <!-- Button for an open accordion --> <button aria-expanded="true">Address</button> <!-- Current page in the nav --> <a href="/settings" aria-current="page">Settings</a> <!-- An ARIA live region --> <!-- This has an implied aria-live="assertive" --> <div id="toasts" role="alert"></div> <!-- These usually need JS for the interaction -->
60. <!-- Yes please! --> <button>Edit</button> <!-- Uh, yes, technically --> <button aria-label="Edit"></button> <!-- I suppose so --> <button aria-label="Edit"> <img src="pencil.svg"> </button>
61. <!-- No thank you! --> <div>Edit</div> <!-- Better, but not there yet --> <div role="button">Edit</div> <!-- Better again, but just use a <button> instead! --> <div role="button" tabindex="0">Edit</div>