Revisit a11y affordances of List View nodes

[getdave]

It appears that the components within the <td> for nodes in the offcanvas experiment are aria-hidden. Does this make the node always hidden to screen readers?

I seem to remember that this may also be true for the main list view because otherwise screen readers will announce each node on navigating between them which is annoying.

@talldan Can you remember about this and whether we need to do anything to improve it?

[talldan]

IIRC it was added to List View to prevent NVDA and JAWS from switching modes. I wasn't all that involved in the change, I think @alexstine and @andrewserong know more about it.

[alexstine]

It was added to get around mode switching and list view select oddness. Might be time to remove it now though since list view has better markup with the application role. I may make a PR if I ever get enough time.

[getdave]

So to confirm we need a PR to remove the aria-hidden from the nodes?

[alexstine]

@getdave Probably time to do that now. Also likely need to remove some other attributes from the tr tag. It will take some work. Lots of testing with different screen readers as well. We worked around this before by hacking the heck out of it, that is what you currently see. Although aria-hidden is applied to the link, aria-label on the tr is still allowing it to be read. I think that is how we did it.

@andrewserong might be best to unravel this since he implemented it. I think it is worth testing without the aria-hidden now that the list view itself is in better accessibility shape. We'll need to test block selection carefully. That is what brought on all these changes.

Thanks.

[andrewserong]

As far as I can remember, the aria-hidden we added was for the Button component that renders the a tag, to prevent the link from being announced twice, as well as helping ensure that NVDA didn't unintentionally switch modes while navigating. So I think that means the cell itself, which is a level up, shouldn't be hidden, and other elements that should be available to a screen reader could be added as a sibling to the block select button, rather than inside it?

As Alex mentions, though, things might have moved around a bit since we last added that in. My main recommendation is that if you're going to try removing it, be sure to test with a screen reader to make sure that it doesn't add back in more redundant announcements as elements are focused or navigated to.

[alexstine]

The mode switching should be a non-issue now with the whole grid wrapped in a role="application". Others are still valid test cases though.

[talldan]

I gave List View (and the off canvas editor) a test using Voiceover today and noticed it's not working as expected.

The aria descriptions for items don't seem to be announced. Blocks are announced as 'Link, block name', which isn't quite as informative as it used to be. I'm not sure if it's related to this aria-hidden change. I didn't notice the same issue in Alex's video, so I'm guessing this is only a voiceover problem.

[getdave]

This Issue isn't specifically a problem of the Nav list view. It's a problem for all list view instances.

It needs to be resolved but it's going to require folks with NVDA to test and advise on which attributes need to change and how. Voiceover doesn't seem to be sufficient for testing unfortunately.

[scruffian]

I think we should revisit this once Navigation: Remove OffCanvasEditor component is done.

[alexstine]

I am working on it slowly here: #48461

[scruffian]

Since #48461 is closed I think we can also close this