Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Inserter accessibility #1823
Tested on: Gutenberg 0.3, 0.4.
Setup: Mac OS X Sierra, MAMP, Safari 10.1.1.
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:
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.
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
@tg-ephox is working on the Inserter Menu itself and the view for the blocks. The keyboard navigation we were thinking would be:
Press tab to move from the
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 ?
@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
Yeah, I'm working on creating a generic
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