This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(In reply to comment #0) > 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. FIRST: In the A11Y minutes it is some attention to the word "active": "elements are hidden from presentation but still active yet not focusable". To me the attention to the word "active" is a bit off because, an element with @hidden set is as "active" as any element with display:none set. The spec explains this well when it says that scripts etc works even if they are hidden. That said: The word 'active' is associated with links - *:link:active{color:red}. May the spec could simply pick another word - one that wasn't possible to associate with focus and firing of links. SECOND: Why this discussion about what happens to focus? There isn't any doubt what happens if you do #element{display:none} Is there? I ask because that is all @hidden does - it gives the element a {display:none}. THIRD: The question is incorrect. Since it is not @hidden that removes the focusability but the associated display:none that does the trick, then, if an author does *[hidden]#element{display:block}, we currently get different results for AT users and none-AT users: none-AT: visible *and* focusable to AT: hidden *AND* focusable And that, I agree, is a real concern. Perhaps this is also the *real* concern of this bug? SOLUTIONS TO THE THIRD PROBLEM: Note that @hidden was added to HTML5 before ARIA was incorporated in HTML5. And when ARIA was incorporated, then it was decided to associate @hidden with aria-hidden="true". To me, that seems unnecessary - and complicating as it means that simply unhiding such elements via CSS will keep them unhidden from A11Y users. Thus, @hidden, as currently specced, forces authors to manipulate the DOM via JavaScript. As told in bug 19277, the problem might be solved by simply *delinking* @hidden from @aria-hidden="true". See: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277#c13 Last I checked, no ATs in use seemed to actually associate @hidden with aria-hidden="true". (However, I have it from Steve that some A11Y APIs might have started to do so - despite that AT don't do it, yet.) So, *this* seems to be the right moment if we want to delink @aria-hidden="true" from @hidden.
*** Bug 19405 has been marked as a duplicate of this bug. ***
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: No spec change. Rationale: The first of Michael's three options is what's implemented in the wild, and I believe the spec already covers this (in ยง7.4 Focus). Please let me know if you think additional spec work is necessary!