amp-story: Controls/widgets with an incorrect/missing role

[TetraLogicalHelpdesk]

Controls/widgets with an incorrect/missing role

WCAG Level

Level A

Priority

Low

Pages/screens/components affected

• Navigation
• RTL
• Video
• Audio - amp-story background audio
• Audio - amp-story-page background audio
• Audio - amp-story using amp-audio
• Animation
• Sharing
• Tooltip
• Page attachment
• Branching
• Consent
• Prerender - Image
• Prerender - Video
• AMP Story Player - Player
• AMP Story Player - AMP Story 360

Description

A user interface component's role conveys to assistive technologies the purpose of the component. This, in turn, allows assistive technologies to give more accurate information to users about the nature of the content they are navigating.

Throughout the samples, the various types of modal dialogs/drawers/panels (conceptually all acting as modal dialogs) do not programmatically convey the fact that they are dialogs

User impact

When the role of a user interface component, such as a modal dialog, is not announced, assistive technology users won't be given important information about the component. In this case, while visually it may be fairly apparent that a component is a dialog (due to the semi-transparent overlay behind it, covering the underlying page), this information is not conveyed to assistive technology users.

Required solution

User interface components must expose a role that matches their actual purpose and functionality, so that assistive technologies can understand it and convey it appropriately to users.

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

The "Share" modal dialog currently has a role="alert". This will result in the content of the dialog being announced, but no indication will be given that this is in fact a modal dialog.

<div class="i-amphtml-story-share-menu-host">
  #shadow-root
    <div class="i-amphtml-story-share-menu ..." aria-hidden="false" role="alert" ...>
     ...
    </div>
</div>

The "bookend" drawer (when viewing small-screen/smartphone views of a story) and the "Swipe up" drawer/panel used in Page attachment all lack any kind of role.

<div class="i-amphtml-story-draggable-drawer">
  <div>
    #shadow-root
      ...
  </div>
</div>

The web-based/non-native consent dialog in Consent lacks any kind of role.

<amp-consent ...>
  ...
  <amp-story-consent ...>
    #shadow-root
      <div class="i-amphtml-story-consent i-amphtml-story-system-reset">
        ...
      </div>
  </amp-story-consent>
</amp-consent>

In all these cases, add an explicit role="dialog" to the interface component (and, in the case of the "Share" modal, remove the incorrect role="alert"). Additionally, we recommend adding aria-modal="true" to further clarify the nature of the dialog.

<div class="i-amphtml-story-share-menu-host" role="dialog" aria-modal="true">
  #shadow-root
    <div class="i-amphtml-story-share-menu ..." aria-hidden="false" ...>
     ...
    </div>
</div>

<div class="i-amphtml-story-draggable-drawer" role="dialog" aria-modal="true">
  <div>
    #shadow-root
      ...
  </div>
</div>

<amp-consent ... role="dialog" aria-modal="true">
  ...
  <amp-story-consent ...>
    #shadow-root
      <div class="i-amphtml-story-consent i-amphtml-story-system-reset">
        ...
      </div>
  </amp-story-consent>
</amp-consent>

Conceptually the "Expand Tweet" view in Tooltip also acts as a modal dialog.

However, in this case, the overall structure is slightly more complex to remediate, as it seems to rely on only visually giving the impression of a self-contained overlay, when in fact the embedded tweet is still part of the underlying page and is "shining through"/sitting on top of the actual "modal". We'd recommend dynamically restructuring the DOM in these cases to make the embedded tweet actually part of the container that appears as a modal, and then applying the role="dialog" aria-modal="true" to the container.

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. Trigger any modal dialog/drawer/panel
3. Verify that the control is announced as a "dialog" 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
• W3C - WAI-ARIA Authoring Practices 1.1

Test data

Test date: January 2021

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.