Focusability of scrollable regions

[travisleithead]

@stevefaulkner, @ChumpChief

It is a UI accessibility requirement (on keyboard supporting platforms) that scrollable regions be operable (scrollable) using the keyboard. If this is achieved via making the region focusable by default and included in the default focus order, then it is a sane move.

Regards
SteveF

Travis Leithead travis.leithead@microsoft.com wrote:

I'd like to see scrollable regions added to the list of suggested elements which have the tabindex focus flag set by default to enable this scenario better. "Draggable" elements are already included in the list in a similar spirit. IE would be willing to make a change to this behavior if other browser vendors will also make this change.

Anyone from other browser constituents have an opinion? Steve, does this make sense from an Accessibility perspective?

See discussion at: http://lists.w3.org/Archives/Public/www-style/2014Jul/0050.html

from Matt (MSFT):

Hi all,

I've been investigating keyboard scrolling for scrollable regions within a page (i.e. overflow:scroll) which omit tabIndex, and in particular how they interact with focus. The current browser behaviors are highly non-interoperable with one another. For example:

• IE allows scrollable elements without tabIndex to be focused via mouse click, but they cannot be tabbed to.
• FF allows scrollable elements without tabIndex to be focused via tabbing to them, but not by clicking on them.
• Chrome does not allow scrollable elements without tabIndex to be focused via any means, but they can still be scrolled with keyboard if you click on them first.

I was looking at the definition of focusable areas and the tabindex focus flag. These specify that scrollable elements are focusable, but not suggested to have their tabindex focus flag set or be tab-accessible. This would imply that IE's behavior is currently compliant with the spec -- the element is focusable but not reachable by tabbing.

That said, I don't think this is great behavior. This means that users without a pointing device are generally unable to target and scroll these regions using only the keyboard. I'd like to see scrollable regions added to the list of suggested elements which have the tabindex focus flag set by default to enable this scenario better. "Draggable" elements are already included in the list in a similar spirit. IE would be willing to make a change to this behavior if other browser vendors will also make this change.

Thanks,
-Matt

[chaals]

Seems to have horrible inconsistency in implementation, probably won't be fixed in 5.1 timeline (sadly)...

[chaals]

chromium bug

MS Edge bug - @travisleithead @stevefaulkner this is "closed as can't reproduce" (583). Does that mean it actually works in Edge?

[stevefaulkner]

the bug was moved to https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7045483/ and is still open as far as i can tell

…

-- Regards SteveF Current Standards Work @w3c <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>

On 20 April 2017 at 09:28, chaals ***@***.***> wrote: chromium bug <https://bugs.chromium.org/p/chromium/issues/detail?id=584618> MS Edge bug <https://connect.microsoft.com/IE/feedbackdetail/view/2324891/css-overflow-auto-does-not-allow-scroll-via-keyboard> - @travisleithead <https://github.com/travisleithead> @stevefaulkner <https://github.com/stevefaulkner> this is "closed as can't reproduce" (583). Does that mean it actually works in Edge? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#292 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzBE-q68XZI7PkOBEMqTPNupBmmNCJkks5rxxc4gaJpZM4IRbZz> .

[AmeliaBR]

For comparison, this is the wording I used in SVG 2:

The following SVG elements are focusable in an interactive document. Any instance of such an element in a use-element shadow tree is also focusable. For the purpose of the HTML focus model, interactive user agents must treat them as focusable areas whose tabindex focus flag should be set:

• the document root element
• an ‘svg’ element which has zoom and pan controls
• any element (such as within a ‘foreignObject’) that generates a scrollable region
• ‘iframe’ elements that are browsing context containers
• ‘audio’ and ‘video’ elements with user controls
• any directly rendered element with a valid integer ‘tabindex’ attribute

In the case of user-agent supplied controls, the element may have more than one focusable area, for each sub-control.

In addition, all ‘a’ elements that are valid links are focusable, and their tabindex focus flag must be set unless the user agent normally provides an alternative method of keyboard traversal of links.

For the purpose of this issue, the important part is the third bullet: "any element...that generates a scrollable region".

This is still a proposed rec spec, with no comprehensive test suite, and not a lot of feedback from user agents. If a user-agent implementer came to me and said they had another way of making scroll regions keyboard operable, I would be happy to move that point down to the same paragraph as a links, and say that any scrollable element should be part of the tabindex unless there is a platform consistent alternative way of making it keyboard accessible.

[cynthia]

@frivoal might have something to say on this.

[frivoal]

These specify that scrollable elements are focusable, but not suggested to have their tabindex focus flag set or be tab-accessible

This subtle difference is not helpful, and I strongly believe that they should be focusable and tabbable.

Effectively, the work-in-progress spatial navigation spec needs this to work properly. We could change it to make it clear that this must be focusable via spatial navigation even if they're not reachable by tab navigation, but that seems really undesirable. I'd really like to minimize the difference between things that can be reached by different navigation methods.

[siusin]

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.