Accessibility concerns in an HTML-CSS-JavaScript interactive tree-graph

Question

The structure is as follows:

<button>Button 1</button>
<button>Button 2</button>
<button>Button 3</button>

<figure>
  <ul>
    <li>Item 1
    <li>Item 2
    <li>Item 3

    <li>
      <ul>
        <li>Item 4
        <li>Item 5
        <li>Item 6
      </ul>
    </li>
  </ul>
   
  <figcaption>Tree-graph</figcaption>
</figure>

Depending on which button is clicked, certain li elements would be hidden.

If I hide those lis with CSS display: none, would there be any implications from the perspective of accessibility softwares? That is, would it still be interactive just as it is visually?

Or, would I have to use some WAI-ARIA attributes?

If I hide those lis visually only (such as with the Bootstrap sr-only class), then, from the perspective of accessibility softwares, those buttons aren't doing anything; in which case, I might, as well, hide those buttons with aria-hidden="true"!

brennanyoung · Answer 1 · 2021-08-27T12:23:56.660

This is an interesting one. It appears to be an exotic kind of tree view.

First, please take a look at the tree view pattern described at https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView ... Ask yourself why the opening and closing in your design is handled by separate buttons, an approach which will almost certainly require some live region announcements about the tree state, whereas the w3 treeview pattern integrates the presentation (and AT announcements) of the view with the operable parts.

I'd suggest using html5 hidden attribute to do the hiding, but display:none; is also fine (a rare case where CSS affects the accessibility tree). Don't use sr-only here

If keeping the buttons separate from the tree view is an absolutely fixed requirement, I might lean towards grouping the buttons with the 'tree' inside a wrapper with role="application". You can use aria-roledescription to give the widget a more appropriate, domain-specific semantic name than "application", but please take great care in your choice, so that you raise appropriate expectations.

You might need to offer a brief instruction or other guidance for how the thing is going to behave, although carefully chosen button labels might do that job quite acceptably.

If you make the tree itself (the outermost <ul>) a live region, you might play around with aria-relevant and aria-atomic (see https://www.w3.org/TR/wai-aria-1.2/#attrs_liveregions) so that changes to the tree are announced as you click the buttons. This might work out just fine, although I recommend testing on a range of platforms and ATs.

You should associate the buttons clearly with the tree elements that they control, at least via the button labels.

The intended programmatic mechanism for making that association, aria-controls has limited real benefits for end users, but according to the spec, it should be on your buttons, and the value for this attribute should be the id of the tree item element(s) affected by that button.

You will need aria-expanded, on the buttons, to describe the state of the tree element they control. The state of this attribute will be announced as the button gets focused. Many ATs will also announce it when it changes - i.e. when you click the button.

Interesting case. Good luck with it!

Accessibility concerns in an HTML-CSS-JavaScript interactive tree-graph

1 Answers1