A11y is the one-eyed king
When accessibility on the web is discussed, the WAI-ARIA spec often plays an important role. And not always in a positive way — inexperience with ARIA roles and the difficulty in setting up tests can make proper implementation a daunting task. In practice however, one doesn’t need ARIA for everything. Most websites’ accessibility can be greatly improved with the use of basic HTML elements and attributes. In this article, we present 8 guidelines on how to easily build an accessible website.
On Web Content Accessibility Guidelines (WCAG)
The W3C has created a standard, the WCAG 2.0, that serves as a guideline for making your website accessible. It states that “following these guidelines will make content accessible to a wider range of people with disabilities”. The guidelines themselves are very verbose, so instead you might want to follow this checklist.
A primer on screen reading on the web
Before reading through these 8 guidelines, it is important to understand how blind people use screen readers to access websites. A screen reader is a piece of software that reads text on a computer screen out loud with a computerized voice. It also supports various keyboard shortcuts, which enables blind people to scan web pages and access regions and functions directly that a sighted person would use a mouse for. In the video below Sina Bahram, a blind accessibility researcher, gives a demonstration on how he uses a screen reader.
1. Adhere to the standards
Screen readers read all textual information in the order as it is defined in the HTML. In order to help the screen reader interpret that content as intended, it is important that you use valid HTML. Furthermore it is important that information is coded using correct semantics. When the semantics are incorrectly defined, screen readers cannot process the information.
<span class="button" onclick="submitForm()">Submit form</span>For example, a button coded using a <span> combined with JavaScript to get the behaviour of a button will not be recognised by the screen reader as a button. In this case you should use a <button> element.
<button type="submit">Submit form</button>This element has all the intended functionality (like it being clickable) already built in and screen readers can rightly interpret it.
2. Make sure that each web page is usable by keyboard
Make sure that each user interface element is accessible by using the keyboard. You can check keyboard accessibility by tabbing through every element on the page to see if it can receive focus.
<form action="/path/to/endpoint" method="post">
<input type="text">
<button type="submit">Submit form</button>
</form>By using a <form> element, the browser allows keyboard access automatically on its fields and buttons.
Note: Use tabindex with caution. Since screen readers process information in the same order as they were defined in the HTML, you can get unexpected results if you interrupt this order by using a tabindex with a value higher than 0.
3. Use headings to describe the content
A screen reader can jump from heading to heading to give the user a quick grasp of what content is available on the webpage. That’s why it is important to ensure that each heading is a good description for the underlying content. Also, headings should be structured hierarchically — e.g. a <h1> is followed by a <h2>, not a <h3> — so that the screen reader can properly move through the content in a logical order.
<h1>Cat</h1>
<p>The cat is a small, typically furry, carnivorous mammal.</p>
<h2>Biology</h2>
<h3>Anatomy</h3>
<p>Domestic cats are similar in size to the other members of the genus Felis,
typically weighing between 4 and 5 kg.</p>
<h3>Physiology</h3>
<p>Cats are familiar and easily kept animals, and their physiology has been
particularly well studied.</p>
<h2>Behaviour</h2>
<p>Outdoor cats are active both day and night, although they tend to be slightly
more active at night.</p>4. Make sure that headings, links, form elements and landmarks can be understood without context
Blind people not only scan headings, but also links, form elements and so called “landmarks". A screen reader only reads out the information in the element itself, while it ignores its context. So, it is important that these elements themselves provide sufficient information.
<p>
This website uses cookies.
<a href="cookie-policy.html">More information</a>
</p>In the example above, the screen reader will say “Link: more information”. Without contextual information on the cookie notification, this is of no use to a blind user. “More information” on what? One way to solve this problem is shown in the next example.
<p>
This website uses cookies.
<a href="cookie-policy.html">More information <span class="sr-only">on our cookie policy</span></a>
</p>The sr-only class ensures that the text in the element is accessible for screen readers, but is invisible for seeing people. The screen reader now reads aloud the text “More information on our cookie policy.”
.sr-only {
position: absolute;
margin: -1px;
padding: 0;
width: 1px;
height: 1px;
overflow: hidden;
border: 0;
clip: rect(0 0 0 0);
}By using the sr-only class, a web page can provide extra contextual information to blind people, without having to adjust the visual design.
5. Describe non-textual information
Screen readers will skip all information that is not available in any textual form. For example, images, videos, audio and maps will be ignored. Best to make sure that this information is provided in another, textual way to the blind user.
<img src="cat.jpg" alt="African wildcat">The alt attribute is not the same as an image’s caption. The altattribute should describe what the image shows, within its context. A figcaption, when used in a figure element, could have any text regarding the image. It could be copyright information, or related information about our cat:
<figure>
<img src="cat.jpg" alt="African wildcat sleeping in the sun">
<figcaption>
African wildcats are active mainly during the night. Image rights: CC BY 2.0, John McExample.
</figcaption>
</figure>Note that an image that is only used for decoration doesn’t have to be described; you can keep the alt attribute of such an image empty, as it will only add noise to the blind user.
6. Make sure that visual feedback is also communicated using audio feedback
Web pages can provide visual feedback which screen readers cannot process. Examples of visual feedback are search results that automatically update when filtering, a twitter feed that updates itself or a menu that will show more options when hovered over. Blind users cannot perceive these kinds of feedback. By using a tiny ARIA role, we can add functionality that ensures the accessibility of such elements:
var div = document.createElement('div');
div.setAttribute('role', 'alert');
div.className = 'sr-only';
div.innerHTML = 'Loading new search results';
document.body.appendChild(div);Taking the example of loading new search results, you can notify the blind user using the ARIA role of alert. By adding a <div> containing a role="alert" to the web page when the user triggers new search results, the screen reader will announce: “Loading new search results”. Be careful to not overload the user with information, though!
7. Test the website in a screen reader
There are different kinds of screen readers for different operating systems. According to the WebAIM Screen Reader User Survey, popular screen readers for Windows are JAWS, ZoomText, Window-Eyes and NVDA. On MacOS there is only one screen reader available, VoiceOver, which is already built into the operating system.
Screen readers work in combination with a browser. Not every screen reader and browser combination interprets the web page in the same manner. For example, JAWS in combination with IE11 can give a different result than JAWS in combination with Firefox. The Paciello Group has documented the output of some popular screen readers for all kinds of HTML elements. HTML5 Accessibility lists the browser support of HTML5 accessibility features. Furthermore, as screen readers are expensive, their users will not update the software every time a new version comes out. This means that there are many possible combinations of browsers and screen readers, not all of which need extra care, but awareness of this issue will hopefully help you create better solutions.
Because the way blind people use a website is fundamentally different than the way sighted people can scan a web page, it is important to understand how screen readers work. I would suggest you to download a screen reader, turn off your screen and try it out. If you don’t give up out of frustration in the first few minutes, you will get a better picture of how to use them. If you don’t want to pony up: all screen readers have a trial mode, which is usually sufficient for testing a website on accessibility.
Using a screen reader to test your website during development might be inefficient. Instead, you can use the Chrome plugin ChromeVox. This plugin is a screen reader which runs in the browser. Yet, in my opinion it is important to once in a while test your website in an actual screen reader, in order to understand if your website is really accessible.
And, better yet:
8. Test the website with blind people
Usability testing together with blind users is the best way to check if your website is accessible. I could never have predicted how a blind person uses their computer with a screen reader until I experienced it first hand. And just like with those who have sight, everyone has their own methods and manners of using their computer. Quite simply put: if you only test a website’s accessibility yourself, you probably won’t find every issue. So, try to at least once sit down with one or more blind persons to visit your website together. In my experience, blind people are more than willing to help you with these tests. All you have to do is ask.
Learn more
In order to learn more about making accessible websites, I found the Web Accessibility course on Udacity useful.
Support for the ARIA standard is still not complete. PowerMapper (the Can I use of screen readers) has a list with ARIA roles and attribute support for different screen reader and browser combinations.
Wuhcag (www.wuhcag.com) has some good resources and explanations on WCAG 2.0 guidelines.
Heydon Pickering writes a lot about accessibility and made a couple of practical ARIA examples: heydonworks.com/practical_aria_examples/.
