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.

Transcript

1. 23rd January 2024 Getting started with manual accessibility testing Martin Underhill
2. Martin Underhill Lead Accessibility Specialist
3. What we’ll cover 1. Accessibility conformance 2. Automated accessibility testing 3. Manual accessibility testing 4. Process (ideal, and pragmatic)
4. Accessibility conformance
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)
6. Versions • 2.0 • 2.1 ← Most common • 2.2 ← Current recommendation (brand new!) The Web Content Accessibility Guidelines 2.2
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
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
9. Automated accessibility testing
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
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
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/
13. Automated testing is really useful for things like • Colour contrast • Suspect markup • Missing content, like image alt text and the document <title> • Touch target size github.com/dequelabs/axe-core
15. Manual accessibility testing
16. What I won’t be covering
17. 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
18. 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
19. We’ll focus on just three things 1. Keyboard-only use 2. Screen reader software 3. Speech recognition software
20. Keyboard-only use
21. 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
23. Some keyboard-only testing fi nds • Incorrect markup • Keyboard interaction expectations not met • Focus indicators • Unexpected tab order
24. 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
25. Screen reader software
26. Popular screen reader software • NVDA for Windows • JAWS for Windows • Narrator for Windows • VoiceOver for Mac • VoiceOver for iOS/iPadOS • Talkback for Android
28. 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’
29. Page landmark examples 1. Header 2. Navigation 3. Main content 4. Sidebar with content fi lters 5. Footer
30. 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
31. Speech recognition software
32. Popular speech recognition software • Dragon for Windows • Speech Recognition for Windows • Voice Control for Mac • Voice Control for iOS/iPadOS • Voice Access for Android
33. Some speech recognition software testing fi nds • Decorative button icons that have not been hidden • Labels not matching their underlying accessible name • Incorrect semantics
34. 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
35. Process
36. 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
37. 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
38. 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
39. 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
40. Thanks 🙇
41. Questions!