Audit the new Inserter accessibility #24975
Comments
afercia
added
[Type] Bug
|
On a side note: I'd like to propose to the accessibility team to evaluate whether the modal behavior (with constrained tabbing) added to the Inserter sidebar in #24429 is something that would be beneficial also on the other sidebars: the Settings sidebar, the sidebars added by plugins, the new sidebar proposed for Full Site Editing in #23939 etc. |
|
On the subject of the removal of the collapsible categories, I initially thought it would be an okay change, but the more I've used the editor since then, the more I've grown to miss the ability to quickly get to a specific category. Perhaps bringing back the accordion-style sections isn't the answer, but I think there needs to be some way to filter blocks by category. Perhaps a "Filter by" Being the one who introduced the separate "Reusable" tab, I knew from the start that the label wasn't ideal. But I didn't think the full "Reusuable blocks" title would fit in the limited space (especially when you take other languages into account). This stems from the limitations of the the tabbed design, so perhaps we should use some other design pattern here. A Thinking about it some more, perhaps the category filtering options could be put behind a "Filter" dropdown menu that could also contain options like "sort alphabetically" or "sort by most used", as well as Collection filtering, for finding blocks from a specific plugin (or plugin family). I also agree with the assessment of the Patterns UI feeling a bit confusing. There's hardly enough room to show very many patterns in the sidebar in the first place, and having these big images in between the text makes it feel especially awkward. I understand why it was designed that way, but I'm not sure it was worth it, and I now think it would be better to switch to something more like the other two tabs. As for the "Most used" category, I never found it useful... mainly because I could never control what appeared there and in what order. It always felt kind of random to me, and since "most used" tends to change over time, one could never be sure the same blocks would appear there as last time you used it. For that reason, I'd much rather have something like a "Favorites" category, where the user explicitly chooses what blocks appear there (and which is populated by default with important blocks like Paragraph, Heading, and Image). |
Thinking this a very interesting point. Maybe the "Most used" category was trying to be a bit too "smart" and was changing too frequently in the short term, even if I'd tend to think that in the long term, with a more prolonged use, it was more accurate. Regardless, giving users the ability to set their own favorites seems a better option, as it is often the case when empowering users to do their things. I'm a bit concerned about the UI to add a block type to the Favorites group. That would mean adding additional controls in a UI that's already crowded and difficult to parse, especially for users with accessibility needs. It could be explored separately though and I'd totally support this exploration. |
|
In a perfect world, this would work just like I described in:
"68 results found." Can this be wrapped within the block inserter? This way if the decision is made to keep close on focus loss, at least that text doesn't stick around confusing users about "68" results they cannot see anymore. Thoughts? Thanks. |
|
Part of the reason the inserter is in a sidebar format right now is supposedly so you can see the blue line indicating where the block will be inserted. But... why would you need to see that in the first place? Surely, if you've opened the inserter, you already know where you intend to place the block, right? You certainly already know if you used a sibling inserter or inline appender. And now that the inserter closes on focus loss, you can't even change the position where the block will be inserted. So what's the point? I agree with @afercia and @alexstine that a dialog (like the Options dialog) would make way more sense. On desktop-width screens, it could have way more real-estate to show a full-scale preview of the currently-hovered/focused block type or pattern, rather than the relatively tiny one we have right now. |
|
@alexstine thanks. Regarding:
This makes me think you're testing with an old version of block editor. In the latest version, Tab already navigates through the sections and arrows navigate within the sections.
Right. Well, sections could use both behaviors: be collapsible and provide just one tab stop (with arrows navigation to navigate the sections content). I'd totally agree with your other points, Not a case that they will make the Inserter behavior closer to the one of a dialog. The more I think about this the more I'm leaning towards making the Inserter semantics and interaction the one of a dialog. I'd suggest to consider to make it a dialog also visually: there's only one task users need to focus on when using the inserter: find and add a block. A user interface pattern that exclusively focuses on this task seems the most appropriate to me. |
|
Okay, so sure enough, I was using an older version of WordPress. :( I actually think the newer version functions slightly better at least testing with NV Access. The Tab to get to each section is nice then using arrow keys to navigate is good. The only issue I had from time to time was getting the tabs to change. E.g. in between "Blocks" and "Patterns". Sometimes I had to use down arrow and sometimes it was right and left arrow to get it moving. The real issues with this fall in the fact it's not structured like a dialog, but I think we all kind of agree on that. Thanks. |
|
Other "sliding in sidebars" that have been introduced or are going to be introduced in the plugin or other issues related to this pattern: Site Editor: navigation sidebar #25506 |
Thank you for the feedback! I wonder if it would be any better (or worse?) if, instead of the current one-dimensional keyboard navigation (listbox), we used a two-dimensional widget (grid). Visually, the blocks are organized in a grid-like layout. For sighted (or maybe even half-sighted?) keyboard users, two-dimensional navigation could make more sense. That is, pressing arrow down would move focus down, and not to the right, as it currently is. But, for screen reader users who are totally blind, the way the elements are arranged on the screen doesn't really matter. By using a grid, the screen reader user would also lose the information about the current item number and the total number of items. Instead, they would hear meaningless "row 1, column 1" announcements. We could fix this with custom announcements. But I think it would be better if we didn't need this.
|
|
I honestly do not have a problem with the way the inserter works with the keyboard now. The biggest thing I want to see fixed is wrapping this whole element in a dialog. There is no reason to have this inserter close as easily as it does and once focus is removed from the inserter, it disappears. It may help to add some type of instructional message. E.g. navigate categories using the Tab key. However since this follows a similar layout to the top toolbar and block formatting toolbar, I do not see this being needed. The other thing that should be looked at is switching from Blocks to Patterns tabs. It is still really slow and laggy for me in Firefox and it just about crashed Firefox today. That was not a good UX experience and I have not been able to successfully make that tab control work twice. I do not think using the down arrow key should switch to other categories. I would rather keep the down/up arrow navigating right and left. Tab seems to be a good way to switch between categories effectively. Thanks. |
Worth reminding the grid / gridcell ARIA pattern is very debated amongst accessibility specialists and should only be used after it's proved that it add real value without introducing new barriers, i.e.: after extensive user testing. As mentioned also by Alex, one of the main issues here is that for keyboard users the inserter should have a modal behavior (which it has now) and this probably applies to all the "sliding sidebars" that are landing in WordPress. Specifically for screen reader users, it would be even better if this was a modal dialog. Regarding the tabs:
The ARIA tabs pattern can be implemented with or without automatic activation of the tabs. That is:
The second option has its advantages when loading the panel content requires a certain amount of time to fetch its content. For example, in the media modal, I implemented the switch between the tabs after user activation because loading all the attachments requires time. Instead, the automatic activation while using the arrow keys was making the interface very laggy. This should be taken into consideration when building tabs. The Patterns tab gets re-rendered each time which makes it clearly slow, even when using the mouse. That said, the "sliding sidebars" pattern has other accessibility issues that aren't exclusively related to screen reader users. The accessibility team had an initial discussion on these issues during one of the last meetings on Slack and the additional accessibility problems identified so far are (quoting @joedolson):
|
|
I just noticed there's one more consequence introduced by the new implementation. The main inserter is also an ARIA landmark region. However, this landmark is only rendered when the inserter is open. This is arguably a correct implementation. Landmarks are navigational tools. They establish a sort of "contract" with users by informing them that all the page content is split in some sections. To be effective, this information must be fully provided when the page loads. Only this way users can understand "okay, this page is split in region xyz, region abc, region blah blah, etc. Rendering an additional landmark only when the inserter is open is only useful to allow quick navigation through landmarks (including the inserter when open) via the dedicated screen readers shortcuts. However, the information this landmark exists must be provided at page load. To test:
Screenshot of the VoiceOver landmarks list with the inserter open:
Worth noting that the "Editor publish" landmark is always rendered even when the publish sidebar is closed. This is intentional and it was made in a way to ensure this landmark always has some content; in fact, when the publish sidebar is closed, the landmark contains a visually hidden button to open the publish sidebar. |
|
I've been experimenting a lot with the block inserter in terms of keyboard navigation. I'd like to share my findings here. This is highly based on the design I shared at #21080 (comment). In short, this should improve the current arrow key navigation in the block list and create a combobox-like experience on the search box. GridAs I've mentioned in several other posts, my initial idea was to leverage the ARIA Grid Pattern to create a two-dimensional interactive widget. But there's been a lot of controversial conversations around this pattern, most notably this blog post: ARIA Grid As an Anti-Pattern. I created this example of the block inserter using the grid pattern so we can test it. For sighted keyboard users, the interaction works as described in #21080 (comment). But screen reader support is awful (VoiceOver in special). Row/column announcements are pretty much useless, if not confusing (all screen readers). With this, I could confirm most of what Adrian Roselli stated in his post. No composite roleIn the comments, Adrian suggested the use of a custom widget without a composite role as an alternative. The problem with this approach, as mentioned by @afercia in #23610 (comment), is screen readers wouldn't change to focus mode automatically, and therefore screen reader users wouldn't benefit from the roving tabindex behavior unless they manually activate focus mode. ListboxI talked about this with Sarah Higley — who has also written a related article (Grids Part 1: To grid or not to grid). She suggested the use of the ARIA Listbox Pattern. And that's what we've been using so far. This seems to work well for screen reader users, but it's not a good experience for sighted keyboard users, who can see how items are arranged in a two-dimensional grid, but can't move the focus vertically. Example of one-dimensional listbox. Two-dimensional listboxAfter some research, I learned how Slack was "solving" this in their web app for their emoji picker. Their implementation doesn't work very well on screen readers, but I thought I could improve that to create a two-dimensional listbox: <div role="listbox" aria-orientation="horizontal">
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
</div>As a horizontal listbox, pressing arrow right would move through all But this listbox would also support vertical arrow keys to navigate in a two-dimensional way. JAWS is the only screen reader that announces the Category groupsAnother issue we have is that the block list is organized into categories. Currently, categories are separate listboxes that aren't connected in any way. That is, you can't move through all the blocks using only arrow keys. To solve this, aria 1.2 supports <div role="listbox" aria-orientation="horizontal">
<div role="group" aria-labelledby="group-1-label"> <!-- group -->
<div role="presentation" id="group-1-label">Text</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
</div>
<div role="group" aria-labelledby="group-2-label"> <!-- group -->
<div role="presentation" id="group-2-label">Media</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
</div>
</div>Unfortunately, aria 1.1 doesn't support it. It works in NVDA and JAWS, but not in VoiceOver. Example of a two-dimensional listbox with multiple groups. Multiple connected listboxesInstead of <div>
<h2 id="group-1-label">Text</h2>
<div role="listbox" aria-orientation="horizontal" aria-labelledby="group-1-label"> <!-- group -->
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
</div>
<h2 id="group-2-label">Media</h2>
<div role="listbox" aria-orientation="horizontal" aria-labelledby="group-2-label"> <!-- group -->
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
<div role="presentation"> <!-- row -->
<div role="option">Item</div>
<div role="option">Item</div>
<div role="option">Item</div>
</div>
</div>
</div>Also, the fact that we can use headings, and not Example of multiple connected two-dimensional listboxes. So far, this one has demonstrated to be a really good approach, but I would appreciate any testing and feedback. |
Describe the bug
The new Inserter introduced in WordPress 5.5 has been identified by the accessibility team as a regression in the accessibility level compared to WordPress 5.4. See #22858. The team asked, at the very least, to re-introduce a modal behavior which has been implemented in #24429 🎉 That means the Gutenberg plugin is now "fixed" for what concerns constraining tabbing within the Inserter but worth reminding the version shipped with WordPress 5.5 isn't "fixed".
Besides the welcomed re-introduction of constrained tabbing, there are outstanding issues that still need to be fully evaluated for their impact on accessibility and, to some extent, on general usability.
In the screenshot below: on the left, the new Inserter and on the right, the one in WordPress 5.4:
Some of the things to evaluate:
aria-pressed=true/falseattribute and noaria-haspopupattribute, which doesn't seem correct to merole=regionand an aria-label like the other sidebars so it's now also an ARIA landmark regionrole=listboxthat doesn't seem correct to me: this role was used only to make screen readers announce the number and positions of the block types but it's arguably a correct role for this UIMarking this issue as bug because some of the points above need to be fixed. Adding also the "Task" label, pending a more thorough accessibility audit.
The text was updated successfully, but these errors were encountered: