Discussion:
Seeking clarity over user-experience
(too old to reply)
John Foliot
2017-04-19 21:15:47 UTC
Permalink
Raw Message
Greetings CSS and Web Platform Working Groups,

Recently, one of our Subject Matter Experts at Deque created a test page
that unearthed a... question. After a careful review of the specs (and a
quick double-check with our buddy Glazou), and he recommended to bring this
to you for some input, as there may be a gap here or unintended behavior
- an undefined collision in Daniel's words.

First, the test page can be found at
http://a11yideas.com/testcode/scrollareas.html

There are two scrollable <div> elements with no focusable elements
contained within. The first <div> has a tabindex="0", the second <div>
does not.

Both <div>s have the following CSS declaration:

.scroll {
background-color: #ddd;
height: 140px;
width: 200px;
overflow: auto;
padding: 6px;
margin: 10px;
}


The current spec <https://www.w3.org/TR/CSS2/visufx.html#propdef-overflow>
for 'overflow' states:

​​
The behavior of the 'auto' value is user agent-dependent, but should cause
a scrolling mechanism to be provided for overflowing boxes.


Our testing shows that, indeed, in every mainstream browser we've tested,
because the content is longer than the declared height of the <div> that
the browsers are adding the scroll bars.

HOWEVER, with the exception of Firefox, if a content author does not
explicitly also set the tabindex="0" to the <div> (even though the browser
has added scroll bars) that keyboard-only users cannot tab "into" the
scrollable <div>, nor can they scroll that <div>'s content via the keyboard
only.

As you can imagine, this is a significant accessibility concern. Yet, when
I read the spec, it doesn't seem to address this scenario, at least not
specifically.

At the heart of the question is: if a browser adds a function that requires
user-input/interaction, should the browser also be responsible for adding
that 'modified' element to the tab order when appropriate (like in this
example)?

Logic would suggest to me that the current Firefox behavior is the correct
behavior, since the user-agent (browser) is adding the scroll bars 'when
required' (per "auto"), and when the browser adds those scroll bars, that
the scroll bars should also be automatically added to the tab-order. But
the spec is silent on that, and to date the only browser that appears to be
doing this is FF.

Alan and Rossen, I know that the CSS WG is in Tokyo for a F2F this week,
and perhaps you might have time to discuss this there?

At this point, I am unsure where I should file a bug (if, indeed, a bug is
the right response), but today we have inconsistent behavior in the
browsers, and exclusive of Firefox, I believe there is an unintended but
serious accessibility miss in the current CSS Spec. Perhaps what the spec
should say is something like:

​
The behavior of the 'auto' value is user agent-dependent, but should cause
a tab-focusable scrolling mechanism to be provided for overflowing boxes.

However, I'll leave that to either CSS WG or Web Plat WG to work out:
ideally I'd like to just know what the *intent* was of either WG (and I'm
guessing that CSS WG is the better group to answer the question).

Currently, in the absence of a definitive declaration, here at Deque we
will be failing any scrollable <div> without tabindex="0", as without that
declaration the scrollable <div> is unusable to keyboard-only users, but
we'd love to have a specific spec to point to (and point our clients to as
well).

Thanks!

JF
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@deque.com

Advancing the mission of digital accessibility and inclusion
c***@yandex-team.ru
2017-04-19 22:55:21 UTC
Permalink
Raw Message
Steve Faulkner
2017-04-20 05:41:02 UTC
Permalink
Raw Message
Note: i wrote about this issue a while back: Short note on improving
usability of scrollable regions
<https://www.paciellogroup.com/blog/2016/02/short-note-on-improving-usability-of-scrollable-regions/>
and filed bugs on edge
<https://connect.microsoft.com/IE/feedbackdetail/view/2324891/css-overflow-auto-does-not-allow-scroll-via-keyboard>
and chrome <https://code.google.com/p/chromium/issues/detail?id=584618>

