[Bug 18744] drop WAI-ARIA scope restriction in the text adopted in ISSUE-204

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

--- Comment #20 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-09-09 22:37:47 UTC ---
(In reply to comment #19)
> (In reply to comment #15)
> > 2) <label> has the ID association backwards; the auxiliary label/description
> > references the content rather than the other way around. So that makes it
> > unlike any of the other cases we are thinking about. I think there's a
> > difference between letting references point to hidden elements and letting
> > hidden elements create references. For example, you might have multiple labels
> > pointing to the same control and hide all but the currently relevant one.
> 
> Doubt the direction of the reference makes any difference here.

I think Maciej had a point. That said: I think Benjamin has a point as well.

The <label for> element seems special. And it is only by acknowleding that it
is special that we can, eventually, include it for AT users. How is it special?
Well, perhaps a @uselabel on the <input> rather htan @for on the <label>, might
have been more ideal? It is, in a way, unfortunate that AT users should be less
lucky *just* because the @for points the wrong way, not?

QUESTION: Speaking about the examples in Ted's current text proposal,
          then do we expect 

    * that AT just hide <th hidden="" id="foo"> elements 
      and the <map name="foo"  hidden="" id="foo"> from *user* 
      but actually keep them ready to be presented with full semantics 
      to the user when/if  needed? 
    * or that the full semantics are generated "on the fly" 
      just in the moment  they are needed?

# In the latter case, then we can't expect AT to *find* the label, I think. 
# But in the former case, then the AT would only need to check if it 
  had stored a hidden <label for=foo> somewhere - and use it if 
  it exists.

Not?

-- 
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, 9 September 2012 22:37:49 UTC