Re: Keyboard interaction and W3C specs...

Thanks, Charles - I've put this on our f2f agenda for Monday afternoon and I look forward to your joining us to discuss further.

Dan



> On 14 Apr 2015, at 17:01, chaals@yandex-team.ru wrote:
> 
> Hi,
> 
> There are a lot of W3C specifications, and there are a number of implemenations in browsers, perhaps more in editors, and gazillions of web apps - some driven by libraries, some not - which have approached the problem of people who are intearcting with an application on the web, but not by pointing to something and clicking on it.
> 
> For some people this is a pretty key question - whether it's about the time it takes to move a mouse, or the cost in upper-body strength, or being able to accurately find out where the thing you want to click is.
> 
> The current situation is that HTML assumes the common way to navigate is pressing tab repeatedly to get to things - which is false as well as a pretty pathetic way to navigate a complex application. There are also gazongabytes of javascript trying to deal with this. One serious problem they have is that interaction between scripts just breaks. There is accesskey - which IMHO offers a reasonable possible solution except that the browser implementation is terrible (well, in the best case it reaches the dizzying heights of "pretty bad").
> 
> This issue affects a lot of specs. CSS provides one behaviour for hovering and a different one for focusing, which is what happens with the keyboard. HTML has a pretty horrible tabindex mecahnism, that will probably be deprecated as a reflection of how it is often worse than the problem it tries to solve - SVG has a better approach but still not great. XHTML2 tried to deal with this, but again didn't manage to nail it.
> 
> In addition, the problem has clearly grown from keyboard vs mouse to the range of interactions - voice, gesture, touch, moving an on-screen pointer or focus - that in the 90s was only a wild guess at what might happen. So people understand the issue and why it would be nice if we did something useful to solve it.
> 
> This issue is one the HTML Accessibility Task Force would like help with [1]. As it happens the SVG task accessibility force has just started to look at navigation of complex SVG applications and charts - i.e. the same issue. They are building a growing set of "use case" SVG images [2] to use for considering the problem. 
> 
> It happens that I'd be able to attend your upcoming face-to-face meeting, and I'd be very grateful if you could put this on the agenda.
> 
> [1] https://www.w3.org/WAI/PF/HTML/wiki/Keyboard
> [2] https://www.w3.org/wiki/SVG_Accessibility links to various kinds of example. It might get updated with more - we've got a dozen there and about 4 dozen on github linked from that page - or we might move to a different place to document stuff.
> 
> cheers
> 
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>

Received on Tuesday, 14 April 2015 17:35:16 UTC