New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inserter accessibility #1823

Closed
abrightclearweb opened this Issue Jul 9, 2017 · 18 comments

Comments

Projects
None yet
5 participants
@abrightclearweb

abrightclearweb commented Jul 9, 2017

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.

keyboard accessibility gutenberg 0 4 insert

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.

keyboard accessibility gutenberg 0 4 search

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jul 9, 2017

Contributor

See also #1606

Contributor

afercia commented Jul 9, 2017

See also #1606

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Jul 9, 2017

Contributor

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.

Contributor

mtias commented Jul 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@abrightclearweb

abrightclearweb Oct 13, 2017

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:

gutenberg insert block

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

Can anyone else replicate this issue?

abrightclearweb commented Oct 13, 2017

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:

gutenberg insert block

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

Can anyone else replicate this issue?

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 19, 2017

Contributor

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

Contributor

mtias commented Oct 19, 2017

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

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 20, 2017

Contributor

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 #1497
  • the "tabs on the left" on #1516 (comment) see screenshot below

image

Contributor

afercia commented Oct 20, 2017

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 #1497
  • the "tabs on the left" on #1516 (comment) see screenshot below

image

@afercia afercia changed the title from Problems searching and accessing blocks with keyboard alone to Inserter accessibility Oct 20, 2017

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 20, 2017

Contributor

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

Contributor

afercia commented Oct 20, 2017

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

@afercia afercia referenced this issue Oct 20, 2017

Merged

Improve inserter style #3080

3 of 3 tasks complete

@mtias mtias added this to the Beta 1.6 milestone Oct 24, 2017

@ephox-mogran

This comment has been minimized.

Show comment
Hide comment
@ephox-mogran

ephox-mogran Oct 30, 2017

Contributor

What is the progress on this task?

Contributor

ephox-mogran commented Oct 30, 2017

What is the progress on this task?

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 30, 2017

Contributor

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)

Contributor

afercia commented Oct 30, 2017

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)

@mtias mtias modified the milestones: Beta 1.6, Beta 1.7 Oct 31, 2017

@ephox-mogran

This comment has been minimized.

Show comment
Hide comment
@ephox-mogran

ephox-mogran Oct 31, 2017

Contributor

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 ?

Contributor

ephox-mogran commented Oct 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 31, 2017

Contributor

@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?

Contributor

afercia commented Oct 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ephox-mogran

ephox-mogran Nov 1, 2017

Contributor

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.

Contributor

ephox-mogran commented Nov 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ephox-mogran

ephox-mogran Nov 1, 2017

Contributor

First attempt: #3281

Contributor

ephox-mogran commented Nov 1, 2017

First attempt: #3281

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 3, 2017

Contributor

Thanks! Tested a bit and commented on the PR.

Contributor

afercia commented Nov 3, 2017

Thanks! Tested a bit and commented on the PR.

@ephox-mogran

This comment has been minimized.

Show comment
Hide comment
@ephox-mogran

ephox-mogran Nov 14, 2017

Contributor

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

Contributor

ephox-mogran commented Nov 14, 2017

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

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 14, 2017

Contributor

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

Contributor

afercia commented Nov 14, 2017

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

@iseulde iseulde modified the milestones: Beta 1.7, Beta 1.8 Nov 20, 2017

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 22, 2017

Contributor

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.

Contributor

afercia commented Nov 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Dec 3, 2017

Contributor

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

Contributor

afercia commented Dec 3, 2017

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

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Dec 13, 2017

Contributor

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

Contributor

afercia commented Dec 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment