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
The <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.
Learn more about writing meaningful link text.
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.
Learn more about keyboard interaction.
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.
Learn more about all things ‘alt’.
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.
Learn about the five golden rules of compliant alt text.
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.
Learn more about HTML lists as a way to structure content.
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.
Learn more about accessibility and labeling.
7. Positive tabindex value
The 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 tabindex values.
Learn more about using the tabindex attribute.
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.
Learn more about using ARIA attributes for labels and descriptions.
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.
Learn more about label use in WCAG.
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.
Comments
You write: “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.” There are sighted users though, that don’t use screenreaders but can’t use a mouse. Although even for them it usually is bad if non interactive elements can get the focus, wording like this leads to keyboard use is for screenreader usesrs only – which for many people equals with blind people. Although accessibility experts know, that this is false, the way that we talk about things encourages this kind of thinking. So we should use more general examples. In this case maybe: People that don’t use a mouse need an efficient way to reach interactive elements. Especially when a user interface is designed with mouse users in mind, keyboard users already often need more time to interact with a webpage. So they should not have to deal with useless tab stops, that will slow them down even more. – In a summary: design the keyboard experience in a way, that you as a website owner or developer actually want to use your own page without a mouse.”
Thanks, Marc, you’re right – the placement of that sentence could imply that keyboard navigation is only relevant to screen reader users, which we know is not the case. I’ve added a clarifying sentence.
I would love it if these issues could have an impact rating. I can see that having a non-active element in tab order would be annoying, but missing labels on A or Button tags can block the user from interacting with the website completly.