Join Derek Featherstone for an in-depth discussion in this video Vision issues, part of UX Foundations: Accessibility.
- Using a computer, tablet, or a mobile device without being able to see the screen might seem like quite a challenge to you. That's because it is. You've seen some of the tools that people with visual impairment use already; screen readers and screen magnifiers. In order to use these tools efficiently, people with a visual impairment have a few functional needs. When a blind person uses their screen reader to explore the screen, they need to know exactly what each object is, what it is called, and what it does. For example, when moving around your site, the screen reader will say things like, "link," "login", or "slider zoom level 75%" or "Heading level three: "Getting started building your own shrink ray." In each of those cases, as the person explores the screen, they are told what type of object it is, a link, a slider, or a heading, and they are told what it's about.
Log in, zoom level 75%, Getting started building your own shrink ray. In most of those cases, they aren't told exactly what they can do with that thing, but most of those items have some built in expectations about what they are. A link is activated by pressing "Enter" and a slider uses the arrow keys to change the values. Some screen readers will provide those extra clues to the user if they're on an object for a while and haven't moved on or haven't done anything with the object. So what are these functional needs? First, you get a lot of this for free with programmatic accessibility.
Most of this is done by developers by using straightforward objects in their work. Links, Form fields, Buttons, Headings, Lists, and other pieces of code all provide structure and programmatic accessibility. The screen reader understands what a link is, what a button is, and what a slider is all because of the way things are coded. As a UX designer you don't need to know too much about that. Just be aware that most of the work is done at the code level by development teams. A blind user can't see the screen and if they can't see the screen, they can't see where the mouse cursor is.
So what do they do? They move around the screen, click links, submit forms, and navigate using the keyboard only. That's the second functional need. Creating interfaces that work really well with the keyboard is a must-have for accessibility. You should build that need into any personas that you're creating for your projects. It doesn't need to be for the persona, "Stacy the screen reader user." It can simply be for "Stacy, the statistician." Take that existing persona you already have and add the functional need for efficient keyboard access to it, and you've gone a long way to ensuring accessibility for your site because that screen reader user does everything with the keyboard.
The third major functional need for a screen reader user, is having text-based representations of visuals on the screen. Think of a progress bar or a doughnut chart or any other graph. Those visual representations aren't useful to someone that can't see unless there's also some type of text-based representation of it available. It might be a brief description of the visual or it might be a table that provides all the same data with a summary. Either way, this is what we call a "Text Alternative", and it is a must-have for accessibility.
We also want to ensure that people with low vision are able to easily access our sites as well. Because they are often zoomed in and only see a portion of the screen at once, we need to take that into account when we're designing layouts. Here's a layout from an application we recently reviewed. Let's think about this from a task flow perspective. The person using this app comes here to edit the details of the event. They change the title and the date, and then they make some notes about why they changed what they did. Then they save their work and return to the previous screen.
Let's do a really crude simulation of low vision. Hold up your hand and pretend to hold on to a straw. Now take a look at that layout through the straw. Now go through that same task flow while looking through the straw and with your other eye closed. Edit the title, edit the date, make some notes, and then save. What did you notice about the position of the "Save" button? It's in the top right corner. How did that work for the task flow? We'd be much, much better off with that button down at the bottom of the form.
It would be easier to find. One of the most important functional needs for a screen magnifier user is to have well-placed calls-to-action. Finally, people with low vision need flexibility in their interfaces. They need to be able to increase font size and reflow the layout of forms into vertical stacks to make it easier to see all of the information presented to them. This flexibility creates the environment that they need to be able to customize the display of the site to work well for the way that their eyes work.
You should design for that flexibility. Include it in your personas. I love designing for people with low vision because in many ways the same issues affect people using a mobile phone or tablet. Usually what works well for someone with low vision also works well for someone on a very small screen.
- What is accessibility?
- Managing flow
- Ensuring proximity in your design
- Understanding how screen readers and voice recognition programs work
- Designing for hearing, vision, mobility, and cognitive issues
- Considering accessibility in layout
- Integrating accessibility into your content strategy