-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Page content can be accessed while dropdowns are open #15332
Comments
This issue applies to all the "popovers" in the UI, not just the Document Outline.
This was requested several times by the accessibility team and discussed at length since the very beginning of this project. See for example #469, #1918, #2306, #4621, #5242, and #5559. It's fair to say that development convenience prevailed over usability and accessibility. Given there was no consensus to change the implementation of the popovers as React portals (see #2160), the accessibility team recommended a few improvements including constraining tabbing within the popovers and focus management. Still, the interaction isn't ideal and can be unexpected for some users. Strongly recommended: reconsider the popover implementation. I'd tend to think that also from a component-based pattern, the toggle button should be part of the popover component as it's an essential part of the whole functionality. The recommended source order would also make focus management simpler. |
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. |
I'm not sure about the history here, so pinging @jasmussen and @youknowriad for some insight. This appears to be more of an implementation problem than a design problem. Is this possible?
|
Page content can be accessed while dropdowns are open
Issue description
Sighted keyboard users who open either the Content Structure or
Navigation Block dropdowns find their focus trapped within these
dropdowns until they either select an item or close the dropdown.
This suggests the idea is to treat these dropdowns similar to modal
dialogs, in that users are not meant to move out of the dropdowns in any
linear fashion. However users of assistive technologies such as screen
readers and speech recognition can find themselves interacting with
elements outside the dropdowns unexpectedly.
Speech recognition users may unintentionally activate elements on the
page which are hidden by the open dropdowns, as these are still
available to speech recognition.
Screen reader users can browse their way out of the dropdowns without
realising they have left, and they end up in the page (and not, perhaps
as expected, on the next item in the Editor Top Bar). Because focus
reaches an otherwise-hidden "Open Publish Panel" button, a user
attempting to move backwards back into the dropdown content, especially
by Shift-Tab, find themselves instead moving backwards through the
entire editable document, and not back to the dropdown. This interferes
with expected navigation techniques.
Remediation Guidance
The ideal setup would be to have the dropdowns in source order with the
triggering button and the rest of the Editor Top Bar, and allow users to
Tab out of the menu straight to the next item in the Editor Top Bar.
For non-Tab navigation in assistive technologies, this will allow users
who have navigated away to simply go back to where they expect to be.
Then anything which moves the keyboard focus out of the dropdown (such
as a voice action, or Tab navigation away from it) should close the
dropdown.
Relevant standards
(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-28 in Tenon's report
The text was updated successfully, but these errors were encountered: