- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 17 Mar 2016 12:08:15 -0400
- To: Fred Esch <fesch@us.ibm.com>
- Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, "White, Jason J" <jjwhite@ets.org>, ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>, Bryan Garaventa <bryan.garaventa@whatsock.com>
Thanks Fred,
On 2016-03-16 9:50 AM, Fred Esch wrote:
> When doing a widget, it often makes sense to only have one element
> with tabindex 0 at a time. That allows the user leave the widget using
> tab or shift tab. If you are using arrow keys to move within the
> widget, when you handle an arrow key event, you switch the moved to
> element to tabindex 0 and the element you moved from to tabindex -1.
> The developer can call the onfocus function on the moved to element as
> part of the key event handling.
This is the "roving" tabindex technique as described in the APG [1]. It
doesn't suffer from the problem described in the HTML5 spec, since it
provides navigation for a keyboard-only user.
The HTML5 spec is addressing the case where there is no such
provision. Using your example: if there was no script for the arrow
keystrokes, then a keyboard-only user would be stuck, since there would
be no way they could navigate among the elements with a negative
tabindex. In that case, HTML5 suggests that the "... user agent would
be well justified in allowing the user to tab to the control
regardless". [2]
How the user agent determines this condition is beyond me. A better
approach would be to advise the author to make provision for
keyboard-only users.
[1]
http://rawgit.com/w3c/aria/master/practices/aria-practices.html#kbd_general_within
[2] https://www.w3.org/TR/html5/editing.html#negative-tabindex,
specifically the note.
--
;;;;joseph.
'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
- C. Carter -
Received on Thursday, 17 March 2016 16:08:43 UTC