<https://www.paciellogroup.com/blog/2016/02/short-note-on-improving-usability-of-scrollable-regions/>

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>
Hi John,
I think this problem is, unfortunately, squarely an issue for the HTML
specification, and also means filing bugs on browsers if they aren't
already there.
Note that it isn't new: https://github.com/w3c/html/issues/292 describes
the problem, and shows that people have known about it for quite a while.
It certainly seems to me that Firefox has the right behaviour, and
everyone else doesn't.
For that reason, I will start a new thread about this on public-html - the
public email list for the HTML specification.
I also encourage the APA group to look carefully at the issue mentioned
above.
Greetings CSS and Web Platform Working Groups,
Recently, one of our Subject Matter Experts at Deque created a test page
that unearthed a... question. After a careful review of the specs (and a
quick double-check with our buddy Glazou), and he recommended to bring this
to you for some input, as there may be a gap here or unintended behavior
- an undefined collision in Daniel's words.
First, the test page can be found at http://a11yideas.com/
testcode/scrollareas.html
There are two scrollable <div> elements with no focusable elements
contained within. The first <div> has a tabindex="0", the second <div>
does not.
.scroll {
background-color: #ddd;
height: 140px;
width: 200px;
overflow: auto;
padding: 6px;
margin: 10px;
}
The current spec <https://www.w3.org/TR/CSS2/visufx.html#propdef-overflow>
​​
The behavior of the 'auto' value is user agent-dependent, but should cause
a scrolling mechanism to be provided for overflowing boxes.
Our testing shows that, indeed, in every mainstream browser we've tested,
because the content is longer than the declared height of the <div> that
the browsers are adding the scroll bars.
HOWEVER, with the exception of Firefox, if a content author does not
explicitly also set the tabindex="0" to the <div> (even though the browser
has added scroll bars) that keyboard-only users cannot tab "into" the
scrollable <div>, nor can they scroll that <div>'s content via the keyboard
only.
As you can imagine, this is a significant accessibility concern. Yet, when
I read the spec, it doesn't seem to address this scenario, at least not
specifically.
At the heart of the question is: if a browser adds a function that
requires user-input/interaction, should the browser also be responsible for
adding that 'modified' element to the tab order when appropriate (like in
this example)?
Logic would suggest to me that the current Firefox behavior is the correct
behavior, since the user-agent (browser) is adding the scroll bars 'when
required' (per "auto"), and when the browser adds those scroll bars, that
the scroll bars should also be automatically added to the tab-order. But
the spec is silent on that, and to date the only browser that appears to be
doing this is FF.
Alan and Rossen, I know that the CSS WG is in Tokyo for a F2F this week,
and perhaps you might have time to discuss this there?
At this point, I am unsure where I should file a bug (if, indeed, a bug is
the right response), but today we have inconsistent behavior in the
browsers, and exclusive of Firefox, I believe there is an unintended but
serious accessibility miss in the current CSS Spec. Perhaps what the spec
​
The behavior of the 'auto' value is user agent-dependent, but should cause
a tab-focusable scrolling mechanism to be provided for overflowing boxes.
ideally I'd like to just know what the *intent* was of either WG (and I'm
guessing that CSS WG is the better group to answer the question).
Currently, in the absence of a definitive declaration, here at Deque we
will be failing any scrollable <div> without tabindex="0", as without that
declaration the scrollable <div> is unusable to keyboard-only users, but
we'd love to have a specific spec to point to (and point our clients to as
well).
Thanks!
JF
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
Advancing the mission of digital accessibility and inclusion
--
Charles McCathie Nevile - standards - Yandex
Florian Rivoal
2017-04-27 11:24:49 UTC
Permalink
Raw Message
@chaals, Why is that an issue for HTML? That seems tricky from a maintenance point of view. If CSS adds more similar mechanism or variants of what we already have, it would be much simpler that CSS would also be the spec having to define what happens with tab-focusing.

I would only expect HTML to provide a hook to just let us say "become tab-focusable" and let the CSS spec point to HTML for what that means, but define when it should happen when that depends on layout.

