I organized an accessibility workshop for our front-end and full-stack developers, user interface and user experience designers and others involved in digital production. This post will concentrate on screen-reader (SR) users way of navigation because it may surprise non-screen-reader users quite a lot.
One of main surprises can be that SR users don’t tab through your website. A lot of people assumes that based on Web Content Accessibility Guideline (WCAG) success criteria that defines tabbing order for example.
Screen-reader users have multiple and more effective keyboard shortcuts
If you have ever tried to tab through a webpage you may have noticed one very important thing – tabbing only works on interactive elements. So this is the first problem for a screen-reader user – how would they get to the non-interactive elements like images and texts then? It is worth mentioning that screen-reader users do tab through interactive elements, especially when they are in the form for example.
Screen-reader is a complex software. And there are also differences between screen-readers and also their users, obviously. So to predict how all SR users navigate the web is not an easy task. But we can find some common ground on how majority of desktop (!) screen-reader users navigate the web:
- landmarks – a screen-reader user can jump directly to main landmark or navigation and other landmarks, as long as they are coded correctly (best with semantic HTML elements, or if not possible at least ARIA),
- headings – screen-reader users use headings for navigation quite often, we can compare it with sighted users scanning headings when searching for details on the page – it is almost the same pattern,
- forms – screen-reader users that expect a form on a page can jump directly to them if they want,
- links, images, buttons and so on – screen-reader users can jump to practically all semantically important elements on the page,
- they can search the page internally in the screen-reader and then jump to results as well.
Different screen-readers have different settings and it is not my ambition to document them here but I hope that this list make it clear that screen-reader users may navigate the web even more effectively than mouse users can. The problem is that they must first invest some time to get familiar with the page structure and in my opinion developers should do our best to make it easy for them.
How can developers help screen-reader users to be more effective
As mentioned above, screen-reader users can jump directly to parts of page and with that they can save a lot of their time. Imagine a long webpage article that has a ordering form in the middle. A mouse user will have to scroll to the form and then click into the fields to submit the order, while a screen-reader users just presses the shortcut for forms or even fields and skips scrolling at once.
But for this to work we need the HTML semantics. Therefore it is crucial to use the correct HTML elements that provide their roles and also extend them with labels when needed. If we have multiple nav elements on the page then they should be labelled with help of ARIA – for example aria-label=”Main navigation”. If we have multiple forms that have visible titles we could use aria-labelledby=”ID-of-title-that-describes-the-form” and so on.
HTML semantics is the key for this to work. Not only for screen-reader users but also for voice-control users and other assistive technology users that can derive information from the document object model (with CSS and JavaScript afterwards).
Mobile screen-reader users don’t read whole page from top to bottom
When we mention screen-readers we must not forget about millions of mobile users. According to Google mobile visits even prevail, so let’s think about them as well.
Mobile screen-reader users are much more limited in regards to how they can navigate the page but they still have some quite effective possibilities;
- they can move through containers and landmarks, just like the desktop screen-readers,
- headings are very popular on mobile as well – not a surprise there as headings are so important to understand the content,
- move between same items (for example from link to link),
- tables, lists, buttons, form controls, text fields, search fields, images and so on
Apple’s VoiceOver has a total overview about navigation (opens in new window) and the same goes for Android’s Talk Back’s overview on navigation (opens in new window).
It is also worth remembering that mobile screen-reader users can investigate the page with swiping – getting one item at a time or just tapping wherever on the screen and hearing about the element in focus.
Testing with screen-readers for sighted users
When sighted users first begin with screen-reader testing it can be quite some experience. Especially when screen-reader focus and actual page focus on an element can differ at once. There are some plugins for screen-readers that make the screen-reader focus visible at the same time as for example NVDA focus highlight addon (opens in new window).
But I think seeing that when using screen-reader is actually not so effective. Our visual perception can destroy the meaning of testing and we should really not see the content if we want to test it with screen-reader. Then we are probably more likely to really think about the content from screen-reader perspective and maybe find some parts that really need improvement.
There are of course sighted screen-reader users out there maybe just complement their experience with screen-reader due to different problems (for example dyslexia), so I will not say always test with your screen off, but please do both at least.
