How to design websites for blind and partially sighted people

In the U.S., approximately 12 million people 40 and over have vision impairment.

These are some of the realities of people living with sight loss in the modern world:

• Almost half of blind and partially sighted people feel ‘moderately’ or ‘completely’ cut off from people and things around them.
• Older people with sight loss are almost three times more likely to experience depression than people with good vision.
• Only one in four registered blind and partially sighted people of working age are in employment.

However, advancements in web-related technology has opened up the world to blind and partially sighted people in a positive away, and can help them feel more connected to friends, family and services across the world.

As Paul Johnson’s interview with blind internet user Sunil Peck, who grew up in the pre-internet era, reveals, “The arrival of the internet was (even more) profound for those with visual impairments. [Sunil] explained “it was thanks to the internet that at the age of 25 I read my first newspaper.” At the time things we took for granted were just not available to the blind.”

For the visually impaired, navigating the online world has it’s own specific set of issues that arise not just because of bad design, but also because of thoughtlessness. We designers can do our best to avoid building websites with poor navigation and confusing menus, but how many of us forget to add alt-text to images, or even make them vaguely readable?

This article is intended to walk you through the various ways you can ensure your own website is as accessible as possible for people with visual impairments.

What are the most popular types of assistive technology for using the internet?

In 2016, Gov.uk published the results of their assistive technology survey, in which the Government Digital Service asked 712 users about what devices, web browsers and assistive technology they used to access GOV.UK.

These were the results:

• Screen magnifier 30%
• Screen reader 29%
• Speech recognition 18%
• Readability 15%
• Other 8%

According to the survey, 30% of users said they use a screen magnifier, which is a piece of software that enlarges and enhances anything users are reading and interacting. 38% of those magnifiers also have screen reader capabilities, with ZoomText being the most commonly used in both categories. Other popular screen magnifiers included Supernova and MAGic.

Almost the same percentage of respondents accessed GOV.UK with a screen reader. These are pplications that turn on-screen content into speech or Braille. Most screen readers are made up of two things: the screen reader software, and a Text-To-Speech (TTS) engine, which is what converts the text from the screen reader into speech.

The most commonly used is JAWS, (or Job Access With Speech). This is followed by VoiceOver, a feature for Apple products that gives, “auditory descriptions of each onscreen element and provides helpful hints along the way — whether you prefer using gestures, a keyboard or a braille display.”

Here’s computer programmer Austin Seraphin, who has been blind since birth, on the iPhone’s VoiceOver feature and how it impacted his life.

The next popular option is NVDA (NonVisual Desktop Access), a free and open-source software that you can download or transfer to a USB stick so you can use it with any computer.

So how can you improve the accessibility of your own website for people visiting your website using this range of assistive technology?

Andreas Savva, an accessibility consultant at a leading charity, give his advice.

Recommendations for improving accessibility for blind and partially sighted people

Andreas: What I suggest is that developers and designers should know their audience, and that includes people with a variety of abilities and disabilities. Accessibility should not be considered at the end of the development process, often the last ‘check’, but incorporated through the design and development process of the website/product.

There are guidelines (WCAG 2.0) that can help designers and developers to create accessible websites. Also, the WAI-ARIA Authoring Practices 1.1 (working draft) provide a comprehensive documentation of design patterns that can be used to create accessible website ‘components’.

However, that does not necessarily mean a website that conforms to the guidelines will be easy to use by people with disabilities. It's important to include people with disabilities during the evaluation process to ensure that a website/product is easy to use.

What are the most common issues when navigating the web?

Andreas: Here are some of the more frequent problems found by blind users:

• Areas not accessible via the screen reader
• Page content not structured with headings
• Headings do not follow logical sequence
• Images without alternative text
• Inputs without associated labels
• Links without accessible description
• Buttons without accessible description
• Interactive elements not properly marked using the appropriate HTML element

We often find that the problems reported by blind and partially sighted people differ a lot.

How can we improve the experience for people with color blindness?

Andreas: There are a few approaches that can be used to avoid problems for people with colour blindness on the web.

• There are known color combinations that are causing problems, which can be avoided (e.g. green/red)
• Use high contrast between the background color and text: WCAG 2.0 AA requires a contrast ratio of 4.5:1 for normal text and 3.1 for large text. Large text is considered 14 point and bold text, or 18 point or larger text.
• Do not solely rely on color to convey information. Ensure that information conveyed by colors is available in other visual ways.
• Text over background images can be problematic, as part of the image or the entire image may not have sufficient contrast in relation to the text color.

How to write content that works best with screen readers

The same principles that apply to writing clear and concise copy for the web also apply to writing content that can easily be translated by a screen reader.

Gov.uk offers a breakdown of how screen readers respond to content, which is important to keep in mind and is definitely worth taking the time to read.

Basically it reiterates how the English language is a complex beast even at the best of times. We have plenty of words that are spelled the same but sound different: we tie a “bow” or take a “bow”, we pronounce the acronym of Value Added Tax as “VAT” and “vat.”

But any good screen reader should be customizable enough to work in most effective way for the individual user. Some include dictionaries where you can change the way a word is pronounced, or add pronunciations for new words.

The more you make your content accessible for people with visual impairments, the less accessible you may be making it for other people. You can add spaces between letters like “V A T” to make it more screen reader friendly but it will make things difficult for sighted people to read, especially if they have low literacy or find reading difficult due to dyslexia.

Here’s the major takeaway from Gov.uk’s advice on the subject:

“Don’t write content that works specifically for screen readers, write content that works well for everyone. Use correct punctuation, spelling and grammar, use standard conventions for acronyms and abbreviations, and use words that are appropriate for your audience.”

Should I use automated tools to check accessibility?

Years ago, Gov.uk decided to test the efficiency of 10 free automated testing tools by building the “world’s least accessible webpage” complete with 143 accessibility failures grouped into 19 categories.

Here it is in all its glory:

According to Gov.uk the page contains such common failures as images without alt-text, blank link text, flashing content that doesn’t carry a warning and overly complicated language.

Here are the results:

• 29% of the barriers created weren’t picked up by any of the tools (42 barriers out of 143)
• Tenon counted the most error messages and warnings – 37% of barriers found.
• If you include manual inspection prompts, Asqatasun was the most effective – 41% of barriers found.
• Google Developer Tools only picked up 17% of the barriers.

For the most effective accessibility testing, think of a testing tool like a spellchecker. It can certainly help you pick up issues, but it should never be used in isolation. The best way to be sure that you’re picking up every accessibility issue is by combining automated tools with manual checking, website checklists, and usability testing.