[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 #16 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-09-08 21:24:37 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #9)

> > [for] indirect relations between hidden *labels/captions* and some
> > visible content[…]the hidden label/caption content should be exposed

> Sounds like a good idea to describe the principle better. I will leave it to
>Ted & James to propose specific refinements, though!

Sure. 

> > (2)[…]very useful to include Steve's positive <label for> example[…]
> 
> I think <label for> isn't quite like the other cases. Reasons:
> 
> 1) <label> is expected to act as a short label which can be presented directly
> inline by assistive technologies, rather than a long description. Structure
> seems less obviously useful for labels than for long descriptions; labels often
> use intrinsically plain text mechanisms like alt="". I think this is a
> difference between text a screenreader would present inline, and text that
> would only be presented specifically on request. In the latter case, it seems
> more appropriate to potentially use more structure.

What's your point here? Is it that vendors should not spend energy on exposing
"full semantics" for <label for> because "plain text semantics" are good
enough?  If that is what it is, then I wonder: The alternative to not expose
the "full semantics" of <label for> is, I think, not "plain text semantics" but
to not pronounce it at all. Isn't that so? (This seems like a difference from
aria-describedby - where there is indeed a choice between plain text and "full"
semantics.)

> 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.

I thought that the backward id/for relation was the reason why Ted came up with
the somewhat vague phrase "indirect relations". At least, that was why I used
that phrase when I suggested what the principle seems to be. I agree that for
the other examples, then it is the "content" that points to its "label". But I
challenge that it is important which way the for/id relation goes. The
important thing is, it seems to me, whether it is the label or the content that
is hidden. I think there is only practical reasons behind the fact that the @id
sits on the <input id> instead of on on the <label for>: The <label for> does
almost always come *before* the <input id> and - when you click a label, then
you are taken to the <input id>. So the relationship between <label for> and
<input id> is extremely tight. Tighter than, for example, the relation between
a <td> and a <th>, I think. (<label> can even wrap around an <input> - and then
does not need id/for.)

> 3) Historically, it appears that hidden or display:none labels are not
> presented at all by assistive technologies, at least in my testing. So the
> change wouldn't just be flattened to structured, it would be not presenting to
> presenting. That's a potential compatibility risk. I think the other positive
> examples are cases where there is already something exposed, but it may be
> beneficial not to force it to be flattened.

I don't think that is correct: In case of the <map> example, then <area>
children are not flattened … Otherwise, they would not have functioned as links
… Which serves to make a point: I think that "full semantics" might be
misleading. It would be better to think "not [completely] flattened semantics".
For example, in case of aria-describedby (since we have discussed that so much
...), one could imagine that AT would start to interprest the @lang attribute
long before they start to express all other semantis, not? And ditto for <label
for>.

Thus, I think it is a false assumption if - as I now perceive - you think that
we here discuss whether or not to *increase* the semantics for things that are
already exposed as flattened. I think, what we do here is the usual: Describe
existing practise *and* prescribe some new practise.

I should clarify one thing - and may be that is related to the reverse
relationship that you mentionend above: I agree that the @for in <label for>
does not count as something that overrule the @hidden="". What I mean is this:
*Only* when the user enters the <input id> to which the hidden <label for>
points, should it be exposed. Remember, that when <label for> is *visible*,
then AT (at least VoiceOver) exposes it twice: Once when the <label input>
element is presented and a second time when the <input id> is presented.

Yes, in VoiceOver, a hidden <label for> is not exposed. And it would be useful
to know how other AT behave. However, we describe here what AT are encouraged
to do. And it seems to me that Steve's example was very meaningful.

-- 
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 Saturday, 8 September 2012 21:24:38 UTC