WCAG Level

Level A

Priority

Low

Type

Images, Semantics

Pages/screens/components affected

• amp-inline-gallery

Description

When images do not have a text description, it means anyone who cannot see images properly will not know what the images are for. If the images act as actual controls (such as image-based buttons or links), this leads to the controls also lacking an accessible name, and in the case of links, links without any link purpose. Without an accessible name, interactive controls will simply be announced as the generic "link", "button" or similar by assistive technologies.

In the amp-inline-gallery pagination and thumbnails Glitch the thumbnails and their previous next controls are wrapped in an aria-hidden="true" container. As a result, they receive keyboard focus but no accessible name nor role is announced by assistive technologies.

<amp-base-carousel ... aria-hidden="true" ... >
  ...
</amp-base-carousel>

User impact

When navigating through the page (for instance, using Tab / Shift + Tab to move from one focusable element to the next), assistive technology users will land on the previous/next controls. However, since these controls lack both a role and an accessible name, they will be announced simply as blank/empty tab stops. The controls may further - depending on the specific assistive technology - be announced as "clickable", as there is associated JavaScript behavior tied to these controls.

While these controls serve no practical purpose to blind screen reader users, and may only be perceived as a redundant tab stop, this may be confusing for (partially or fully) sighted assistive technology users, who will be able to see the controls but not hear them announced.

Required solution

Graphical controls must be given an accessible name. There are various ways to achieve this. For controls that contain an <img> element, one option is to provide an appropriate alt="..." attribute for the image. Alternatively, accessible names can be provided by adding aria-label="..." or aria-labelledby="..." to the control itself.

As a general rule, do not add aria-hidden="true" to containers that have focusable child elements - see also Using ARIA - Fourth Rule of ARIA Use.

This solution must be applied to all instances of the issue identified within the test sample, then applied to all other instances of the same issue identified throughout the rest of the website.

Implementation guidance

Remove the aria-hidden="true" from the carousel for the thumbnails.

As an aside, we note that this carousel also has a conditional logic that only shows the controls when (pointer:fine).

<amp-base-carousel ... controls="(pointer: fine) always, never" ... >

If the intention here is to only ever show controls on "desktop" and not on touch devices, note that there are situations where even on a nominally "touch-only" device like a smartphone or tablet, users may have additional inputs such as paired Bluetooth mice or keyboards. For this reason, we recommend removing the conditional logic here and to always show controls regardless. See also CSS-Tricks: Interaction Media Features and Their Potential (for Incorrect Assumptions).

Test procedure(s)

Use these steps to confirm that the solution has been correctly applied:

1. Turn on your screen reader
2. Navigate through all controls (using Tab/Shift+Tab to move to all focusable elements)
3. Make sure that controls are announced with an actual name and role (e.g. "Delete, button") rather than just as generic nameless controls (e.g. "button", "link"), or as "blank"/empty tab stop.

Related standards

• WCAG 2.1 Success Criterion 1.1.1 Non-text Content (Level A)
• WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A)

More information

• W3C Accessible Name and Description Computation 1.1
• W3C: Image concepts
• W3C: An alt decision tree
• W3C: HTML 5.2 Requirements for providing text to act as an alternative for images

Test data

Test date: November 2020