Inserter accessibility

[abrightclearweb]

Tested on: Gutenberg 0.3, 0.4.

Setup: Mac OS X Sierra, MAMP, Safari 10.1.1.
Gutenberg is the only plugin active.

When using the keyboard only to navigate and insert a block, only the Search and Recent blocks are navigable. The Blocks or Embeds tabs (actually buttons) can't be reached by keyboard alone.

It's possible to tab through the list of available blocks under Recent and select one to insert. Tabbing to the end of the Recent list gets you stuck on the last block (Cover Image). Tabbing or shift-tabbing (or using the left/right arrow keys) from this position does nothing. The user must select that block or press Esc to cancel.

The Search only searches the blocks shown in the current pane. So searching Recent blocks only delivers a result when the block is Recent. There is no feedback given if the search result is null.

Searching for e.g. button only works if the user has selected the Blocks button, which is not possible with the keyboard alone.

This issue makes most blocks inaccessible by keyboard.

There is a similar issue with VoiceOver screen reader. It is possible to navigate to Blocks or Embeds but in a very difficult and completely unintuitive way.

To find the Blocks option using VoiceOver it was necessary to:

1. Go to the Insert button and activate it.
2. Tab to the search field
3. Enter some text
4. Press CTRL-Opt-U to open the rotor
5. Navigate using left/right arrow keys from Window Spots Menu to Form Controls menu
6. Navigate to Blocks button using down arrow key
7. Activate Blocks button
8. Tab back to the search field and delete text
9. Tab down the list and select the desired block

Not many users would think to do this!

This UI for inserting blocks looks better for sighted users but needs to be keyboard navigable.

The search function also needs to be improved to search all blocks.

[afercia]

See also #1606

[mtias]

The Search only searches the blocks shown in the current pane. So searching Recent blocks only delivers a result when the block is Recent. There is no feedback given if the search result is null.

This will be covered with #1596.

[abrightclearweb]

I've tested now with Gutenberg 1.4 and the issue of accessing the Blocks and Embeds panels when inserting blocks with the keyboard alone remains. I can't see how these sections can get focus.

Here's a demo:

All I'm doing is tabbing and shift-tabbing.

Can anyone else replicate this issue?

[mtias]

@abrightclearweb the different panels are not yet accessible with the keyboard, but search is global—searches across all available blocks.

[afercia]

See also #1497 (comment)

Would be great to prioritize decisions on the inserter and have a stable version soon.

There are currently 2 alternative design proposal I'm aware of:

• the "go larger font-size and single column" on Inserter: go larger font-size and single column #1497
• the "tabs on the left" on Turning a static block into a dynamic reusable block #1516 (comment) see screenshot below

[afercia]

Renamed this issue so we can use it to address all the accessibility side.

[ephox-mogran]

What is the progress on this task?

[afercia]

Accessibility on the inserter is still to re-build after the changes that broke a first a11y implementation. I think the best option would be to abstract a NavigableMenu and make it a generic component for keyboard navigation. See #3210 (comment)

[ephox-mogran]

We probably should have updated this task yesterday. @tg-ephox and I are currently looking at this task. I'm trying to make a generic component for TabPanel that is accessible based mostly on this (https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html) and not heeding this (http://simplyaccessible.com/article/danger-aria-tabs/ ) yet :). @afercia , are you aware of the problems listed in the latter link?

@tg-ephox is working on the Inserter Menu itself and the view for the blocks. The keyboard navigation we were thinking would be:

<SearchBar>
<TabList>
  <Tab 0/>
  <Tab 1/>
  <Tab 2/>
</TabList>
<TabView />

Press tab to move from the SearchBar to the TabList to the TabView. We are proposing having only these three tabstops. They would cyclic from the end back to the start as well.

When TabList gets focus, it would shift focus to the currently selected tab. Pressing left and right would move the selected tab left and right respectively, and make the newly focused tab the active tab.

When TabView gets focus, it would focus either the last focused block (if still in the view), or the first block. The arrow keys up, down, left, right) would be used to navigate through the grid of block types. I'm not sure how that should work with the groups that are separated by category. If the user pressed tab it would jump back to SearchBar. Tabbing would not be used to cycle through the blocks or the tabs.

This is a proposal, and based on what was said above, it might too early to start work on it if that component is still in a state of flux. However, just to see if we are getting the right idea, is that the kind of keyboard flow that you would want @afercia, @abrightclearweb ?

[afercia]

@ephox-mogran yes I'm aware of the interpretation people at Simply Accessible gave to their testing on the ARIA tabbed interface and that post is controversial. Have you read the comments to the post, especially the ones from people like Bryan Garaventa, Birkir Gunnarsson, and Matt King? They're all people actively working, or who have worked, on the ARIA specifications. Matt King is one of the editors of the ARIA Authoring Practices 1.1.

That said, if we decide to go with the ARIA interaction model, which is navigation with only arrow keys inside a widget, then we should adopt that model for all the other cases, for example: toolbars and menus. Personally, I'd encourage that and I think this interaction model should be well communicated to users.

Worth reminding the main advantage of this ARIA interaction model is that it's a "mixed" model. It allows to use Tab to quickly navigate to a widget (a toolbar, a tab interface, etc.). The widget has just one Tab stop. Tabbing again allows to navigate away from the widget without having to explore all its content. Navigation within the widget works with arrow keys only.

When well implemented, this is a very efficient mechanism.

Worth noting tabbed interfaces are everywhere in our operating systems, and they work exactly like ARIA tabbed interfaces do. I wonder how keyboard users would't know how to use them, unless they're occasional keyboard users.

I think the block types groups would need some ARIA role to make the arrow keys navigation be communicated to assistive technologies users and to make it work.

Not sure about the groups that are separated by category, maybe the best option would be keep it simple and arrow through all the groups?

Have you looked into NavigableMenu?

[ephox-mogran]

Yeah, I'm working on creating a generic NavigableContainer at the moment, with various navigation modes based on NavigableMenu. Seems promising so far.

I should have a prototype ready by the end of today Australia time, so if you have time, I'd appreciate your feedback on it. There will be a few tab stops in the InserterMenu (Search, Tab List, and a tabstop for each block category). Each of these will be considered a separate widget and the widget itself will have arrow navigation inside. This is aimed at keeping basically what we have now, but making it keyboard accessible.

[ephox-mogran]

First attempt: #3281

[afercia]

Thanks! Tested a bit and commented on the PR.

[ephox-mogran]

Should we close this issue now? Are there any other tasks to do aside from #3281 ?

[afercia]

I'd like to see a final round of testing from the accessibility team, they usually test the plugin though.

[afercia]

Going to open a new issue for the necessary adjustments to the ARIA roles and attributes. Still pending a testing round from the a11y team.

[afercia]

We're testing the inserter keyboard accessibility at the WCUS contributor day, will post some feedback soon.

[afercia]

Going to close this to start fresh with a new issue with some feedback from WCUS a11y testing.