WCAG Level

Level A

Priority

High

Type

Semantics

Pages/screens/components affected

• amp-sidebar

Description

A control's role conveys to assistive technologies the purpose - and expected interaction or effect - of the control. Its state represents a particular characteristic of the component in response to an action or process.

Currently, the amp-sidebar element exposes a role="menu", which does not correctly reflect its actual content and purpose - which is more akin to a modal dialog.

User impact

When the role of a control doesn't match its actual purpose, assistive technology users may not know how to interact with the control, or may be surprised if the effect of a control doesn't match the expectation set by its role.

In the case of a role="menu" element, the user expectation is generally that the element is structured, and behaves, like a native applications menu - providing a list of options/commands that can be navigated using cursor keys. This is currently not the case for amp-sidebar, which can have a wide range of content, structures and controls that don't necessarily match the rigid structure of a traditional menu.

Required solution

Controls must expose a role that matches their actual purpose and functionality. If the controls have different states (e.g. pressed, selected, disabled, invalid), this state must be conveyed in an unambiguous/programmatic way, so that assistive technologies can understand it and convey it appropriately to users.

In the case of amp-sidebar, currently the generated markup includes the incorrect role="menu".

<amp-sidebar ... role="menu" ...>
  ...
</amp-sidebar>

Rather than identifying the sidebar as a menu (see WAI-ARIA Authoring Practices 1.2 - Menu or Menu bar), it should instead be identified as a dialog, as the component's appearance and behaviour are more in line with how a modal dialog operates (see WAI-ARIA Authoring Practices 1.2 - Dialog (Modal)).

<amp-sidebar ... role="dialog" aria-modal="true" ...>
  ...
</amp-sidebar>

Note: Modal dialogs require specific focus handling - moving focus to the dialog when it is opened, maintaining focus inside the dialog, returning focus to the control that originally opened the dialog once it's closed. These are already correctly implemented in amp-sidebar.

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.

Test procedure(s)

Use these steps to confirm that the solution has been correctly applied to issues identified within the test sample, and to test the rest of the website for instances of the same issue:

1. Turn on your screen reader.
2. Navigate through all controls on the page.
3. In the case of interactive controls (such as toggles, form controls, etc.), interact with the control.
4. Verify that the control is announced with its correct role, and that its state - and any change to the state - is correctly conveyed by the screen reader.

Definition of done

Complete all of these tasks before closing this issue or indicating it is ready for retest:

• All issues identified within the test sample have been resolved.
• The rest of the website has been tested for the same issue.
• All issues identified throughout the website have been resolved or filed as new issues.

Related standards

• WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A)

More information

• W3C - Understanding Success Criterion 4.1.2 Name, Role, Value
• W3C - ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
• W3C - WAI-ARIA Overview
• WAI-ARIA Authoring Practices 1.2 - Menu or Menu bar
• WAI-ARIA Authoring Practices 1.2 - Dialog (Modal)

Test data

Test date: November 2020