- From: <bugzilla@jessica.w3.org>
- Date: Thu, 04 Oct 2012 21:18:00 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19279 Summary: What happens to focus when element with focus has @hidden set Product: HTML WG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: LC1 HTML5 spec AssignedTo: eoconnor@apple.com ReportedBy: cooper@w3.org QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org, public-html-a11y@w3.org The HTML Accessibility Task Force in discussion on 4 October 2012 http://www.w3.org/2012/10/04-html-a11y-minutes.html#item02 identified that it was not clear what happens to the keyboard focus if an element with the focus has the @hidden attribute set - which should make it unable to have focus. Does the element still have focus but the user can't see it? Does the focus move somewhere, and if so where? Does the focus disappear? Can the user recover it? In discussion, the participants in the telecon agreed that the spec should say explicitly what should happen in this situation. There was not detailed discussion or strong opinions about what should happen, as long as the spec is clear. Therefore what should be specified will need to be determined in further processing of this bug - this bug merely identifies that *something* needs to be specified. Following are some options this filer can imagine: * The focus remains on the element that is now hidden, and the user agent is able to report where the focus is (perhaps with a warning that it's on hidden content). However, as with any hidden element, events on the element can no longer be actuated. When the user advances the focus, the focus moves to the next focusable element after the hidden element in the focus order. * The focus is automatically moved to the focusable element that is either next or previous (one or the other but which needs to be decided) in the focus order. The user agent is able to inform the user that the focus has been moved and why. * The focus is moved to the page overall, and would restart at the beginning of the focus order when the user advances focus. With the first two options, there should probably be a reminder that if there is no subsequent focusable element to which to advance, that the focus would recycle back to the beginning automatically, just as happens with normal focus cycling. There also needs to be care in implementation particularly with the second option. If a single element is hidden, it is easy to move to the next focusable element automatically. However, if several elements are hidden at once or some other change is made to the focus order at the same time, what was the "next" element before the element was hidden may no longer be the "next" one after it was hidden. The focus should probably move to the next focusable element in the new focus order. For this to work, the spec probably also needs to specify that hidden elements retain a position in the focus order even though they're not in fact focusable, so that a "next" element can be determined. This would of course be the position if the element is un-hidden without having to shuffle everything else. The recommendation of this filer is that the spec adopt the second option, automatically moving the focus to the next focusable element, after all caveats for changes of focus order and focus cycling have been dealt with, and with the user agent possibly informing of the change. But that is one opinion, the most important is to say something about this case. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Thursday, 4 October 2012 21:18:01 UTC