Examples: amp-accordion: Hidden "Show more" buttons remain focusable, lack accessible name

[TetraLogicalHelpdesk]

WCAG Level

Level A, AA

Priority

High

Type

Interaction, Structure

Pages/screens/components affected

• amp-accordion

Description

For people who navigate using a keyboard or keyboard-like device (such as a switch control or a joystick), the focus order of interactive controls in a document should be logical and intuitive.

The amp-accordion example and the hidden header example both contain a "Show more" control which disappears after being activated. However, due to the way in which the control is hidden, it remains keyboard-focusable. This leads to an unnecessary tab stop when the control is hidden, as well as resulting in the visible focus indication "disappearing" (as focus goes to a now invisible element). In addition, due to the way the control is hidden, it also lacks an accessible name once hidden.

User impact

Duplicate/unnecessary tab stops are likely to cause irritation for keyboard-only users when they are navigating through the page. When the elements that receive focus are not visible, this can add further confusion, as no visible focus indication is presented.

Assistive technology users may not realize that the element that receives focus is currently unavailable/inactive, and will be confused when trying to activate it.

Additionally, since the "Show more" control, once hidden, also lacks an accessible name, it will only be announced as an unlabeled generic "button", giving no further indication about its purpose to users of assistive technologies.

Required solution

When an element is visually hidden (because it is inactive/inoperable), it must not receive focus. In this case, if the intention is to completely remove the control, it should be fully removed from the document (by removing the element from the DOM) or styled using display:none, which has the effect of removing/hiding the element completely from assistive technologies and making it non-focusable by keyboard 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

When the control is hidden, its inner <span> element is hidden with display:none. However, the focusable outer element (currently, a heading that has been given a role="button" and made focusable with tabindex="0") remains in the document - and now lacks any content or any alternative way of providing an accessible name, leading to it simply being announced as "button".

<h4 class="i-amphtml-accordion-header" role="button" aria-controls="..." aria-expanded="true" tabindex="0">
  <span class="show-more">Show more</span>
</h4>

amp-accordion section[expanded] .show-more {
  display: none;
}

As noted in a separate issue, we generally recommend not changing the <h4> headings into buttons directly, but rather keeping those headings and instead injecting/generating a <button> inside them, in order to maintain an appropriate structure - though in this case, "Show more" is not necessarily an appropriate/descriptive heading.

In this specific example/circumstance, we would however recommend hiding not just the inner <span>, but the entire heading/control altogether.

amp-accordion section[expanded] {
  display: none;
}

However, if the user's focus is currently on the "Show more" control, removing it this way will result in the focus being "lost". In cases where focus is lost (generally caused by the element that previously had focus being disabled or removed from the page), some browsers may error-correct and attempt to relocate the user's focus to the nearest focusable element, or they may simply reset the focus to the start of the document. Overall, it will likely make the user's experience of navigating the page unnecessarily tedious and confusing. To avoid this, we recommend programmatically setting focus to the newly shown content panel that appeared as a result of activating the control. To set focus to a static element, which does not ordinarily receive focus, add tabindex="-1" to the element - this will then allow the element to be focused using the standard .focus() JavaScript method. In this case, we recommend adding the tabindex attribute dynamically, as part of the accordion's scripting (rather than expecting authors to add this themselves).

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. Navigate through the page using the Tab key.
2. Activate any expand accordion controls.
3. If the control disappears after the panel/accordion was opened, verify that it does not still receive focus.

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 rest of the website have been resolved or filed as new issues.

Related standards

• WCAG 2.1 Success Criterion 2.4.3 Focus Order (Level A)
• WCAG 2.1 Success Criterion 2.4.7 Focus Visible (Level AA)
• WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A)

Test data

Test date: November 2020

[stale]

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.

[stale]

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.