W3C home > Mailing lists > Public > public-apa@w3.org > April 2017

Seeking clarity over user-experience

From: John Foliot <john.foliot@deque.com>
Date: Wed, 19 Apr 2017 16:15:47 -0500
Message-ID: <CAKdCpxzQ5Esm1oYnk8uwnY166S7tneL3xF3hYq_LekkqO+jmjg@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>, www-style@w3.org, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Cc: CB Averitt <cb.averitt@deque.com>
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

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

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

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

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


John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion
Received on Wednesday, 19 April 2017 21:16:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:02 UTC