Re: Seeking clarity over user-experience

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/>

On 19 April 2017 at 23:55, <chaals@yandex-team.ru> wrote:

> 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.
>
> 19.04.2017, 23:16, "John Foliot" <john.foliot@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 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.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>
>
>
> --
> Charles McCathie Nevile - standards - Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>