Web accessibility has gained momentum recently, both due to governmental policy and also recent additions to the HTML 5 specification. Yet, when web developers create websites, there are many misconceptions regarding how content is presented for users with disabilities. This article presents some of the most common mistakes that are made, and possible ways for web developers to spot them and then solve them.
The best way to spot accessibility errors, is simply to test for them! Just like software should undergo testing before release, so should web pages. And if you're testing browser compatibility anyway, it's no harder to test the accessibility of your web pages. The important thing to remember, is to use the proper tools for the job.
Using a screen reader for testing may seem like a daunting task, but you can't make an omelet without breaking any eggs. By the same logic, you can't claim that you've tested your web site for accessibility properly, unless you've actually navigated your web site with a screen reader. Thankfully, just like there are a small number of browsers that form a canonical testing suite, there is a similar selection of screen readers that should cover the majority of your user base:
- JAWS (Windows, ~50% market share. 40-minute testing mode after each fresh Windows boot.)
- NonVisual Desktop Access (NVDA) (Windows, ~15% market share. Free software, and with helpful guides at WebAIM.org )
- VoiceOver (Mac OS X, iOS, ~9% market share. Comes pre-installed on every modern Mac.)
- WebAnywhere (Web-based, unknown market share. Open source.)
WebAIM.org is a wonderful resource if you need help with web accessibility. In addition to a plethora of well-written articles and tutorials, they also provide WAVE, a nice visual evaluation tool. There are two versions: One web version and also the Firefox toolbar .
Here are some of the features you get with WAVE:
- Visual overview of features, warnings and errors.
- Text-only view (showing the real document reading order)
- Outline view (heading structure)
- Helps you win arguments with Management about spending time fixing accessibility errors!
Go ahead and give it a try yourself. Do not dare continue reading this article, until you've tested a site with WAVE !
Page has twenty-one headings and one hundred eleven links articles dash Enonic Labs dash Internet Explorer Link Graphic Enonic LABS List of two items bullet Link articles bullet Link about List end Link Graphic…
Are you getting dizzy from the text above? Good, because that's how many visually impaired users experience web pages. It's the kind of text that is read to you by a screen reader, starting at the beginning of a web page. There is a Firefox Add-on called Fangs which basically robs web developers of their vision, and helps them identify with how the visually impaired read a web page. It does so by emulating the text output of the JAWS screen reader.
In Fangs, you can choose between:
- Reading all items on the page
- Reading all headings
- Reading all links
The three reading modes that Fangs provide, are all very common ways to read web pages with a screen reader.
All the three reading modes that Fangs provide are commons ways that the visually impaired have web pages read to them. If users want to proceed carefully, they may have the whole page read to them. But don't forget that there are just as many impatient visually impaired users as there is impatient users in the rest of the population! Therefore, when forming the HTML, take into account that some users would also prefer to have shortcuts that allows them to skip content, and that all headings, links and image alternative texts should be short and concise.
What is the difference between Fangs and the Text-only view in WAVE? With the Text-only view in WAVE, you still may read the page in a non-linear fashion. Your eyes give you visual context, in which you can easily spot headings, paragraphs, and other visual cues that help you read the web page. This is not consistent with how screen readers force the user into a linear reading order.
Just like we all costomize our computer applications to a degree, so do users of screen readers.
One of the most dominant differences between screen readers and visual navigation, is the linear vs. non-linear reading order. When we read a web page with our eyes, we glance quickly at pieces of the page here and there, gradually piecing together the context and determining what to focus our attention on. But when navigating a web page using a screen reader, each element on the page is read in chronological order.
How to spot: Is the page showing hidden content, either on mouseover, by following same-page-links, or other similar types of interaction?
How to spot: Use the tab key, and see if you can follow the changes! Browsers usually have a setting that enables the use of navigating with the tab key, either directly or by holding down a modifier key. To trigger a click event on a focused item, space or enter is usually the norm.
In HTML earlier than version 5, you could create anchors that pointed to anchor targets, such as these:
In HTML 5 however, the name attribute is no longer valid, and you must point to an element by its id attribute value instead. The problem is that only certain types of items are focusable by default. So when an anchor is followed to a non-focusable item, the browser shifts the viewport to the item, but the focus remains on the link that was clicked .
Focusable items by default are links, images, and form elements (and possibly more, depending on the browser)
To make a non-focusable item focusable, you can put the item into the tab order with the tabindex attribute. If the value is set to non-negative integer, the item goes into the tab order, which is useful – sometimes . If you on the other hand need the item to follow the order of the regular text flow, use a negative integer such as "-1".
Make sure that you have styled the :focus pseudo-class in CSS for all focusable elements, especially links. It is conventional practice to use the "outline: 1px dotted black;" style.
Screen readers use markup to gain a sense of the semantics and structure of a web page. For instance, when you use an ordered list around a block of text, the screen reader recognizes this HTML element and switches to a specific reading behavior: Stating that this is an ordered list, stating the number of items in the list, and then labeling each item in the list with a specific number. When used correctly, proper semantic markup can be very beneficial to users of assistive technologies. But when used incorrectly, it may result in a lot of confusion.
How to spot: Most commonly seen in situations when the visual design looks like a well-known item, but behaves like another.
We've all done this at least once, haven't we? Marking text as bold instead of as a heading, or using headings because a line of text should look bold. This can lead to an inconsistent heading structure on the page, either too few headings, or too many and spread around in strange places. Users who rely on screen readers often make the screen reader list the headings on a page consecutively, so it is important to have a sensible and consistent heading structure on each page.
Tip: The page (as an article) should have a h1 heading. Every section (groupings of content) should have a h2 heading, and every
article in lists should have a h3 heading (or lower, if multiple groupings are present). Navigational and interactive elements
do not need headings, as they have their own markup that is better suited (<nav role="menu">, <form role="search">, <fieldset><legend>…).
In the end, these rules may be broken from site to site, but it should be consistent within a single site.
Tip: If a section doesn't have a heading, add a descriptive heading of your own, and hide it using CSS. If you use "position: absolute" to move it outside the screen, and not "display: none" or "visibility: hidden", the screen reader will still read the element to the users who depend on it.
Our eyes prefer reading patterns based on straight lines. As a result, many content lists are designed to look like tables. Don't give in to the temptation!
Limit the use HTML tables to when the user needs to compare data across entries. For instance, in a list of employees where you can sort employees based on their department, a table can be smart to use because then the screen reader can navigate to the "department" header cell, and then start listing the titles of each of the respective employee entries. But in a list of news articles with publishing dates, a table structure would just add unneccessary markup, unless the main interactivity feature of that section is to be able to navigate to a data type and find a listing based on a specific criteria.
Do not use tables if data in a row or column suddenly switches to a different data type, such as having a "gender" column that in the bottom half of the table. At the very least, use different tables that are labeled correctly. Which brings us to:
When using tables, make sure to use th header cells for both columns and rows, properly marked using the scope attribute. And if the row header cells are not in the first column, use a system of header and id attributes, as described in this article at Webaim.org .
In one instance, a call-to-action link to another page may be designed to look like a button. Or you could have a search filter, with a "reset filter" link that reloads the page
Tip: Use links when moving to a different page, or when the page must be reloaded, or when skipping to a different part of the
same page without reloading
Tip: Use buttons when perfoming an action on the page, such as removing a filter or changing sort order
We've only scratched the surface of what can be done in order to improve accessibility on a site, but by following the simple steps outlined above, many web sites should become more accessible than they are today. Hopefully as more and more public sites become more accessible due to governmental regulations, this will also have a positive effect on web developers, in the sense that there will be more focus on designing accessible web sites.