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
   

   View Slide

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
   

   View Slide

3. I work in the team that creates Nova, our internal design system
   

   View Slide

4. In 2017, the GDS ran 13 accessibility testing tools on the world’s least accessible website
   

   View Slide

5. 30%
   Only 30% of accessibility issues are found by automated tools.
   

   View Slide

6. Does this mean automated testing is
   useless?
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

9. Everyone can fix at least 30% of
   problems. Let’s get started!
   

   View Slide

10. Educate...
    yourself,
    your team, and
    your org
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

14. Use tools you already
    know well
    

    View Slide

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.
    

    View Slide

16. Testing setup at ResearchGate
    Jest
    Test runner
    Jenkins
    Continuous integration
    jest-axe
    Accessibility testing
    engine
    

    View Slide

17. Test in as real
    circumstances as possible.
    

    View Slide

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)
    

    View Slide

19. Testing a button component...
    

    View Slide

20. ...and axe gives us a list of problems
    

    View Slide

21. Make the results
    actionable
    

    View Slide

22. axe gives us a list of problems
    

    View Slide

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
    

    View Slide

24. Take it one issue at a time
    

    View Slide

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
    

    View Slide

26. Go beyond the 30%
    

    View Slide

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.
    

    View Slide

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%
    

    View Slide

29. No more excuses
    Thank you!
    

    View Slide

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/
    

    View Slide

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/
    

    View Slide