—Florian
Hi John,
I think this problem is, unfortunately, squarely an issue for the HTML specification, and also means filing bugs on browsers if they aren't already there.
Note that it isn't new: https://github.com/w3c/html/issues/292 <https://github.com/w3c/html/issues/292> describes the problem, and shows that people have known about it for quite a while.
It certainly seems to me that Firefox has the right behaviour, and everyone else doesn't.
For that reason, I will start a new thread about this on public-html - the public email list for the HTML specification.
I also encourage the APA group to look carefully at the issue mentioned above.
Post by John Foliot
Greetings CSS and Web Platform Working Groups,
Recently, one of our Subject Matter Experts at Deque created a test page that unearthed a... question. After a careful review of the specs (and a quick double-check with our buddy Glazou), and he recommended to bring this to you for some input, as there may be a gap here or unintended behavior - an undefined collision in Daniel's words.
First, the test page can be found at http://a11yideas.com/testcode/scrollareas.html <http://a11yideas.com/testcode/scrollareas.html>
There are two scrollable <div> elements with no focusable elements contained within. The first <div> has a tabindex="0", the second <div> does not.
.scroll {
background-color: #ddd;
height: 140px;
width: 200px;
overflow: auto;
padding: 6px;
margin: 10px;
}
​​The behavior of the 'auto' value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes.
Our testing shows that, indeed, in every mainstream browser we've tested, because the content is longer than the declared height of the <div> that the browsers are adding the scroll bars.
HOWEVER, with the exception of Firefox, if a content author does not explicitly also set the tabindex="0" to the <div> (even though the browser has added scroll bars) that keyboard-only users cannot tab "into" the scrollable <div>, nor can they scroll that <div>'s content via the keyboard only.
As you can imagine, this is a significant accessibility concern. Yet, when I read the spec, it doesn't seem to address this scenario, at least not specifically.
At the heart of the question is: if a browser adds a function that requires user-input/interaction, should the browser also be responsible for adding that 'modified' element to the tab order when appropriate (like in this example)?
Logic would suggest to me that the current Firefox behavior is the correct behavior, since the user-agent (browser) is adding the scroll bars 'when required' (per "auto"), and when the browser adds those scroll bars, that the scroll bars should also be automatically added to the tab-order. But the spec is silent on that, and to date the only browser that appears to be doing this is FF.
Alan and Rossen, I know that the CSS WG is in Tokyo for a F2F this week, and perhaps you might have time to discuss this there?
​The behavior of the 'auto' value is user agent-dependent, but should cause a tab-focusable scrolling mechanism to be provided for overflowing boxes.
However, I'll leave that to either CSS WG or Web Plat WG to work out: ideally I'd like to just know what the *intent* was of either WG (and I'm guessing that CSS WG is the better group to answer the question).
Currently, in the absence of a definitive declaration, here at Deque we will be failing any scrollable <div> without tabindex="0", as without that declaration the scrollable <div> is unusable to keyboard-only users, but we'd love to have a specific spec to point to (and point our clients to as well).
Thanks!
JF
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
Advancing the mission of digital accessibility and inclusion
--
Charles McCathie Nevile - standards - Yandex
c***@yandex-team.ru
2017-04-29 11:59:22 UTC
Permalink
Raw Message
Florian Rivoal
2017-04-29 14:21:00 UTC
Permalink
Raw Message
Hi Florian,
When CSS decides something should become focusable based on layout, then IMHO they are extending HTML. The basic reason for something to be focusable is that it is an interactive HTML element, or it adds an attribute like tabindex or accesskey - all of which is obviously HTML.
For all these cases, I agree. But we were discussing the need to make something focusable when it becomes scrollable, so that keyboard users can operate the scrolling mechanism.

Whether or not something is scrollable seems to me to be a CSS question.
So yes, you're right, we could let CSS define this case if it is defining the mechanism, and add it as an extension to HTML [1].
If you think this is a preferred approach, please note that in https://github.com/w3c/html/issues/292 <https://github.com/w3c/html/issues/292> ...
I am not sure I understand what the point of defining something to be an HTML extension is, compared to simply using mechanisms defined by HTML.

We could even define this in CSS in generic terms, without hooking specifically into HTML, by simply requiring that scrollable elements must me made possible to operate to keyboard users, without specifying how.

—Florian

Loading...