Keyboard focus cannot easily reach Settings panel after opening

[karlgroves]

Keyboard focus cannot easily reach Settings panel after opening

• Severity: High
• Affected Populations:
  • Blind
  • Low-Vision
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Block Panel
  • Document Panel

Issue description

Keyboard users who use the "Settings" button to open the Settings
panel cannot easily reach the newly-opened panel using typical keyboard
navigation. The Settings content does not follow the triggering button
in the DOM, nor is focus programmatically moved there once it opens.

This is especially problematic for users who are zoomed in above 175%,
where the mobile styles apply, showing the Settings panel taking up the
entire page similar to a dialog. Users who attempt to tab through the
panel find themselves tabbing through elements behind the panel. The
screenshot shows a tooltip from something getting focus behind the
panel.

Issue Code

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


        <div role="toolbar" ..." aria-label="Document and block tools">...</div>


        <div class="edit-post-header__settings">


            ...


            <button type="button" aria-label="Settings" aria-expanded="true" class="...">...</button>


        </div>


        <div class="edit-post-more-menu">


            <button type="button" aria-label="Show more tools &amp; options" aria-expanded="false" class="...">...</button>


        </div>


    </div>


    ...


    <div class="edit-post-layout__content" role="region" aria-label="Editor content" tabindex="-1">...</div>


    ...


    <div class="edit-post-sidebar" role="region" aria-label="Editor settings" tabindex="-1">


        <div class="...">


            <span class="edit-post-sidebar-header__title">Gutenberg Editor Demo (edited for output scoping)</span>


            <button type="button" aria-label="Close settings" class="...">...</button>


        </div>


        <div class="...">


            <ul>


                <li>


                    <button class="..." aria-label="Document (selected)" data-label="Document">Document</button>


                </li>


                <li>


                    <button class="... " aria-label="Block" data-label="Block">Block</button>


                </li>


            </ul>


            <button type="button" aria-label="Close settings" class="...">...</button>


        </div>


        ...


    </div>

Remediation Guidance

Either move the dropdown contents to come immediately after their
activating buttons in source order OR programmatically move focus to the
first focusable item inside the dropdowns when they've been opened
(even if opened by a shortcut key).

Shortcut keys for moving around a document should be considered extra UX
features for power users, rather than essential for basic navigation.
Focus should follow a predictable order, generally following visible
items, and should not be able to reach invisible areas.

Relevant standards

• 1.4.10 Reflow (Level
  AA)
• 2.4.3 Focus Order
  (Level A)
• 2.4.7 Focus Visible (Level
  AA)

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-33 in Tenon's report

[melchoyce]

Screenshot from full report:

[afercia]

Related to the popover implementation as React portal, see #15332. See also this comment: #15332 (comment)

[afercia]

Nothing that this part:

Shortcut keys for moving around a document should be considered extra UX features for power users, rather than essential for basic navigation. Focus should follow a predictable order, generally following visible items, and should not be able to reach invisible areas.

is part of a broader issue and I'd recommend to include it in the design principles: content navigation via keyboard can't rely on shortcut keys alone.

[karmatosed]

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

[enriquesanchez]

@ellatrix pinging you since I know you have recently been working on keyboard navigation improvements to the editor and block toolbars.

Is the remediation guidance suggested on this issue something we could try?

Either move the dropdown contents to come immediately after their
activating buttons in source order OR programmatically move focus to the
first focusable item inside the dropdown

This means that after activating the 'Settings' button in the editor toolbar, focus should move to the first focusable element in the 'Settings sidebar', this being the 'Document' button.

[ellatrix]

This means that after activating the 'Settings' button in the editor toolbar, focus should move to the first focusable element in the 'Settings sidebar', this being the 'Document' button.

That sounds good!