The following accessibility topics were identified from a11y issues discovered by an independent audit of the aa.com production site. While the specific a11y issues discovered by such audits are addressed through separate enhancement efforts, we capture these highlights here so teams can learn what to watch for as they enhance and add features to their own projects. The ultimate goal is these lessons learned will help us release features with zero accessibility issues in the future.
Duplicate ID errors are known to cause problems for assistive technologies when they are trying to interact with content. Therefore it is critical you insure there are no duplicate ids present in the DOM. Having two elements with the same ID even if only one is visible in the browser is not sufficient. There should be no duplicate ids in the entire DOM, visible or not.
Hyperlink tags should only be used if the user is going to be redirected to another page or another location within the same page. This includes links that open new browser windows, as those are considered redirections as well. In the case of single page applications, if the link were associated with a specific URL or route that will generate a new view, then a link would be appropriate. They should not be used to trigger dynamic actions or to submit forms.
Button tags (including input type=“button/submit”) should be used when triggering some dynamic action (opening a dialog, expanding a hidden panel, revealing a tooltip, etc.) or submitting a form. They should never be used to redirect users to another page or location in the same page. It is also important that the button describes its purpose to assistive technologies such as opening a popup/dialog, expanding/revealing some content as well as convey its current state (i.e.: a button used to expand or collapse a panel of content would convey whether the panel is currently expanded or collapsed).
Headings (h1-h6) facilitate navigation and understanding of overall document structure for users of assistive technologies. Therefore, you should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.). Also you should not skip heading levels (e.g., h1 followed by h2 followed by h4) just to achieve a particular visual effect, that’s what CSS is for.
Heading text should also be meaningful and concise. This is because many assistive technologies will construct navigational aids using the heading text. Users of assistive technologies can struggle if heading text is too long or doesn’t adequately describe the content for which it is a heading.
In addition, headings should avoid text strings that also contain hyperlinks or actionable elements. Doing so can interfere with how assistive technologies convey the meaning of the heading when the heading receives focus. For example, don’t include a tooltip button at the end of heading nested inside the <hX> tags. Instead, code the button outside the heading tags and use CSS to position the tooltip button appropriately for the desired visual design. An example where an actionable element may be allowed nested inside a heading would be for a trigger for an expander. In this case the entire heading text could be nested inside the button element that serves as the trigger to expand/collapse the dynamic content.
If a component provides special keyboard interactions (i.e.: use of arrow keys or page-up/page-down, etc.) instructions should be provided such that keyboard-only users, both sighted and non-sighted, can quickly and easily understand how to use the component.
Some users with vision issues may increase the size of the text on the page either by zooming the page or resizing the text. Zooming will rescale the entire page and present both vertical and horizontal scroll bars to allow the user to access the entire content. Text-only resizing will just resize the text without rescaling the page. This typically results in no horizontal scrolling.
We need to support text-only resizing up to 200% without loss of content or functionality with no overlapping text. Therefore, it is important to not set max-heights or pixel specific sizes on containers. Use min-height and percentage based sizes (i.e.: %, em, rem) so the containers can expand as text size increases and words wrap to new lines.
For some problematic layouts it may also require the use of word-break: break-word; to allow long words to break onto multiple lines.
Avoid images with text embedded in the graphic as the text can’t be resized by the end user without zooming the entire page and color contrast issues can occur depending on the underlying graphic. A more accessible approach would be containing the text in elements separate from the image so they can be resized as needed.
Be mindful that very long text strings inside buttons and hyperlinks are challenging for users of Assistive Technologies like screen readers. While it is important for the user to understand the context and purpose of the link or button, it can be overwhelming if we are relying on very long and rambling labeling to convey that context or purpose. It may be better to keep the labeling concise and employ coding techniques to programmatically associate the context messaging so the user can easily discover it should the labeling not provide enough details.
Do not include any text that describes the component itself that is already being conveyed to the user by assistive technologies. (Example: don’t add text that says, “link opens a new window” to a hyperlink as screen readers will already convey that the element is a link. “Opens a new window” would be sufficient and preferred).
Avoid redundancy where possible. If a link or button contains text that has some repeating messaging, try to limit what is exposed to assistive technologies so users aren’t overpowered with overly verbose, redundant text.
Since landmarks are used as navigation in some assistive technologies, applying a label to the landmark element can help convey exactly what the landmark contains. This is especially helpful if there are multiple navigation elements (<nav>) on the page as the added label will provide the distinction. Use of the aria-label attribute to provide the label text can help with this.wal