One of the things I’ve been working on lately is ensuring that our web apps are accessible, which primarily means that those with visual impairments can use them. Partially that means making sure to use high-contrast colors and large buttons, and partially it means the webpages work well with screen readers.
Screen reader compatibility largely breaks down into the following:
- Is the entire page keyboard accessible; can the user access all functionality and information without using the mouse?
- Does the screen reader tell the user everything he needs to know about what’s going on on the page?
- Does the screen reader avoid throwing gibberish at the user?
Is the page keyboard accessible?
Can all of the page functionality be used without a mouse? This means more than just being able to tab to all fields (although that’s the obvious first step). Other things to consider:
- Is there any information that’s only available when hovering over an area of the screen? Unless this is a field that can be tabbed to (in which case a screen reader will read the tooltip), that information may not be available to keyboard users (or mobile users).
- If there is a popup window, does focus return to the main page when the popup is closed? Similarly, when clicking a button, does focus go away? If focus is lost, a keyboard user is stuck.
Will all visible information actually be read?
- If the page contains text which isn’t associated with a control that can gain focus, it may be ignored entirely by the screen reader.
- If taking an action causes a visual change elsewhere in the page – say, making a warning visible – then even if that change is visible to the screen reader, the user is unlikely to know about it immediately and could either miss it entirely or become frustrated when it is encountered and it’s either not clear what caused the warning or it’s difficult to navigate back to the appropriate section.
Will extra information be read?
If you don’t tell them what not to read, screen readers will try to grab everything. Even a well-designed page will throw a lot of information at the user (which is why screen readers talk really fast). If you’re using tables to style your content, the screen reader will read off all the details of the table. When testing, I’ve found that sites like Facebook can completely overwhelm the screen reader. There are various attributes you can add to clean this up (such as role=”presentation”) which may or may not be correctly interpreted, depending on which screen reader you use.
Testing
Unsurprisingly, accessibility ends up being something that, while you can follow best practices, you still need to test for. The top screen reader option, JAWS, is horrendously expensive (starting at $900 for a home license), but NVDA is a free, open source alternative that works well for testing. Helpfully, there is a text box option so you can see what it’s saying rather than simply listening at high speed. So far I’ve only used it for work, but while writing this post I tried it out on this site and determined that the site is not actually screen reader friendly, which tells me I need to make some revisions! Hopefully I’ll have an update on that in a future post.
Is it worth it?
Making a website accessible can be a lot (and I mean a lot) of work, for relatively little reward (the number of people using screen reader software is obviously a small percentage of the overall audience, particularly for some specialized sites). However, we still have an obligation (both moral and, in some cases, legal) to make our work usable for as many people as possible. As a bonus, efforts taken to improve usability for people with disabilities often end up being a great help to people we wouldn’t normally think of as disabled, simply impaired – the elderly, for example, who may have weakening vision. In a future post, we’ll talk about accessibility improvements we can make that will help improve usability for all of our users.