Accessibility researchers have been finding the same mistakes in web accessibility for years. In this article we share the most common issues and how to fix them.
The main web accessibility failures found by researchers over the years are:
- Insufficient contrast (of buttons, links, form elements, text colors etc.)
- A missing visible focus indicator when using keyboard navigation
- Images without a description (alt text)
- Links without text or with invalid references
- Link titles that are identical to the text
- Forms without labels (to explain what answer the form requires)
- Tables without headers or with faulty headers (‘th’)
- Using tables for layout instead of for data.
- Invalid or deprecated code
The following list presents a non exhaustive overview of Success Criteria of which repair seems feasible and that would have a high impact on web accessibility. Some of the items may be applied by content editors, others have a more technical nature.
Content related quick wins
- Use heading markup for headings. Usually, when web content editors wish to use a heading, they can select the heading text and then use a preset for headings in their CMS (e.g.: h1 – h6 or kop1, kop2). Assistive technology can recognize heading markup and announce that the text is a heading.
This helps people with disabilities understand a text. Using their assistive technology they can also navigate from heading to heading as a quick way to find content on a Web page (SC 1.3.1).
- Use list markup for lists. Usually, when web content editors wish to make a bulleted or numbered list, they can use a preset in their CMS. This is a button with bullets or numbers. Assistive technology can then announce that the text is a list (including the number of items and subitems etc.). Do not make your own lists using ‘-‘ or ‘*’ etc. without using list markup (SC 1.3.1).
- Add descriptions to images. By adding descriptions to images (like photos, charts, diagrams, audio, video, pictures, and animations), the content of the images can be read to persons with disabilities. This helps people who cannot see of read these images. Most CMS provide the option to add such a description (for images this is usually known as the ‘alt-attribute’). Note that some websites fail because they apply this Success Criterion the wrong way. (SC 1.1.1).
- Do not use ‘click here’ or ‘more’ for links. Give links a description that works when they are read out of context (SC2.4.4). Assistive technologies can provide the user with an overview of the links on a page to help them navigate more quickly and easily. Do not use “click here” for links.
- Make your PDF documents accessible from the start. Many seem to ignore the fact that office documents downloadable from a website are also covered by the accessibility standards (see section 2.1.1). There is much information about making office documents like PDF accessible online. For PDF this can mostly be done directly from Word, Open Office or using Adobe Acrobat Pro. The failures most found in PDF documents are the lack of page titles (SC 2.4.2) and the lack of language indication (SC 3.1.1). Both page titles and language of the page can be added using Adobe Acrobat Pro or directly in Open Office or Word).
Technology related quick wins
- Use labels. Use label or title elements to associate text labels with text fields and other form controls (SC 4.1.2). Assistive technology can use this to recognize and present the information to user.
- Use sufficient contrast. Make sure there is sufficient contrast on the Web page (this includes PDF and other office documents). Increase the contrast of text in error messages and of placeholder text in text (like for search and in forms). Also check the contrast of buttons and make sure the footer on the website has sufficient contrast (SC 1.4.3).
- Support resizing text. Make sure all the content on your Web pages is still perceivable when you resize the text up to 200 percent. Also check if text in text fields, labels etc. resizes (SC 1.4.4).
- Provide skip-links. Make sure you have skip-links on your Web pages to bypass blocks of content that are repeated on multiple pages (e.g.: navigation menus, advertising frames, etc.). Also check that the first skip-link is always to the main content of the page (SC 2.4.1). Note that it is not always visible and that on most Web pages the skiplinks only show if a user uses the tab key.
- Provide keyboard accessibility. Make sure that all elements on your Web pages and documents can be reached and operated using the keyboard (SC 2.1.1). You can test this by using the tab key and the space bar (or enter).
- Provide a visible focus. The focus should be visible when you tab through a Web page (SC 2.4.7). Make sure this also works with menu items, text fields, buttons, etc. Also check if the order is correct (SC 2.4.3)
- Explain what goes wrong in a form. If a user makes an error in a form, the feedback should be a text that tells them (1) that an error has occurred and (2) where it can be found (SC 3.3.1). This saves a person who is blind from having to go through the complete form again. If desired, this can be combined with other signals like use of color or an asterix.
- Make your hamburger menu accessible. Many hamburger menus are not accessible using only a keyboard (SC 2.1.1). To test this, one can use the ‘tab-key’ to tab through the menu. While trying out if this works, one can also check if there is a visible focus (SC 2.4.7). Many hamburger menus miss the indication of the status (open/closed) (SC 4.1.2).
This article is an excerpt from The Implementation of Web Accessibility Standards by Dutch Municipalities. Factors of Resistance and Support, a thesis by Eric Velleman.