web-components icon indicating copy to clipboard operation
web-components copied to clipboard

details: Expanded/collapsed state not exposed in Chrome + NVDA

Open TetraLogicalHelpdesk opened this issue 3 years ago • 1 comments

WCAG Level

Level A

Priority

Medium

Pages/screens/components affected

Description

When the state of a control is not robustly exposed it can be difficult or impossible for screen reader users to use. While the expanded or collapsed state of the Details component is correctly provided by the aria-expanded attribute and generally works as expected, in Google Chrome and NVDA this state is only communicated when the element with role="button is first focussed. When the state of the Details component is toggled, from expanded to collapsed or vice versa, NVDA remains silent.

The basic example of the Details component in its expanded state

As with other components, although the <vaadin-details> has a tabindex="0" attribute and is therefore keyboard focusable, it is actually the <div role="button"> that receives focus.

<vaadin-details tabindex="0" opened="">

  # shadow-root
  <div role="heading">
    <div role="button" part="summary" aria-expanded="false" tabindex="0">
      <span part="toggle"></span>
      <span part="summary-content"><slot name="summary"></slot></span>
    </div>
  </div>

  <div part="content" aria-hidden="true" style="max-height: 0px;">
    <slot></slot>
  </div>
  # end shadow-root

  <div slot="summary">Contact information</div>

  <vaadin-vertical-layout>
    <span>Sophia Williams</span>
    <span>[email protected]</span>
    <span>(501) 555-9128</span>
  </vaadin-vertical-layout>
</vaadin-details>

As this only affects a single browser and screen reader combination that the component was tested in it's somewhat difficult to diagnose. It appears to be a problem with focus management. When the control is toggled, the expected behaviour is for focus to remain on the control. The status will be announced and the user can continue to expand and collapse the component without moving focus back. This is generally the case, but for Google with NVDA running I attempted to discover which element the browser was recording as having focus using document.activeElement. Before toggling the control, the reported activeElement is details-basic-imported. That this is not the <div role="button"> element is, I believe, a limitation of Chrome's developer tools console when interrogating shadow DOM elements. After toggling the control, the reported activeElement is div#gatsby-focus-wrapper, i.e. the content container that is unrelated to the Details component. Usually when this happens it is due to the browser losing track of focus so it sets it to be somewhere. It still being possible to toggle the control without moving focus back to the <div role="button"> and the previous and next focusable elements being as expected is odd, which indicates something unusual happening with the tracking of focus.

This should be investigated further, specifically checking that focus is not being changed or unset after an interaction. If focus remains on the control at the time that the aria-expanded attribute is toggled between true and false the change should be announced. In the past NVDA has had problems with announcing changes in aria-expanded but these have been resolved and shouldn't apply here.

User impact

When an assistive technology does not announce changes in aria-expanded or similar attributes, screen reader users will not be made aware of the change in the UI, i.e. understanding that the component is expanded or collapsed. While it is possible to remove focus then return focus and have the state announced, this is an inconvenience and a failure of WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A) which requires that changes in state are programmatically exposed.

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 (using Tab/Shift+Tab to move to all controls that can be toggled
  3. Make sure the current state of the control is announced when first focused
  4. Toggle the state of the control, from collapsed to expanded, unchecked to checked, etc.
  5. Make sure that the changes in state are announced 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 components, their variants, and the documentation website have been tested for the same issue.
  • All issues identified throughout the rest of the components/website have been resolved or filed as new issues.

Related standards

Test data

Test date: March 2021 Website: vaadin.com/components, vaadin.com/docs-beta

TetraLogicalHelpdesk avatar Mar 17 '21 13:03 TetraLogicalHelpdesk

Before toggling the control, the reported activeElement is details-basic-imported. That this is not the

element is, I believe, a limitation of Chrome's developer tools console when interrogating shadow DOM elements

If the focused element is inside a Web Component, document.activeElement reports the Web Component itself. If you want inspect deeper, to see the element focused within the Web Component, you should use theFocusedWebComponent.shadowRoot.activeElement.

I tried this and the focused element doesn't change while toggling. The expanded state change is also announced occasionally, but for some reason not every time. Kind of feels like an issue with NVDA.

tomivirkki avatar Apr 27 '21 10:04 tomivirkki