[Bug 19279] New: What happens to focus when element with focus has @hidden set

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 the QA contact for the bug.

Received on Thursday, 4 October 2012 21:18:01 UTC