Toolbar elements are tabbable

[karlgroves]

Toolbar elements are tabbable

• Severity: Medium
• Affected Populations:
  • Blind
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Editor Top Bar

Issue description

Keyboard-only users who enter the Editor Top Bar must Tab from button to
button. Although this is manageable when there's a small number of
buttons, the group of buttons is given the role of toolbar, whose
purpose (besides grouping related controls) is to lessen the number of
Tab stops keyboard users must make to navigate past widgets.

Screen reader users may be told they are entering a toolbar and expect
to be able to Tab past everything in it. Their experience does not match
the promise of the role.

Screen reader users may also miss the toolbar role when meeting the
first item (an anchor), because roles such as toolbar are sometimes only
announced when users meet items which can trigger their forms/focus
mode. Since the anchor's behaviour is semantically different from the
buttons' (the buttons deal with the editable content, the anchor simply
takes users back), it may make more sense to keep the anchor out of the
toolbar group.

Issue Code

    <div role="region" aria-label="Editor top bar" class="edit-post-header" tabindex="-1">


        <div role="toolbar" aria-orientation="horizontal" class="edit-post-header-toolbar" aria-label="Document tools">


            <div class="components-toolbar components-toolbar edit-post-fullscreen-mode-close__toolbar">


                <a href="edit.php?post_type=post" aria-label="View Posts" class="..."><svg aria-hidden="true"...>...</svg></a>


            </div>


        <div>


            <div class="editor-inserter">


                <button type="button" aria-label="Add block" aria-haspopup="true" aria-expanded="false" class="...">...</button>


            </div>


        </div>


        <button type="button" aria-label="Undo" aria-disabled="false" class="...">...</button>


        <button type="button" aria-label="Redo" aria-disabled="true" class="...">...</button>


        <div class="table-of-contents">


            <button type="button" aria-label="Content structure" aria-expanded="false" aria-disabled="false" class="...">...</button>


        </div>


        ...


    </div>

Remediation Guidance

Move the "View Posts..." anchor out of the role=toolbar section,
so the toolbar only has <button> children.

Although ideally it would be a better use of the toolbar pattern to
implement Arrow-keys only, and not support Tab navigation between items,
this pattern may not be familiar to all users. Adding support for the
Home and End keys (for jumping to the first and last item in the
toolbar) will help here: this will allows users who know the keyboard
pattern for ARIA toolbars to efficiently get past the toolbar, while
leaving the Tab pattern for users who do not.

Recommended Code

    <div role="region" aria-label="Editor top bar" class="edit-post-header" tabindex="-1">


        <div class="...">


            <a href="edit.php?post_type=post" aria-label="View Posts" class="..."><svg aria-hidden="true"...>...</svg></a>


        </div>


        <div role="toolbar" aria-orientation="horizontal" class="edit-post-header-toolbar" aria-label="Document tools">


            <div>


                <div class="editor-inserter">


                    <button type="button" aria-label="Add block" aria-haspopup="true" aria-expanded="false" class="...">...</button>


                </div>


            </div>


            <button type="button" aria-label="Undo" aria-disabled="false" class="...">...</button>


            <button type="button" aria-label="Redo" aria-disabled="true" class="...">...</button>


            <div class="table-of-contents">


                <button type="button" aria-label="Content structure" aria-expanded="false" aria-disabled="false" class="...">...</button>


            </div>


        </div>


        ...


    </div>

References

https://www.w3.org/TR/wai-aria-practices-1.1/#toolbar

Relevant standards

• 2.1.1 Keyboard
  (Level A)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-8 in Tenon's report

[afercia]

Related to the general issue (mentioned several times) that there are too many tab stops when navigating through the blocks UI. See for example #632, #3383, #5694, and #1934 (comment)

[melchoyce]

Screenshot from full report:

[afercia]

Note: this part:

Screen reader users may also miss the toolbar role when meeting the first item (an anchor)

relates to the view_items link with that appears only in "Fullscreen Mode":

(the icon was changed in #13403). In default mode, this link is not rendered:

This link needs to be moved out from the role=toolbar and still be within the "navigate region" landmark.

[afercia]

Re: the toolbar general issue, there are a few options. As reported, the purpose of a role=toolbar is:

• grouping related controls
• lessen the number of Tab stops keyboard users must make to navigate, by using only arrows navigation (see for example Toolbar: consider to use a roving tabindex and standardize navigation #3383 and Add arrow navigation to the editor toolbars #631)
• inform screen readers they have to stop intercepting keystrokes so arrow navigation works

Reducing the amount of Tab stops is by far the most important goal especially when a toolbar has many buttons. Consider, for example, the "Top Toolbar" option adds several buttons:

More importantly, please consider this applies also to the block toolbars:

As mentioned in other issues and PRs: imagine a post with 10 paragraph blocks. Keyboard navigation through 10 block toolbars like the one in the screenshot above requires 90 tab stops. It could be reduced to just 10 tab stops by implementing only arrows navigation.

However, a good point is that not all users may be familiar with this pattern (although it's a standard pattern widely used also in the operating systems user interfaces).

Options to evaluate:

Keep both arrows key and Tab navigation adding support for the Home and End keys:

• users who aren't familiar with arrows navigation can use the Tab key
• users familiar with arrows navigation can use End and Home to jump to the last and first item in the toolbar
• cons:
  • discoverability of the Home / End keys pattern
  • wouldn't help so much in reducing the amount of keystrokes to navigate toolbars, especially in the post content where the pattern would be, for example: 1) press Tab to enter the toolbar 2) press End to jump to the end of the toolbar 3) press Tab to exit the toolbar (repeat for each block in the post content)
  • in some keyboard layouts, there is no Home key or End key: a keystroke combination is required, making the step above even more inefficient

Implement only arrows key navigation (and maybe add the roving tabindex pattern):

• users who aren't familiar with arrows navigation would need to learn the new pattern
  • cons: discoverability
• users already familiar with arrows navigation would be OK
• the amount of keystrokes to navigate through the blocks in the post content would be greatly reduced

[gziolo]

@diegohaz works on this issue in #17875.

[diegohaz]

All toolbar blocks are now working with roving tabindex on master. Should we close this?

[gziolo]

Amazing work, let's close 🥳