Skip to content
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

Constrained tabbing: more failures with Safari and Firefox #46041

Closed
afercia opened this issue Nov 24, 2022 · 0 comments · Fixed by #47426
Closed

Constrained tabbing: more failures with Safari and Firefox #46041

afercia opened this issue Nov 24, 2022 · 0 comments · Fixed by #47426
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Compose /packages/compose [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release

Comments

@afercia
Copy link
Contributor

afercia commented Nov 24, 2022

Description

Related: #46038 and #45809
See also #42653

Migrating the a11y tests to Playwright #46038 surfaced more failures of Constrained tabbing, specifically with Safari and Firefox. Actually, in #46038 one test fails with Webkit and two tests fail with Firefox. These can be reproduced also manually.

Step-by-step reproduction instructions

To manually reproduce the failing tests in the Draft PR #46038

  • Include the changes from Constrained tabbing: fix unstable behavior in firefox #42653 if not merged yet. Thie will fix another bug in Firefox.
  • Edit a post.
  • Open the Keyboard shortcuts modal dialog, for example by pressing Control+Option+H on macOS or by clicking the related item in the Options menu.
  • Note: this modal dialog has two features that have an impact on the Constrained tabbing failure:
    • For all browsers other than Firefox: the modal contains only one focusable element: the Close button.
    • For Firefox: the modal contains a scrollable div element. Firefox makes scrollable element focusable when they trigger an actual overflow (your screen height may have an impact here, make sure the modal content height actually exceeds the modal container height and the div is actually scrollable).

Safari:

  • With the modal opened, click any part of the modal after the Close button.
  • Press the Tab key.
  • The modal closes.
  • Expected: the modal to stay opened and focus to move to the Close button.

This happens only when clicking somewhere after the Close button.

  • With the modal opened, click any part of the modal_before_ the Close button, for example click the modal title 'Keyboard shortcuts'.
  • Press the Tab key.
  • Observe the modal stays opened and focus goes to the Close button, as expected.

Firefox:

  • Make sure the modal content is actually scrollable. This may depend on your screen size. When there is an actual overflow of the content, Firefox makes the scrollable div with CSS overflow: auto focusable.
  • With the modal opened, press the Tab key.
  • Focus moves to the scrollable div, as Constrained tabbing relies on native browser behavior.
  • Note that you won't see any focus style. To make debugging easier, add the following CSS somewhere:
:focus {
	outline: 4px solid red !important;
	outline-offset: -4px;
}
  • Press the Tab key again.
  • Focus stays on the scrollable div. The Close button is not reachable by pressing the Tab key. Edit: can't reproduce this part any longer.
  • Expected: focus to go to the Close button and then cycle through the two elements at following Tab key presses.
  • Close the modal and then reopen it.
  • Press Shift+Tab.
  • Focus goes to the Close button.
  • Press Shift+Tab again.
  • Focus stays on the Close button. The scrollable div is not reachable by pressing the Shift+Tab.
  • Expected: focus to go to the scrollable div and then cycle through the two elements at following Shift+Tab keys presses.

Firefox is the only browser that natively makes scrollable div elements focusable. I'm not sure this has been ever taken into account. However, the current implementation of Constrained tabbing relies on native browsers behaviors which are actually different. It seems to me the current implementation is inherently fragile as it is exposed to different, legitimate, browsers features. I'm not sure what is the best option here:

  • either keep the current implementation and then cover all the browsers differences.
  • revert to the previous implementation, which didn't rely on native browser behaviors and kept things more under control.

Either ways, the scrollable div issue would need to be solved by standardizing the behavor. There are good accessibility reasons to make a scrollable div always focusable, see #45809.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Regression Related to a regression in the latest release [Package] Compose /packages/compose [a11y] Keyboard & Focus labels Nov 24, 2022
@afercia afercia self-assigned this Jan 18, 2023
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jan 25, 2023
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Compose /packages/compose [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants