Keyboard interaction and W3C specs...

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 16:02:18 UTC