Make the Blocks navigation a nested list to better communicate the blocks nesting level #11734
Conversation
designsimply
added
the
[Feature] List View
|
From a UI perspective this looks great. Seems like you've been able to propose a solution that still keeps the look and feel we've been using. |
afercia
added
the
[Focus] Accessibility (a11y)
| @@ -25,23 +25,30 @@ function BlockNavigationList( { | |||
| showNestedBlocks, | |||
| } ) { | |||
| return ( | |||
| <ul className="editor-block-navigation__list" role="presentation"> | |||
| /* | |||
| * Disable reason: The `list` ARIA role is redundant but | |||
There was a problem hiding this comment.
❤️ for the explanation.
If there's a WebKit bug we could link to that'd be swell, but no worries if not.
There was a problem hiding this comment.
Not sure. It's a Safari specific bug. Chrome is exempt. I wouldn't know where to look for Apple open bugs. We do the same thing in BlockTypesList, for more details see #7058 (comment). Test case: https://codepen.io/afercia/full/WxmJWx/
| @@ -55,6 +62,7 @@ function BlockNavigationList( { | |||
| ); | |||
| } ) } | |||
| </ul> | |||
| /* eslint-enable jsx-a11y/no-redundant-roles */ | |||
There was a problem hiding this comment.
Probably not a big deal, but can this be moved immediately underneath the <ul>? Just to minimise the number of lines we ignore linting on?
There was a problem hiding this comment.
Tried and I'd need to do something like this to make the linter happy:
/* eslint-disable jsx-a11y/no-redundant-roles */
<ul className="editor-block-navigation__list" role="list">
{ /* eslint-enable jsx-a11y/no-redundant-roles */ }
{ map( blocks, ( block ) => {
not sure it looks so nice 🙂
Description
When there are nested blocks, the Blocks navigation displays them with some indentation. However, this information is only visual. This PR seeks to communicate the nesting level also semantically by using an unordered list. Lists convey important information for free: the number of items in the list, their nesting level, the current item number.
Assistive technologies can use the list semantics to properly inform users, so they can actually get the structure of nested blocks.
I've done my best to avoid visual changes.
Worth noting arrows navigation won't work well with screen readers on Windows because now there isn't an ARIA role to instruct screen readers to stop intercepting keystrokes. I think providing the missing information is more important than arrows navigation. Also, there are proposal to change and extend the functionalities of the Blocks navigation, see #10984, #11408, #11688, and #11711. In all those cases, an ARIA menu wouldn't be the proper UI to use and arrows navigation would need to be removed anyways.
I'm trying to keep the arrows navigation behavior for non-screen reader users for now, but I'd tend to think this component is now more similar to the "Document outline": a simple list with no special interaction other than the native one. Please do let me know if completely removing arrows navigation is desirable.
NavigableMenuto keep arrows navigation (for now)screen-reader-textto communicate the selected state of a list itemaria-orientationattribute, as this is not a menu any longereditor-block-iconto a<span>element:<div>elements are invalid HTML within buttons; we'd want this component to be reusable everywhere and also ensure valid HTML and a div doesn't seem appropriate; theeditor-block-iconis already a flex element with set width and height so this change shouldn't harm anythingaria-labelledbyany longer, I'm not so worried about it because users get this popover clicking on a button that already announces "Block Navigation"Fixes #11713
Screenshots to illustrate how the nesting level gets announced thanks to the native semantics of an
<ul>element:Note: other screen readers communicate the nesting info in different ways, see the example screenshots on #11713