W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2017

Re: Seeking clarity over user-experience

From: Florian Rivoal <florian@rivoal.net>
Date: Sat, 29 Apr 2017 22:21:00 +0800
Cc: John Foliot <john.foliot@deque.com>, public-webapps <public-webapps@w3.org>, "www-style@w3.org" <www-style@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>, CB Averitt <cb.averitt@deque.com>
Message-Id: <DAFBED78-8277-4D37-BAA5-6E9BD7D960BA@rivoal.net>
To: chaals@yandex-team.ru

> On Apr 29, 2017, at 19:59, chaals@yandex-team.ru wrote:
> 
> 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
Received on Saturday, 29 April 2017 14:21:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:42 UTC