No more excuses - Getting the first 30% of accessibility issues

Only 30% of accessibility issues on a website can be caught by automated testing, according to the GDS accessibility team. But those 30% are a great baseline to operate from, and we should strive to make it as easy as possible for everyone to get there.

While every situation is different and every project faces unique challenges, the basics are often the same: we start small and try to scale our testing approach. We need to integrate new accessibility testing tools into our existing processes and pipelines. And we need the test results to be actionable and easy to understand.

In this talk, I tell the story of how we’re trying to get to the first 30% at ResearchGate: how we approached those issues, the obstacles we’re facing, and what new exciting possibilities await us all in the future.

Transcript

1. No more excuses Getting the first 30% of accessibility issues
2. Hello good* people (wave emoji) I am Tim von Oldenburg UX Engineer at ResearchGate, the professional network for scientists. Email me at tim@tvooo.de Get in touch: https://twitter.com/sweeneytimm * if you’re interested in making products accessible, you’re probably not a bad person
3. I work in the team that creates Nova, our internal design system
4. In 2017, the GDS ran 13 accessibility testing tools on the world’s least accessible website
5. 30% Only 30% of accessibility issues are found by automated tools.
6. Does this mean automated testing is useless?
7. Of course not! Automated testing is still very valuable. These 30% may not sound like much, but they are a solid baseline that you can operate from. It’s also a baseline that everyone can achieve, no matter how big and diverse their organization is, or if they have dedicated resources for user research.
8. The value of automated testing “The web can only become an accessible, inclusive space if developers are empowered to take responsibility for accessibility testing and accessible coding practices. Automated accessibility testing is a huge timesaver, it doesn't require special expertise, and it allows teams to focus expert resources on the accessibility issues that really need them.” https://github.com/dequelabs/axe-core
9. Everyone can fix at least 30% of problems. Let’s get started!
10. Educate... yourself, your team, and your org
11. How to educate yourself Local community: Attend A11y Meetup Berlin :-) Online resources: Video courses, blogs, books Existing solutions: Copy other people’s work Ask: Get help from Stanley* * anybody who knows more than you do
12. How to spread knowledge to your team Give a code review and suggest accessibility improvements while changes are being made anyway. This feels less like additional work than a separate task would. Give a workshop to raise the general accessibility knowledge in the team, or to work on a specific problem together.
13. Are other teams or people in your organisation struggling with accessibility? Offer to help them. Do you have an internal company blog? Do you have a company chat? Write about what you’re doing to make your product more accessible. Share relevant articles and news. How to create awareness in your organisation
14. Use tools you already know well
15. Which tools are you already using? Use Selenium for end-to-end tests? Use it to test keyboard accessibility. Collect Lighthouse performance metrics? There is an accessibility audit built into Lighthouse as well. Design using Sketch? There is a plugin to check for color contrast. Use a test runner? Don’t add another one to your toolkit.
16. Testing setup at ResearchGate Jest Test runner Jenkins Continuous integration jest-axe Accessibility testing engine
17. Test in as real circumstances as possible.
18. From fake DOM to real browser Selenium gives you a real browser. However, it’s slow, required additional infrastructure if you use a CI, and might run slightly unstable. Instead, you can run your tests in a headless browser, such as puppeteer, directly from your command line or Continuous Integration server. (Firefox also has a headless mode)
19. Testing a button component...
20. ...and axe gives us a list of problems
21. Make the results actionable
22. axe gives us a list of problems
23. How to make the connection from test results to the actual source? We insert a highlight around the problematic element. The terminal output tells us what the problem is. The highlight in the screenshot tells us where the problem is. Visualise test results
24. Take it one issue at a time
25. Don’t be discouraged by too many problems. Either approach it section by section (inputs, navigation, …) or problem by problem (color contrast, labels, …). Take it one issue at a time
26. Go beyond the 30%
27. Go beyond the 30% Automated testing is really useful. Automate what you can. Just don’t use “we are using automatic testing” as an excuse. Aim to design and test with real people. There is no replacement for the human factor when creating a product. Addressing the first 30% of accessibility issues means “getting the obvious issues out of the way”. Now you can focus on the real ones.
28. Recap - Educate yourself, your team, and your org - Use tools you already know well - Test in as real circumstances as possible - Make the results actionable - Take it one issue at a time - Go beyond the 30%
29. No more excuses Thank you!
30. References GDS Accessibility Testing tools study: https://accessibility.blog.gov.uk/2017/02/24/what-we -found-when-we-tested-tools-on-the-worlds-least-acce ssible-webpage/ axe: https://github.com/dequelabs/axe-core https://github.com/nickcolley/jest-axe Puppeteer: https://pptr.dev/ https://github.com/smooth-code/jest-puppeteer Web Content Accessibility Guidelines (WCAG): https://www.w3.org/TR/WCAG21/
31. References (2) Inclusive Design Principles: https://inclusivedesignprinciples.org/ WAI-ARIA Authoring Practices: https://www.w3.org/TR/wai-aria-practices-1.1/ Inclusive Components: https://inclusive-components.design/