Designing for Visual Impairments

This is part 5 of a series that begins here: Designing for Accessibility.

In the previous article in this series I talked about design considerations for keyboard interaction, which was the last of three articles on designing for keyboard access. The good news is that the guidelines for keyboard accessibility also benefit users who require screen reader software to access content on your web pages. In the following article, I’ll talk about additional considerations for screen reader users and other users with visual impairments.

Many people equate web accessibility with screen reader use, but there are many other types of visual impairments to consider in your design. Macular degeneration, glaucoma, cataracts and other disorders can cause blurring, loss of areas of vision, decreased contrast sensitivity, a loss of visual acuity, or gradual loss of vision. Color blindness can occur congenitally or due to trauma; and decreased color sensitivity (such as the ability to tell the difference between navy blue and brown) and contrast sensitivity simply occur naturally as people age.

What this means is that many people — more people than you probably think — don’t see your page the same way you see it. They may:

  • use screen reading software such as Jaws, NVDA or VoiceOver to read the content on the screen
  • use a screen magnifier (such as ZoomText or the built-in Mac OS X screen magnification software) to greatly magnify the section of the page they are reading
  • use a custom style sheet to change layout or colors so it’s easier for them to read or understand content — or turn off styles altogether
  • increase the base size of fonts on their computer or in their web browser
  • temporarily zoom in or out using the browser zoom — if you’ve used ever your phone or a tablet device to view a web page, you’ve probably done this yourself at some point
  • wear corrective lenses to help them focus
  • do some combination of the above (including using a screen magnifier and a screen reader together)
  • do nothing at all

Let’s look at some of the ways you can make your content available to all of these visitors.

Provide unique, descriptive page titles (but keep them short)

A good page title benefits users who open multiple tabs in their browser or multiple browser windows, and users who find your content through a search engine. It’s also good for search engine optimization. But it provides a critical landmark for screen reader users, as it’s the first thing that’s read by the screen reader when the user visits a page.

In addition to stating what the page does or what it’s about, the title should provide enough context to identify it among other pages. If users are likely to be visiting multiple pages on your site, front-loading the title with the unique content will enable them to quickly differentiate between pages — for example, it’s faster to tell “Privacy Settings < shannon sans-serif” and “Edit Post < shannon sans-serif” apart than “shannon sans-serif > Privacy Settings” and “shannon sans-serif > Edit Post”.

Provide structure through content order, semantic headings and other markup, and landmark roles

All of the techniques involved in the article about designing for keyboard navigation also apply to visual impairments, but for different reasons.

  • Screen reader software reads content in the order in which it appears in the markup, so it needs to be ordered in a way that makes sense.
  • Screen reader users use headings to get an overview of what’s on the page: it’s like a table of contents.
  • People who use a custom style sheet to change how the page is rendered rely on the correct markup. You can’t make all the links blue on a yellow background if, in the underlying code, they aren’t links.
  • People who turn off style sheets will still be able to understand the content if it’s logically (and semantically) organized.

You, as the designer, may not be responsible for the final markup. But you can help your development team make the right choices by calling out the content order, regions that correspond to landmark roles, and heading levels.

For a great example, check out the Boston Globe’s recent redesign:

Boston Globe Home Page

The home page looks much like a newspaper. But the content order isn’t the same as the display order. In the content order, “The Boston Globe” text comes before the date; there are headings that aren’t visible to the eye that help make sense of lists of links, such as the sections; and the content in the middle column comes before the other columns. (Thanks to a well-considered responsive design, if a viewer resizes the page or views it on a tablet or phone the content responds to the available pixels, and things like the sections list collapse and expand accordingly — another benefit of logically structured content.)

If you were viewing your page with only the default browser styles, would the content still make sense?

Describe important images

Blind users and users with other severe visual impairments may not be able to see images on a page, so providing a text equivalent that a screen reader can announce is necessary for them to understand the content. But other users may benefit as well, such as those who are viewing a page over slow connections.

Not all images on a page are important to a user’s understanding of the content. Take, for example, a tweet from a Twitter feed:

A recent post of mine from Twitter

Twitter displays the poster’s avatar to the left to each tweet. The image reinforces the handle and name of the poster, which are displayed above the tweet text. The avatar image helps sighted visitors visually scan a list of tweets, but screen reader software doesn’t need the visual context: the visible Twitter handle and the poster’s name are sufficient. The image is clickable with a mouse, but can’t receive keyboard focus and isn’t wrapped with a link tag. In this context the image is presentational: if it wasn’t announced by a screen reader it wouldn’t inhibit anyone’s understanding of who wrote the tweet.

On the other hand, Salesforce uses images in its Recent Items list to visually differentiate items of different types:

The Salesforce Recent Items list - each item has an icon next to the item name

The icons make it easier to scan this list as well, but they’re also necessary in order to determine whether an item is an account, contact or something else, because the name doesn’t always provide that context. So the icon requires alternative text indicating what type of item it is, such as “Account” or “Contact” (not “A folder” or “A picture of a person”).

If an image contains important information such as text or data, if it’s a link that can receive keyboard focus, or if it provides visual context or structure to the page that is necessary to understanding content, then it needs a text equivalent that’s available to screen readers.

  • Indicate in the design deliverables which images are necessary to understanding page content, and which images are presentational.
  • Specify the text equivalent for images that supply necessary information.
  • Make sure the text equivalent is contextually useful: for example, either “Delete” or “Close Window” may be appropriate for a square with an X in it, depending on how it’s used.
  • Try for 5 words or less, if possible — avoid “Picture of”, etc. Some images, such as charts, will require more. This is usually provided using some other method than the “alt” property on the HTML image tag.
  • Avoid using images containing text for buttons, menu items, and other text that’s meant to be read — it’s not translatable, won’t adjust to default browser text sizes, and the contrast may not be sufficient for users with visual impairments that don’t require screen reader software.

If you were viewing your page with the images turned off, would the content still make sense?

Use sufficient color contrast, and don’t rely on color alone to convey information

Color blindness is one of the most common forms of visual impairment, but people with partial sight or vision degeneration due to aging may also perceive colors differently than those with normal vision. These visitors may have trouble distinguishing colors with similar lightness, hue or value because the contrast is reduced for them.

WCAG 2.0 guideline 1.4.3 recommends a minimum contrast ratio of 4.5:1 between the foreground and background colors for readability, with a contrast ratio of 3:1 between surrounding text (for example, link color compared to the paragraph text color).

Additionally, use some means in addition to color to differentiate: underline or bold-face links in paragraphs, use different line styles or patterns in addition to different colors for graphs or charts, provide text labels, or use icons (with appropriate text equivalents). This will allow users with diminished color sensitivity to distinguish content.

Also, avoid referring to content on the page by color — for example, “click the red button”. Refer to labels or section headings instead.

Consider proximity for visual cues and feedback, and provide audio and visual cues for important notifications

Screen magnifying software greatly enlarges a portion of the screen to enable people with limited vision to read it. Here’s an example of Virtual Magnifying Glass:

Magnified area of a screen showing part of a label and text field

If an action taken by the user changes content that isn’t in the proximity of the enacting control, users may miss the change — a problem not limited to assistive technology users, which is why visual transitions are often used by interaction designers. If you’re providing contextual help or inline form validation (such as password strength) to the right of a text field, screen magnifier users may not see the notification. Placing such messages below the text field will make them easier to see.

Screen readers have a similar issue in that they read content in the order in which it appears on the page, and if a change occurs outside the reading order it can be missed. Indicating when audio notifications are required, the urgency of the notification (polite or assertive) and the content, will help developers use ARIA live regions properly to notify screen reader users of the changes.

Provide sufficient context for links

Screen reader users can retrieve a list of links in a page, in a similar way that sighted users can scan a page to pick out a link of interest. But a screen reader may announce the link text; the link title text, if present; or both. It won’t announce the context around the link.

If the link text is “Read more” or “click here”, screen reader users can’t easily scan the surrounding context to figure out what the link is — and if there are multiple instances on a page of the same link text pointing to different pages, it will be very confusing. Try to provide enough information in the link text that it still makes sense out of visual context, such as “Continue reading: Designing for Accessibility: Visual Impairments”.

If there just isn’t space, provide the additional information as a title on the link. But be aware that some screen readers won’t read the title text.


To ensure the best reading experience for all users:

  • Provide unique, descriptive page titles.
  • Outline the structure of the page in your design deliverables — including content order, landmark roles, and heading levels.
  • Identify which images are presentational and which are necessary to understanding content — and describe them contextually.
  • Use sufficient color contrast, and don’t rely on color to convey information.
  • Provide feedback and visual cues in proximity, and provide both audio and visual cues for important notifications.
  • Provide enough context in link text that the text is still understandable if taken out of context.

Up next in the series: how does someone who is deaf or hearing impaired interact with your page?

October 24, 2011 · Tags: , ,

No Comments »

RSS feed for comments on this post. TrackBack URL

Leave a Reply