$30 off During Our Annual Pro Sale. View Details »

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

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.

Tim von Oldenburg

March 04, 2019

More Decks by Tim von Oldenburg

Other Decks in Technology


  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

  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

  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/