a11y testing: tech talk

Tech talk at OEV Innovation Hub Berlin

Transcript

1. a11y testing Niklas Kiefer
2. What’s in • Why a11y testing matters • Different strategies for your development routines ◦ manual vs. automatic testing ◦ unit vs. integration testing • Code examples
3. Accessibility (a11y) “Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.” https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility
4. a11y testing - Why it matters • regularly test your components against a set of defined rules and best practices • automatic testing: catch bugs earlier ◦ “find on average 57% of WCAG issues automatically”, cf. https://github.com/dequelabs/axe-core • get a better understanding of how our products works for a wider range of users
5. Disclaimer a11y testing doesn’t make your web content fully accessible!
8. Manual testing
9. Manual testing • Tab like crazy • Use dev tools • Use screen readers or voice recognition tools • Conduct a11y audits
10. Tab like crazy
11. Tab like crazy
12. Tab like crazy: automatic? https://github.com/bpmn-io/bpmn-js-properties-panel/pull/703
13. Dev tools • Chrome a11y tree • axe DevTools • Google Lighthouse • IBM accessibility checker (Carbon)
14. Chrome a11y tree
15. axe DevTools
16. Google Lighthouse
17. IBM accessibility checker
18. Use screen readers • NVDA • JAWS • VoiceOver
19. Conduct a11y audits • Use the techniques mentioned before • Collect critical a11y issues • Act on them • The A11Y Project Checklist
20. Automated testing
21. Automated testing • Unit tests - test your components • Integration tests - test e2e scenarios • Find examples for both cases in the Frontend Template
22. Unit tests • axe default rules • configurable based on your needs
23. Unit tests • React testing library
24. Integration tests • Axe Playwright
25. Integration tests
26. Critical a11y issues - Examples
27. Clear focus path
28. Alternative texts and titles
29. Labels for inputs
30. Use semantic HTML where possible
31. Use semantic HTML where possible The first rule of ARIA: If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
32. Use semantic HTML where possible ⛔ ✅
33. Use semantic HTML where possible ⛔ no translation support ✅ Source: https://conf.react.dev/talks/19
34. Focus states for buttons and inputs
35. Error states
36. Error states Source: https://conf.react.dev/talks/19
37. Recommend: Semantic headings
38. Recommend: Skip to main content
39. Color contrasts
40. Notifications and alerts Source: https://conf.react.dev/talks/19
41. Notifications and alerts Source: https://conf.react.dev/talks/19
42. • Web Content Accessibility Guidelines • axe dev tools • React Conf Talk - Demystifying accessibility in React apps ◦ More resources • Google A11ycasts Helpful resources
43. What’s more • Training - Accessible Code • Find some notes in this Miro board
44. Thank you! Any questions?