You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browsers have different native behaviors when it comes to elements made scrollable with CSS overflow:
Firefox: the scrollable element is focusable.
Webkit-based browsers (Chrome, Safari, Opera, etc.): the scrollable element is not focusable.
For keyboard users, it is essential to be able to scroll a scrollable element to see all its content. When the element contains focusable elements, more or less users are able to make the element scroll by tabbing through the focusable elements. However, when the scrollable element does not contain focusable elements, there's no way for keyboard users to scroll. See for example the Keyboard shortcuts modal: #41500
As said above, the underlying issue comes from different browsers behavior. Regardless, we should make sure keyboard users can always access the content of a Scrollable component.
There's a simple technique to remediate see this note by the Paciello group:
Add a tabindex=0 to include the scrollable element in the tab sequence for all browsers.
Add a clear focus style to the scrollable element.
This allows sighted keyboard users to move focus to the scrollable element and then use the arrow keys to scroll. Other native keyboard shortcuts e.g. Scrollbar, Shift+Scrollbar, Fn+Down arrow/Up Arrow work as well.
However, at this point, the element would be a silent tab stop for screen reader users. When tabbing to the scrollable element, nothing would be announced.
To remediate, an appropriate ARIA role and label need to be provided.
The Paciello group recommends to use role=region and an aria-label with a meaningful value. That seems fine to me, with a little drawback: an element with role=region and an aria-label becomes an ARIA landmark. As such, it will be listed by screen readers in the page landmarks. Ideally, landmarks should be used only to mark the main regions of a page. This seems a minor annoyance compared to the greater benefit users will get from being able to scroll.
By fixing the accessibility of the Scrollable component, we could also consider to re-use it in more places to fix issues like #41500.
One more thing: if the Scrollable element is made focusable, there will be the need to check if and how that may impact the focus.focusable and focus.tabbable DOM utilities from the @wordpress/dom package.
This is a great plan and definitely needed. I agree with your statement about the role="region" and aria-label usage. I find silent tab stops mildly disconcerting, particularly in a workspace/editing environment or when focus has shifted, like in the keyboard shortcut modal.
#47426 is going to introduce some of the logic needed for an accessible scrollable to fix bugs within the Modal component. That logic should be better abstracted here for the Scrollable component. As suggested in #47426 (comment) a hook would probably be the best approach.
Also, it would be great to have #41001 in place to see if the accessible Scrollable can use the useResizeObserver hook instead of a custom implementation of ResizeObserver.
Description
Browsers have different native behaviors when it comes to elements made scrollable with CSS overflow:
For keyboard users, it is essential to be able to scroll a scrollable element to see all its content. When the element contains focusable elements, more or less users are able to make the element scroll by tabbing through the focusable elements. However, when the scrollable element does not contain focusable elements, there's no way for keyboard users to scroll. See for example the Keyboard shortcuts modal: #41500
As said above, the underlying issue comes from different browsers behavior. Regardless, we should make sure keyboard users can always access the content of a Scrollable component.
There's a simple technique to remediate see this note by the Paciello group:
Short note on improving usability of scrollable regions
https://www.tpgi.com/short-note-on-improving-usability-of-scrollable-regions/
tabindex=0
to include the scrollable element in the tab sequence for all browsers.The Paciello group recommends to use
role=region
and anaria-label
with a meaningful value. That seems fine to me, with a little drawback: an element withrole=region
and anaria-label
becomes an ARIA landmark. As such, it will be listed by screen readers in the page landmarks. Ideally, landmarks should be used only to mark the main regions of a page. This seems a minor annoyance compared to the greater benefit users will get from being able to scroll.By fixing the accessibility of the Scrollable component, we could also consider to re-use it in more places to fix issues like #41500.
Worth also mentioning the technique to make scrollable elements accessible is already used in Core, see for example https://core.trac.wordpress.org/ticket/49211
Step-by-step reproduction instructions
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
The text was updated successfully, but these errors were encountered: