The Do’s and Don’ts of Accessibility and Inclusive Design: Vision
When developers plan to make an application accessible to those with visual impairments, often the first thoughts are about screen readers and making sites and applications available to people who are blind. While that is an important aspect, it should not be where the discussion about accessibility stops. Vision is a broad area, and there are a number of accessibility issues in the area of vision. Here are some examples of primary visual disabilities:

  • Refractive error: Focusing light on the retina. This includes nearsightedness, farsightedness, and astigmatism. In many cases, glasses can remedy this, but some cases are too severe for glasses to help
  • Cataracts: A clouding of the lens in the eye that can be slight to severe
  • Macular degeneration: A condition that causes blurred or no vision in the center of the visual field
  • Color blindness: A situation where vision may be normal in most means but the ability to see certain colors is hindered

In addition, there are a variety of visual situational disabilities that many of us may deal with:

  • Having our eyes dilated as part of a vision procedure
  • Stepping outside into the bright sunlight and trying to see something on our phone or device
  • Corneal abrasion: Think of getting sand or dust blown into your eyes to the level that you can’t wear contact lenses for a few days

Each of the situational disabilities described above is temporary. Still, each of them would benefit from accommodation, and we should make the applications we develop accessible to as many people as possible.

Design Considerations

How can we make applications more accessible to people with visual impairments? Below are some design suggestions, many of which do not require any assistive technology.

Use appropriate color contrast:

Using a distinct contrast of colors is especially important when dealing with color blindness, but this design practice is helpful for everyone. The usual combination is dark text against a light background, but this can be reversed if using a dark background. The Web Content Accessibility Guidelines (WCAG 2.1 is the current recommendation) encourages a color contrast of 4.5:1 for medium-sized bold or unbold text and 7:1 for small, unbold text.

Enable scalable fonts:

By allowing the user to magnify and scale the font size for their needs, users can more easily read the text in a variety of situations.

Put all the information on the page:

If you have to navigate a site with a vision impairment, it’s frustrating to need to download information as separate documents. In some cases, it’s necessary, such as with binary files or installable executables, but if dealing with text, where possible, make it available within the page itself.

Avoid using color alone to display meaning:

Green means go, yellow means proceed with caution, and red means stop. For users with normal vision, these color cues are common and can communicate a lot of information quickly. But for a color-blind user, this meaning can be missed. There isn’t a single type of color blindness, so where possible, use text or graphics to display and convey greater meaning than color.

Make your pages as linear as possible:

Having pages that flow from top to bottom in a single-column format is easier for people who need to increase magnification on a page. The text will align with the magnification level, and the pages will display similarly to how they will at normal magnification. Spreading the content out over multiple columns or in a side-to-side format makes it difficult to see where the content is, and navigating the page could be confusing.

Do not separate elements that go together:

By grouping text boxes and buttons that relate to each other, we can make sure that context is not missed and that actions that need to be performed in a certain order are easy to interpret. Think of a form layout that needs to be magnified by 200 percent. If you can’t see the button that goes with a particular text box, it’s a good bet that your users will miss it, too.

Considerations for Screen Readers

While the modifications discussed above benefit everyone, there are some situations where assistive technology is needed. Screen readers are applications that take the text that appears on a screen and reads it aloud for the user. There are a number of techniques that can be used to help make this process easier, and as an added bonus, these additions can be checked with automated scripts.

Describe images and provide transcripts for video:

The alt tag is very helpful for displaying additional descriptive meaning for an element. Any image that appears on the screen that is meaningful to a user should have a descriptive alt tag. For a video, transcripts can go into greater detail about what is appearing on the screen.

Make content easy to navigate:

Set the tab order so that the user can more easily navigate to the most important information. The first item should be a link at the top of a page that says, “Skip to main content,” and allows the user to bypass the navigation elements on the page.

Use HTML5 options to make pages more structured:

Use the options available through HTML5 such as article, nav, sidebar, etc. These labels give a much better idea of what is being navigated. Use div tags sparingly, and if they must be used, give an alt tag description that can provide context.

Provide a keyboard-only option to complete a task:

It is common to rely on a mouse or another pointing input device to complete actions, but for screen reader users, a mouse is useless. Navigation and interactions are done via keyboard. If a workflow can’t be completed with just a keyboard, users who rely on screen readers will not be able to use your application.

If there are links, make the link text descriptive:

If a page has multiple links that say “Click here,” it is easy to lose the context of which link goes where. Be descriptive with the link, and define specifically where it will take you.

Tests We Can Automate

With the items listed above, these are all areas that can help me think about and prime my testing strategies. There are also areas that are good candidates for automation.

All images have an alt tag and have descriptive alt text

This is a simple first step and its one that is easily handled by any tool that can examine a web page. If there is an tag, there needs to be alt text associated with it. Granted, not every image is going to be meaningful to the user: Some are purely decorative or are repeated inside of a page. If an image is part of the page flow and is relevant to the content being displayed, it is important to verify that there is alt text for these images. For images that are just there for a sense of page aesthetics, null tags can be created.

Tables have and values

Tables are challenging for screen readers and for keyboard navigation. Check that the tables are properly descriptive so that they are easier to navigate and provide context for the data in each row or column. Search for and tags in each table and identify any instances where they are not used.

Inputs have labels

When using forms, it’s important to identify all of the controls and what they represent, especially for assistive technologies like screen readers. The <label> tag helps to present that control to the user effectively. Example: If a form is looking for an email address, and the input type is “text” with a name and id of “emailaddress”, adding <label for=”emailaddress”> will provide that extra level of context for a screen reader.


On the whole, these are small changes, but they can make a big difference in the user experience of our sites and applications. Given the variety of situations that are related to vision, placing a focus on accessibility and inclusive design can help many more people enjoy our sites and applications, as well as use and buy our services. Accessibility and inclusive design aren’t just the right things to do. They make good business sense, too.

Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.

Get a free 30-day trial

Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.
You might also like these articles