Keyboard focus is not managed when dynamic content disappears

[karlgroves]

Keyboard focus is not managed when dynamic content disappears

• Severity: Medium
• Affected Populations:
  • Blind
  • Low-Vision
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Publish and Unpublish

Issue description

When the "Calendar Help" link or the "Close" button on its popup is
clicked, the focus is reset to the top of the page, in all tested
browsers except Chrome and chromium.

Keyboard and screen reader users rely on predictable and consistent
focus control to navigate the page. When this is absent, users may find
it much more difficult or even impossible to navigate using the
keyboard.

Issue Code

    <!-- when Calendar help is clicked... -->


    <button type="button" class="components-button components-datetime__date-help-button is-link">Calendar Help</button>





    <!-- ...focus should be brought to the popup -->


    <div class="components-popover__content" tabindex="-1" style="max-height: 187.361px;">


        ...<button type="button" class="...">Close</button>...


    </div>





    <!-- when the Close button is clicked, focus should move to Month control -->


    <div class="components-datetime__time-field components-datetime__time-field-month">


        <select aria-label="Month" class="...">...</select>


    </div>

Remediation Guidance

When the "Calendar Help" link is clicked, focus should move to the
popup which is opened (which has tabindex="-1").

When the "Close" button is clicked, focus should move back to the
Calendar Help's first focusable element (the month control).

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

[melchoyce]

Screenshot from full report:

[afercia]

Was able to reproduce with Firefox on the Calendar UI.

For other modals, a similar issue has been mitigated with the introduction of the onFocusLoss option in #14444.

[tellthemachines]

Update: this is now only a problem on IE11; it's fixed on all other browsers.

[afercia]

@tellthemachines I'm afraid you're confusing webkit and firefox proprietary behaviors with actual focus.

Modern browsers try to be "smart" and when a part of the DOM is removed or becomes hidden they try to start the tab order from the nearest focusable element. In Chrome, this is called sequential focus navigation starting point and landed in Chrome 50 on April 2016. Firefox already had a similar feature.

This is something completely different from managing focus though. It's just an attempt to restart the tab order from the nearest place so that after a Tab key press you may have the impression a focus loss didn't happen. Instead, it actually happened. Also, this mechanism is not guaranteed to work well with assistive technologies or when large parts of the DOM get removed/hidden.

In any case, when a part of the DOM that contains the currently focused element is removed or hidden, technically there's a focus loss that needs to be managed programmatically.

[alexstine]

Is this still an issue? I know it is in some parts of the editor, but I am hopeful those have been split in to different issues by now.

[tellthemachines]

Closing as this was fixed in #41097 when DateTimePicker was refactored to use WP components, which handle focus programatically.