Need to expose elements that are "scrollable"

[scottaohara]

Firefox presently allows keyboard focus to navigate to elements with scrollable overflow (e.g., CSS overflow: auto | scroll, ensuring that instances where such elements do not have focusable descendants will be reachable / scrollable by keyboard users.

For elements which have strong implicit ARIA roles, it would be ideal if we could expose / standardize a "scrollable" announcement of some sort. Something to indicate why this element, which is likely otherwise a non-focusable element, is in the focus order.

For generics which are scrollable, this announcement is arguably even of greater importance.

The questions I have for scrollable generics are:

• is it enough to expose them as "scrollable' or a "scrollable container"?
• Should the generic role be swapped out for something else? group seems the most benign?

[scottaohara]

Today I met with @bkardell, @hidde and @argyleink concerning expectations around "content tabs" - a demonstration can be found: https://codepen.io/briankardell/pen/qBoVWNv

While discussing the current implementation a horizontally scrollable region of content, where there are some usability concerns with how sighted users who may not be using a mouse can quickly navigate past such a scrollable element, or to specific panels within the scrollable element. For instance, how might someone enter a specific section - via the in-page links that would navigate a user to a particular panel... but then the keyboard user would have to "tab" through any other visually hidden focusable elements within this container before they could exit it.

The idea of additional keyboard commands to allow for quick access to the different panels (scroll snaps) was mentioned, but also, keyboard commands to quickly navigate in/out of the scrollable container was brought up - which brings us to this issue where such functionality would also be welcome for scrollable regions in general - and thus this issue.

Essentially, a scrollable region/pane/group/whatever-it-would-be-called would allow for indicating to user that the element represents a scrollable container of longform content. It may contain multiple paragraphs or sections of content, which may also contain a number of focusable elements that could impede a user from quickly bypassing the region. While this would go beyond the scope of 'mapping', and thus would need to be specified elsewhere, the browser could implement keyboard commands to allow quick access to and from the last focusable element within such a scroll region, if not the region itself if it were to lack nested focusable elements. Doing so would mitigate against a divergence in usability for sighted mouse users and sighted keyboard users, where the former can quickly bypass such scrollable elements if they so choose, but keyboard users primarily using the Tab key would have to navigate through the scrollable regions content. Having explicit functionality beyond just announcing the content is "scrollable' would potentially solve for the feedback that AT users have provided of "why is this element announced as scrollable. what does that mean to me?" when elements have been made scrollable and focusable - introducing extra announcements for people using screen readers who otherwise don't interact with or have issues with scrollable elements in the same way that sighted keyboard users do.

---

Not directly related to the above, but related to this issue in general, @aardrian has written about Keyboard-Only Scrolling Areas which provides more commentary on the pros/cons of scrollable regions.

---

For anyone i have @ -mentioned, if I've left anything out that would be helpful to this thread, please post your thoughts. Thanks

cc @smhigley @jnurthen as you have both been involved in the above mentioned 'content tabs' open ui conversation, and would appreciate any thoughts you have here as well.

[aardrian]

Today I met with @bkardell, @hidde and @argyleink concerning expectations around "content tabs" - a demonstration can be found: https://codepen.io/briankardell/pen/qBoVWNv

This pen may be broken. In Firefox and Chrome it is just plain content, no scrolling boxes. The "explanation" link at the top is empty. Is this still undergoing development @bkardell?

On to the other bits...

Quick ideas for keys to address scrollable containers (ARIA regions or not):

1. a modifier for the Tab↹ key that appears only in scrolling areas.
   • for screens that disable scrolling on the <body> to implement their own custom scrolling, perhaps heuristics to account for that.
2. allowing the Esc key to exit the area by moving past it in the direction user was already moving.
   • likely a terrible idea, but since many scrolling regions are meant to visually "save space" like disclosure widgets on awkward FAQ pages, the context could be close enough.
   • all bubbling prevented.
3. building in group navigation (like Android's navigation clusters).
   • Ctrl + Tab↹ is for Android, but is already claimed by desktop browsers.
   • this is similar to my first suggestion, but for navigation all groups.
4. a browser-inserted "skip" control at the start and end of the scrolling area.
   • I am embarrassed for suggesting this, but, frankly, it is what a lot web devs have to do for content areas chock full of interactive bits, so there may be some familiarity.
   • assuming the control only "appears" when the scrolling container gets focus.

I don't really like any of these, but sometimes it easier to bat down bad ideas than come up with good ones, and those batting down conversations can lead to better ideas. I don't mind being the guy saying the wrong ideas if it gets the conversation going.

I am unaware of something native on OSes that already does this.

[bkardell]

This pen may be broken. In Firefox and Chrome it is just plain content, no scrolling boxes. The "explanation" link at the top is empty. Is this still undergoing development @bkardell?

I added the link to the explanation which is openui/open-ui#559 and related to https://bkardell.com/blog/SpicyUpdate.html

Unfortunately I would suggest not looking at the pen more that casually, and when you do make the window big (otherwise it is just regular content) - the reason being that as it is relying on some features we don't have good interop on yet and currently means that which particular browser it is broken in, and how is varying from week to week almost. Basically though, the idea is that the content area is just a horizontal scroll pane with scroll snapping and the "tabs" are just in page links. You can use the pen to understand the bits about tabbing and arrow keys and not currently much more than that.

[aardrian]

…make the window big…

Yup, that did it. Maximized and it did what you suggested. Thanks.

[aleventhal]

We are working on putting scrollable areas in the tab cycle in Chrome in 1444450.

I don't think we're going to expose an accessible name from contents -- they tend to be too long.

@jcsteh @cookiecrook do either of you have suggestions on how these should be exposed?
I suppose on IA2 we could expose a scrollable: horiz|vert|both object attribute.

[cookiecrook]

Does this mean:

<div style="overflow:scroll;"> 

…would get an implicit tabIndex DOM property value of 0? If so, would it sprout the content attribute, too?

Should it also snarf up/down arrow keys when focused, and if so, do they bubble up to the main scrollable web view once you've reach max or min scroll position?

[cookiecrook]

…and would that behavior change if it was overflow:auto; and the contents were short enough that it didn't need a scrollbar?

[aleventhal]

It doesn't sprout an implicit attribute AIUI. If there's no scrollbar, it's not in the tab order.
Firefox has had this behavior for a long time.

@masonf@chromium.org is working on it for Blink.

[scottaohara]

the difference between the chromium behavior i've seen vs firefox's behavior is that with firefox so long as the element's overflow causes scroll bars to render, the element will be in the tab order of the page.

but with chromium, the element will only be focused via tab if scrollbars are rendered (re: overflow:auto) AND if there are no tabbable descendants. I quite like this implementation for that reason.

[cookiecrook]

What about the arrow key question?

Should it also snarf up/down arrow keys when focused, and if so, do they bubble up to the main scrollable web view once you've reach max or min scroll position?

[cookiecrook]

Gecko issue where a screen reader user found this behavior unexpected:
https://bugzilla.mozilla.org/show_bug.cgi?id=1069739

[scottaohara]

there are comments in that issue though that illustrate why it's also a necessary feature, but i think Firefox could also improve that by not always focusing the scrollable element - but instead doing what chromium is going to do, and only make it tabbable if it has no tabbable descendants.

just quickly checking firefox, the up/down arrows only impact the focused container, or the parent scrollable container, if a descendant within is focused.

the implementation in chrome canary will scroll the larger document once the container's scrolling has hit the end points.

i can see pros/cons to either of those implementations.

[JAWS-test]

only make it tabbable if it has no tabbable descendants.

I think there are good reasons to have a scrollable container always in TAB focus order:

• the TAB-able element in the container can be an element that is operated with the arrow keys, e.g. a select element - then I cannot scroll the container with the arrow keys.
• the TAB-able element in the container can be at the end, so that when focus is received, the container is scrolled to the end. To read the content in the container, I have to scroll to the top first and then back down again
• for consistency with the containers without TAB-able elements.