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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19279

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #1 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-10-07 02:14:05 UTC ---
(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.

-- 
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 Sunday, 7 October 2012 02:14:08 UTC