TPGi’s accessibility experts have been busy this year, identifying thousands of accessibility errors through manual and automated testing. From all those results, the following 10 issues were the most commonly found by our ARC automation tools. We hope this list helps guide your team to avoid some of this year’s most common barriers. Cheers to another year of making things accessible!
1. No link text
<a> element is HTML’s way of specifying links to other web pages, or locations within the same webpage, providing the foundation for the web’s purpose as a connected set of pages. But developers sometimes use the
<a> element to provide other interactive functionality, and often this is done in a way that omits any link text. The result is that assistive technologies such as screen readers have no way to communicate the purpose of the link, leaving users unsure what will happen when they follow the link. That’s why every link must communicate its purpose in an accessible way.
2. Non-active element in tab order
This error occurs when a non-interactive element has been placed in the tab order using
tabindex="0", which means it becomes focusable using the keyboard when it doesn’t need to be, reducing efficiency and increasing effort for keyboard users. Generally, only elements that are interactive, such as links, buttons and form input fields, should be included in focus order. Screen reader users have access to a wide range of additional keyboard commands to allow quick navigation through content, so there’s no need to include static text and images in the focus order. Edit: In fact, all users who rely on keyboard navigation are negatively affected by this common error.
3. Missing link alt attribute
Closely related to item #1 in our list, often links are labeled with an icon or other graphic that visually indicates the purpose of the link. A common error is to provide this graphic without any text alternative. When an image link has no alternative text, assistive technology users will be unaware of the link’s purpose. For that reason, it’s essential to provide alternative text for image links, that describes the purpose of the link.
4. No alt text
Related to item #3, an image’s alternative text, provides a text description of the image content. When an
<img> element lacks a text alternative, screen reader users have no way of knowing what the image is for. Providing a text alternative that communicates the same information as the image is one of the most fundamental accessibility requirements; but exactly what the alternative text should be would depend on the image’s purpose.
5. List not nested correctly
Using markup to identify lists helps communicate the structure of page content in an accessible way. When a list item has a nested list, it’s important to use markup in the correct way to make the nesting relationships clear. This helps avoid confusion when the list structure is described by screen readers.
6. Duplicate labels used
Another accessibility issue commonly detected by automated tools is form fields that have multiple identical labels. Having more than one label with exactly the same text can make it harder for some users to understand the form’s structure, and decide what content to enter in a particular field, increasing the chances of input errors. If your form has multiple labels with the same text, that’s a sign you might want to reconsider the design of the form or change the labeling of each input field.
7. Positive tabindex value
tabindex attribute is a way to control which elements on a web page receive keyboard focus. In the past, developers would use different values of
tabindex to try to control the focus order through a page. However, this approach is very brittle and difficult to maintain, and today, the only values of the
tabindex attribute that should be used are either
0 (see item #2 in this list for more on that topic) or, in specific situations where focus is managed using scripting,
-1. To optimize keyboard usability, don’t try to control focus order using positive
8. Invalid aria-describedby
Sometimes, a control may need a description as well as a label, when users might need to know more details about the state or purpose of the control. The
aria-describedby attribute can be used to provide a connection between a control and some descriptive text elsewhere on the page. But the ID value defined by
aria-describedby must match an element on the page with the same ID, otherwise the connection between those elements will not be conveyed by assistive technologies.
9. No label for button element
Similar to links without link text (item #1), a button without an accessible label does not convey its purpose to assistive technology users. Unfortunately, many buttons are implemented in a way that relies on visual icons, which means the user has to be able to see that icon in order to understand the button’s purpose. To avoid this problem, provide each control with an accessible label that clearly communicates its purpose to assistive technologies.
10. Invalid aria-labelledby
Very similar to item #8 on this list, in specific situations a control may be provided with an accessible label by connecting the control to some text elsewhere on a page. The
aria-labelledby attribute can provide this connection, but it needs to correctly reference the text element’s ID, otherwise the connection between the control and its label is lost to assistive technology users.