- From: <chaals@yandex-team.ru>
- Date: Wed, 18 Feb 2015 13:53:54 +0300
- To: W3C Public HTML <public-html@w3.org>
Hi, the HTML spec doesn't really define keyboard interaction, although there are a few things in it that assume there is some, including tabindex, accesskey, focusable items, and contenteditable. In addition, ARIA (which is incorporated) provides lots of guidance on how keyboard interaction should work for various complex controls - and the examples provide piles of javascript to try and make this work. There are in fact lots of problems with the way things are. Javascript-based keyboard interaction is extremely common, demonstrating that the functionality is considered useful. It's also a mess, more or less inevitably interfering with default user interactions, because the developer failed to anticipate the range of possible user interactions. There is a strong - but fundamentally wrong - assumption that keyboard users navigate through the Web using the tab key. Although that is the "most common" approach in terms of deployed browsers, people who actually rely on keyboards often use additional functionality built into their browser, added through an extension, or provided by assistive technology to provide effective navigation techniques. There is a long-standing belief that accesskey cannot be used effectively. It is true that poor implementation in mainstream browsers makes it hard to know whether there *are* keyboard shortcuts available (the same problem applies to shortcuts implemented in javascript), often makes the "shortcut" relatively difficult to use, and does nothing to mitigate clashes with expected user interaction behaviour. Editing behaviour, especially in combination with IMEs for scripts too big to fit on a keyboard, such as "CJK" (chinese, japanese and korean) and many accented latin scripts runs into conflicts more easily. There seems to be an assumption that keyboards are used alone, rather than thoughtful integration to recognise the fact that in reality people usee various combinations of keyboards, pointers, cursors, gesture and voice controls according to their device, situation, and the task at hand. So whatever is necessary to develop in the space of interaction needs to provide the right level of abstraction to work with all these combinations. There are also some promising approaches to mitigating this. Pending a clear idea of how HTML is going to develop "after 5" the HTML accessibility Task Force has begun to look at this issue. From time to time it comes up on the Task Force teleconferences (Thursdays, 11am Boston time), and mailing list. There is an effort to gather relevant information in their wiki pages based at https://www.w3.org/WAI/PF/HTML/wiki/Keyboard and I am proposing to continue the discussion in the HTML WG, using [Keyboard] as a mail prefix, and gathering threads around the various groups working on things that impact this part of the platform (there are plenty of thoseā¦) cheers Chaals -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Wednesday, 18 February 2015 10:54:28 UTC