Screen readers in the real world
Like many designer/developers, I’ve read a lot about screen readers, tested using screen readers, and tried to bring screen readers into my thinking about design, usability and site structure.
This is of course a limited way of working; I don’t rely on a screen reader to access digital content, and testing a platform I am already familiar with—and likely had a hand in designing or building—takes a huge variable out of play – surveillance (more on this to follow).
A few of us were recently able to experience usage of a screen reader in the wild, this came in the form of a webinar titled Using Screen Readers and Testing Tools to Evaluate the Accessibility of a User Journey.
The webinar was delivered by Larry L. Lewis Jr, a technology and accessibility teacher who has complete blindness.
Larry began by explaining that he takes a lot of flights, and since the travel agent he relied on closed he now books these directly through the websites of airline carriers. In order to navigate the web, Larry uses the JAWS for Windows screen reader, and gave a demonstration of two user journeys that involve booking an airline ticket.
During his demonstration, Larry made two very important observations –
- You can have a fully compliant website/code that is not accessible to all users. A website or system may satisfy every point on an accessibility checklist and still be inaccessible. This is why user testing is crucial.
- When Larry entered the airline websites, after he was sure he was on the right website (something he referred to as the Surveillance stage of his user journey), he went straight to the first form input field on the page. Despite what the screenreader was feeding back to him, he knew by experience that the first form input was likely to be the ‘flying from’ field, which was correct in both the examples he showed.
What does this tell us about site structure and testing? Firstly, real user testing is fundamental to providing an accessible platform, as the requirements of a user cannot be fulfilled by meeting a checklist. Secondly, Larry demonstrated an important assumption that he relies on to navigate the web, this kind of information is something that can only come from people with experience in actually doing the thing you are tying to test.
Larry then listed out what he considers to be the various components of a user journey, which he defines as –
- Surveillance: Where am I and what’s around me?
- Destination: Where do I want to be?
- Navigation: How will I get there?
- Interaction: What are the tasks that I need to perform on the way?
- Completion: I MADE IT!
There is quite a lot going on there, and by breaking it down this way we can observe the multiple steps that must be considered when designing, building and testing with accessibility in mind.
Thanks to Larry for taking the time to deliver this demonstration, and for giving us a window into his view of the web.
Watch Mark Sutton give a screen reader demo for digital accessibility –
If you’re a Mac user, you can use the VoiceOver utility (built in to the OS), here’s a guide to get you started – https://webaim.org/articles/voiceover/