Open afercia opened 4 years ago
afercia
commented
4 years ago 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.
ZebulanStanphill
commented
4 years ago 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" <select>?
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 <select> dropdown comes to mind again, but I worry a bit that if we're already using a <select> for category filtering, it might be all look a bit too heavy.
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).
afercia
commented
4 years ago 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.
alexstine
commented
4 years ago In a perfect world, this would work just like I described in: https://github.com/WordPress/gutenberg/pull/25170#issuecomment-691387640 the dialog behavior. However this to opens up in the sidebar view which is miles away from the "Add Block" button in the DOM. Without converting this element in to a dialog, these are my thoughts in the interim.
"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.
ZebulanStanphill
commented
4 years ago 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.
afercia
commented
4 years ago @alexstine thanks. Regarding:
Why not follow the same structure that is used in other places in the editor? E.g. you Tab in to the "Most Used" toolbar then you can use your left and right arrows to navigate it. You Tab again and you land in "Common Blocks" toolbar where you can use arrows for navigation. This would remove the required number of Tab keystrokes from users.
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.
It is a fair point to say why not just collapse the section? Well, if I am part way through a 30 block list, I don't want to go all the way back to the section button to collapse it.
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.
alexstine
commented
4 years ago 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.
afercia
commented
4 years ago 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 https://github.com/WordPress/gutenberg/pull/25506 Try List View in a panel in post editor https://github.com/WordPress/gutenberg/pull/25034 Exploring beyond a sidebar for exposing styling tools https://github.com/WordPress/gutenberg/issues/20212 Iterate on global styles sidebar (Site Editor) https://github.com/WordPress/gutenberg/issues/25139 Persistent block navigator panel https://github.com/WordPress/gutenberg/issues/22113 List View Design Updates (issue) https://github.com/WordPress/gutenberg/issues/24029 List View: Design updates (Draft PR) https://github.com/WordPress/gutenberg/pull/24419 Navigation Component: Accessibility #25259
diegohaz
commented
4 years ago @alexstine
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.
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.
alexstine
commented
4 years ago 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.
afercia
commented
4 years ago 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).
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 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.
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 hope that summarizes it reasonably well, but please don't imagine it's complete.
afercia
commented
4 years ago 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.
diegohaz
commented
4 years ago 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 https://github.com/WordPress/gutenberg/issues/21080#issuecomment-649231549.
In short, this should improve the current arrow key navigation in the block list and create a combobox-like experience on the search box.
As 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 https://github.com/WordPress/gutenberg/issues/21080#issuecomment-649231549. 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.
In 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 https://github.com/WordPress/gutenberg/pull/23610#issuecomment-660686352, 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.
I 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.
After 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 role="option" elements as the focus would wrap from the last item in a row to the first item in the next row.
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 aria-orientation attribute so people know they should use horizontal arrow keys by default. But all screen readers will announce the number of the currently active item in the set. Pressing the arrow down key on the first item would move focus below. Screen readers will go from 1 of 9 to 4 of 9 so users have a hint that they've skipped a few items.
Another 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 role="group" as listbox children:
<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.
Instead of role="group" elements, we could stick with what we have today (separate listboxes), but connect them so moving down from the last item in a listbox would move focus onto the first item in the next listbox. This may be controversial, but the resulting experience has been great:
<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 role="presentation" elements (as listbox doesn't support headings as children) has also a great impact on accessibility as users will be able to navigate through the categories by headings.
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.