Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Getting started with manual accessibility testing

Getting started with manual accessibility testing

Manual accessibility testing can be daunting. Using assistive technologies like screen reader software can be a noisy, overwhelming, time-consuming experience; especially if accessibility is new to your product's culture. Martin takes us through the steps to introduce accessibility testing, the assistive technologies we should use, and even how to work with team members to catch as many accessibility defects as possible before the works reaches quality assurance testing.

tempertemper

January 23, 2024
Tweet

More Decks by tempertemper

Other Decks in Programming

Transcript

  1. 23rd January 2024
    Getting started with manual
    accessibility testing
    Martin Underhill

    View full-size slide

  2. Martin Underhill
    Lead Accessibility Specialist

    View full-size slide

  3. What we’ll cover
    1. Accessibility conformance
    2. Automated accessibility testing
    3. Manual accessibility testing
    4. Process (ideal, and pragmatic)

    View full-size slide

  4. Accessibility conformance

    View full-size slide

  5. — W3C
    “WCAG … de
    fi
    nes how to make Web content more
    accessible to people with … a wide range of disabilities,
    including visual, auditory, physical, speech, cognitive,
    language, learning, and neurological disabilities”
    Background on WCAG 2
    The Web Content Accessibility Guidelines (WCAG)

    View full-size slide

  6. Versions
    • 2.0
    • 2.1 ← Most common
    • 2.2 ← Current recommendation (brand new!)
    The Web Content Accessibility Guidelines 2.2

    View full-size slide

  7. Conformance levels (from lowest to highest)
    1. A
    2. AA (A + AA) ← Most common
    3. AAA (A + AA + AAA)
    www.w3.org/TR/WCAG21/#wcag-2-layers-of-guidance

    View full-size slide

  8. — W3C
    “Although these guidelines cover a wide range of
    issues, they are not able to address the needs of
    people with all types, degrees, and combinations of
    disability”
    Background on WCAG 2

    View full-size slide

  9. Automated accessibility testing

    View full-size slide

  10. axe DevTools
    • Other tools are available!
    • Fewer false positives than other tools (anecdotally)
    • Widely used
    • Maps issues to Deque University knowledge base
    • UI (in Chrome/Firefox dev tools) for axe-core
    • Many services run axe-core under the hood
    • Decent free baseline product with room to grow
    www.deque.com/axe/devtools

    View full-size slide

  11. axe-core
    Disclaimer: I know very little about
    this; best left to experts like you!
    1. Install in your CI/CD pipeline
    2. Con
    fi
    gure to appropriate
    version, level, etc.
    3. Then either:
    • Flag issues on build
    • Export reports

    View full-size slide

  12. Facts and
    fi
    gures
    • 20% to 25% of WCAG 2.1 AA issues – Level Access
    • Around 40% ‘accessibility issues’ – Smashing Magazine
    • 57% of ‘digital accessibility issues’ – Deque
    www.levelaccess.com/blog/automated-accessibility-testing-tools-how-much-do-scans-catch/
    www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/
    www.deque.com/blog/automated-testing-study-identi
    fi
    es-57-percent-of-digital-accessibility-issues/

    View full-size slide

  13. Automated testing is really useful for
    things like
    • Colour contrast
    • Suspect markup
    • Missing content, like image alt text and the document
    • Touch target size
    github.com/dequelabs/axe-core

    View full-size slide

  14. Manual accessibility testing

    View full-size slide

  15. What I won’t be covering

    View full-size slide

  16. Mobile testing
    • This is a WCAG requirement
    • You’re probably already doing it
    • To a great extent, also covers when users:
    • have browser zoom turned up on larger screens
    • change the font
    • add extra text spacing

    View full-size slide

  17. A bunch of design stuff
    • Descriptive (alt) text makes sense
    • Form
    fi
    eld labels provide enough information
    • Captions match a video’s audio track
    • Using colour alone to convey meaning
    • Icon-only buttons

    View full-size slide

  18. We’ll focus on just three things
    1. Keyboard-only use
    2. Screen reader software
    3. Speech recognition software

    View full-size slide

  19. Keyboard-only use

    View full-size slide

  20. Keyboard controls
    • Tab ⇥ moves through the tab index
    • Enter/Return ⏎
    • Activates a link or button
    • Submits a form
    • Space ␣
    • Activates a button (not a link)
    • Checks a checkbox
    • Up ↑ and down ↓ move through dropdown options and radio groups

    View full-size slide

  21. Some keyboard-only testing
    fi
    nds
    • Incorrect markup
    • Keyboard interaction expectations not met
    • Focus indicators
    • Unexpected tab order

    View full-size slide

  22. Keyboard-only testing top tips
    • Check for skip links
    • Only interactive elements should
    be focusable
    • Double check against default
    browser behaviour
    • Try to cancel an action with Esc
    playground.tempertemper.net

    View full-size slide

  23. Screen reader software

    View full-size slide

  24. Popular screen reader software
    • NVDA for Windows
    • JAWS for Windows
    • Narrator for Windows
    • VoiceOver for Mac
    • VoiceOver for iOS/iPadOS
    • Talkback for Android

    View full-size slide

  25. Some screen reader testing
    fi
    nds
    • Whether form inputs are properly hooked up to their labels, hint text, etc.
    • Components that look like one thing and are read out as another
    • Incorrect heading structure
    • Missing page ‘landmarks’

    View full-size slide

  26. Page landmark examples
    1. Header
    2. Navigation
    3. Main content
    4. Sidebar with content
    fi
    lters
    5. Footer

    View full-size slide

  27. Screen reader testing top tips
    • Don’t use the tab key!
    • Understand the ‘modes’:
    • Navigation
    • Interaction
    • Learn the ropes on an accessible website (like GOV.UK)
    • Once you’ve mastered the basics, learn shortcuts
    www.tempertemper.net/blog/screen-reader-users-and-the-tab-key

    View full-size slide

  28. Speech recognition software

    View full-size slide

  29. Popular speech recognition software
    • Dragon for Windows
    • Speech Recognition for Windows
    • Voice Control for Mac
    • Voice Control for iOS/iPadOS
    • Voice Access for Android

    View full-size slide

  30. Some speech recognition software testing
    fi
    nds
    • Decorative button icons that have not been hidden
    • Labels not matching their underlying accessible name
    • Incorrect semantics

    View full-size slide

  31. Speech recognition software testing top tips
    • Learn the ropes on an accessible website (like GOV.UK)
    • Don’t begin testing on your own product until it works well for:
    • Keyboard-only users
    • Screen reader users

    View full-size slide

  32. Ideal process involves
    • axe-core in CI/CD pipelines; con
    fi
    gured to catch WCAG 2.2 AA, plus
    fl
    ag best practices
    and AAA
    • Screen reader testing with multiple screen readers across multiple operating systems
    • Speech recognition software testing with multiple speech recognition software apps
    across multiple operating systems
    • Testing on multiple platforms:
    • Parallels for Mac (or equivalent) to test on Windows
    • Device lab for native mobile accessibility testing and Windows users to test on Mac

    View full-size slide

  33. Getting started
    • Start by aiming for WCAG 2.1 AA conformance
    • Run axe DevTools on each page (until axe-core is installed and con
    fi
    gured)
    • Start manual accessibility testing with the software on your machine
    • Once comfortable, introduce testing with a second screen reader or speech
    recognition software package, ideally on a different platform
    • Ask devs to check with the keyboard and their built-in screen reader software
    • Get eyes on designs early – you’ll spot issues others won’t

    View full-size slide

  34. Don’t worry – it’ll get quicker!
    • Getting to grips with a new way to use UI takes time
    • Eventually, it’ll be as quick as testing with the mouse
    • Introducing manual accessibility testing gradually is the best way

    View full-size slide

  35. Don’t forget the three steps
    1. Keyboard only usually
    fi
    nds the big issues
    2. Screen reader software
    fi
    nds a bunch more
    3. Speech recognition software
    fi
    nds the remaining issues

    View full-size slide