Posted on by Ela Gorla in Design and development, User experience
Tags: Assistive Technology
Screen readers are familiar to many in digital, but how they work in practice can be less clear. In this post, we shed some light on the topic.
Screen readers are software applications that convert on-screen content into audio, reading aloud what’s displayed on your laptop or mobile screen. For more information on how they work, visit browsing with a desktop screen reader and browsing with a mobile screen reader.
Despite their widespread use, there are still many misconceptions about how screen readers work and how people interact with them. We explore some of these below.
Probably the biggest misconception around screen readers is that they are only used by people who are blind. This is far from reality. WebAIM's latest Screen Reader User Survey shows that only 77% of respondents identified as being blind.
Many people may access digital content with a screen reader, for different reasons. For example:
Read about the experience of some screen reader users:
With so many people using screen readers for different reasons, it's only natural that each person's experience is unique.
People adjust their screen reader's settings and choose a navigation method to suit their needs and preferences. Two people with the same disability using the same screen reader may still have very different experiences.
Some people use screen readers in combination with other assistive technology - for example a Deafblind person may use it together with a refreshable Braille display while someone with low vision may use it together with screen magnification software. The input device used to navigate web content can also differ; blind people will use a keyboard while low vision or sighted people may use a mouse and a keyboard. And people with thinking disabilities may choose to have text highlighted as the screen reader announces it.
It's often impossible to predict how someone will use a screen reader. The best way to learn about the different strategies and methods used by people is to observe User Experience (UX) Testing sessions.
Several screen readers are available - JAWS, NVDA, and Narrator for Windows machines, VoiceOver for Mac and iOS devices, TalkBack for Android devices, and so on.
While they work in similar ways, there are some key differences. Keyboard commands (on laptops and desktops) and gestures (on touch screen devices) may vary slightly from screen reader to screen reader.
The same applies to how screen readers announce content. As demonstrated in the Screen Reader HTML Support table screen readers can announce elements and labels differently. For example some announce a button as "button" followed by its visible label (such as "button save") others announce the label first ("save button").
This is nothing to worry about, screen reader users are aware of these differences and don't expect all screen readers to work and announce elements in the same way. Trying to force screen readers to behave in any other way is likely to confuse, rather than help, people.
We are sometimes asked whether having a simplified version of a website or app designed and built for screen reader users specifically is a good solution. The answer is, no.
Having separate versions of a product for different groups of people is not an inclusive approach. A more inclusive solution is to build a product that adjusts and supports the needs and preferences of everyone, including screen reader users.
It's not an efficient or sustainable solution either; creating and maintaining different versions of a product requires time and money. By spending just a portion of that time and money to implement accessibility considerations, you can create a product that works better for everybody.
A key accessibility consideration when building content that works for screen reader users is to provide a text description for images. Designers and developers are sometimes unclear on why this is required. Surely screen reader users don't care about images, right?
As discussed under Misconception 1: only blind people use screen readers, not all people using screen readers are blind. Some may have enough vision to know that an image is on the screen but not to make out its content. And some people with thinking disabilities may see the image but struggle to interpret it. All these people expect their screen reader to describe the image for them.
Some blind people also really appreciate images being described. This is particularly true for people who lost their sight later in life. They may like to know that an image of a sunny, clear sky or of a menacing storm is on a page as that will evoke a particular feeling or emotion.
Another common misconception is that screen reader users need instructions on all elements that make up a web page or app screen.
For example, for a page containing an "Add to cart" button, some may assume that including the hidden instruction "Activate the 'Add to cart' button to add the product to your shopping cart" is useful to screen reader users. In fact, this adds unnecessary noise which ultimately worsen people's experience on the website or mobile app.
Just as you wouldn’t include instructions on how to use buttons or links for sighted users, there’s no need to explain how to operate them for screen reader users.
As long as elements are coded following best accessibility practice, screen readers provide all necessary information by default. For example, when reaching an element coded as a button, they announce it as a button and read out its visible label. People are then able to activate the button using their screen reader default keyboard command or gesture.
Many screen reader users, especially if blind, navigate web content using a keyboard. This doesn't mean all content must be keyboard focusable.
Screen reader users have a wide range of keyboard commands at their disposal. Unlike people who use a keyboard without a screen reader, they can navigate to all sorts of focusable and non-focusable items.
For example, they can reach a new line of static text by pressing the down arrow key; the next heading on screen by pressing the H key; the next page section (like the header, main or footer) by using the D key; and so on.
Trying to make all content keyboard accessible is not needed and is going to interfere with the way screen reader users navigate websites.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。