Bug 18744 - drop WAI-ARIA scope restriction in the text adopted in ISSUE-204
drop WAI-ARIA scope restriction in the text adopted in ISSUE-204
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC All
: P2 normal
: ---
Assigned To: Edward O'Connor
HTML WG Bugzilla archive list
: a11y, a11y_text-alt, aria
Depends on: 18793
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-30 14:55 UTC by Edward O'Connor
Modified: 2012-09-12 19:19 UTC (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edward O'Connor 2012-08-30 14:55:36 UTC
Currently, the spec says

> User Agents are encouraged to expose the full semantics of hidden
> elements to Assistive Technology when such elements are referenced
> from WAI-ARIA attributes such as aria-describedby.

Instead of specifically referring to WAI-ARIA here, we could generalize
this encouragement to other such cases. Something like this maybe:

> When a hidden="" element is related to another element by ID reference
> (e.g. with aria-describedby=""), User Agents are encouraged to expose
> the full semantics of the hidden="" element to Assistive Technology.

This might help alleviate PF's concern that HTML5 unduly specifies
changes to WAI-ARIA in this clause.
Comment 1 Michael[tm] Smith 2012-09-04 18:48:06 UTC
I added some proposed wording from James Craig over at https://www.w3.org/Bugs/Public/show_bug.cgi?id=18745
Comment 2 steve faulkner 2012-09-06 14:52:50 UTC
(In reply to comment #0)
> Currently, the spec says
> 
> > User Agents are encouraged to expose the full semantics of hidden
> > elements to Assistive Technology when such elements are referenced
> > from WAI-ARIA attributes such as aria-describedby.
> 
> Instead of specifically referring to WAI-ARIA here, we could generalize
> this encouragement to other such cases. Something like this maybe:
> 
> > When a hidden="" element is related to another element by ID reference
> > (e.g. with aria-describedby=""), User Agents are encouraged to expose
> > the full semantics of the hidden="" element to Assistive Technology.
> 
> This might help alleviate PF's concern that HTML5 unduly specifies
> changes to WAI-ARIA in this clause.

I would suggest that if the "(e.g. with aria-describedby="")" was removed and replaced with a native HTML example: e.g.

<label for="test" style="display:none">label</label>
<input type="text" id="test">

Then the jurisdiction issue would be removed, as the for attribute is defined in HTML
Comment 3 steve faulkner 2012-09-06 15:16:43 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Currently, the spec says
> > 
> > > User Agents are encouraged to expose the full semantics of hidden
> > > elements to Assistive Technology when such elements are referenced
> > > from WAI-ARIA attributes such as aria-describedby.
> > 
> > Instead of specifically referring to WAI-ARIA here, we could generalize
> > this encouragement to other such cases. Something like this maybe:
> > 
> > > When a hidden="" element is related to another element by ID reference
> > > (e.g. with aria-describedby=""), User Agents are encouraged to expose
> > > the full semantics of the hidden="" element to Assistive Technology.
> > 
> > This might help alleviate PF's concern that HTML5 unduly specifies
> > changes to WAI-ARIA in this clause.
> 
> I would suggest that if the "(e.g. with aria-describedby="")" was removed and
> replaced with a native HTML example: e.g.
> 
> <label for="test" style="display:none">label</label>
> <input type="text" id="test">
> 
> Then the jurisdiction issue would be removed, as the for attribute is defined
> in HTML

example should be:

><label for="test" hidden>label</label>
> <input type="text" id="test">
Comment 4 Joshue O Connor 2012-09-07 06:55:51 UTC
I am really glad to see some movement on this issue, and while the example needs to be 'mediated' shall we say, I like Edwards suggestion.
Comment 5 Michael[tm] Smith 2012-09-07 10:49:27 UTC
OK, with Steve's proposed refinement, we'd end up with this:

[[
Where accessibility APIs allow nodes to be marked as hidden, User Agents are
encouraged to expose the full semantics of hidden="" elements when they are
referenced via relationship attributes.
This allows Assistive Technologies to access the content structure upon user
request, while keeping the content hidden in all presentations of the normal
document flow.

The following example shows a hidden label element that is referenced by an input element, and whose full semantics could be exposed to Assistive Technologies while still remaining hidden in all presentations of the normal document flow.

  <label for="test" hidden>label</label>
  <input type="text" id="test">
]]
Comment 6 Joshue O Connor 2012-09-07 11:19:54 UTC
(In reply to comment #5)
> OK, with Steve's proposed refinement, we'd end up with this:
> 
> [[
> Where accessibility APIs allow nodes to be marked as hidden, User Agents are
> encouraged to expose the full semantics of hidden="" elements when they are
> referenced via relationship attributes.
> This allows Assistive Technologies to access the content structure upon user
> request, while keeping the content hidden in all presentations of the normal
> document flow.
> 
> The following example shows a hidden label element that is referenced by an
> input element, and whose full semantics could be exposed to Assistive
> Technologies while still remaining hidden in all presentations of the normal
> document flow.
> 
>   <label for="test" hidden>label</label>
>   <input type="text" id="test">
> ]]

+1 to Steves text.
Comment 7 John Foliot 2012-09-07 16:13:48 UTC
I remain completely opposed to this proposal.  My reasons are:

> This allows Assistive Technologies to access the content structure...

A foot switch, a one-handed keyboard, a mouth stick and software such as Dragon/Nuance's Naturally Speaking are all Assistive Technologies. How will the hidden content be exposed to the users of these technologies? The vague and undefined term "Assistive Technologies" as used here is inappropriate: if you mean screen readers, then say screen readers, otherwise this proposed technique must in fact "work" for all Assistive Technologies, such as those referenced above.

> User Agents are encouraged to expose the full semantics of hidden="" elements

AS I have continued to point out (and logged a Formal Objection around), there are certain "full semantics" that are extremely problematic with this current text, mostly centered around the <a> element.

Scenario: Susan is a low-vision user who uses ZoomText (an Assistive Technology that is both screen magnifier and ARIA-aware screen reader). She encounters a web page that has the following code:

<div hidden>
 <ul>
  <li><a href="">Link 1</a></li>
  <li><a href="">Link 2</a></li>
  <li><a href="">Link 3</a></li>
  <li><a href="">Link 4</a></li>
 </ul>
</div>

To "expose the full semantics" is to present to Susan an unordered list of 4 hyper-links. Because ZoomText is ARIA-aware, the screen reading part of the tool will announce those 4 links - however, what shall the "Zoom" part zoom to?  

As well, we have a WCAG requirement (2.4.7 Focus Visible http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible) that specifically mandates "...that there is at least one mode of operation where the keyboard focus indicator can be visually located." To meet this requirement then, those links cannot "...remaining hidden in all presentations of the normal
document flow" - they MUST be visually locatable or this technique is in direct and Willful Violation of WCAG.

If this Working Group wishes to propose a sub-set of semantic structures and markup that could be exposed to screen readers yet remain hidden in the "...normal document flow" (what is normal anyway?), then that might be worth investigating (for example, allowing <span lang="FR"> on hidden content might be very useful), however as currently presented I will remain opposed to this technique, and will leave my existing Formal Objection in place.
Comment 8 Joshue O Connor 2012-09-07 17:01:26 UTC
I don't know if I understand such fierce opposition John. The fact is no matter what 'term' is used much of the good practice that is used to support accessible content development for screen reader users will also be very good for other basic IO or serial input AT devices such as every single one that you mentioned; switches etc.

Exactly how the IO is mediated is often down to the software such as a combination of single input switch (of which there are many variations but the basic IO modality is the same) and scanning software such as the Grid or EZKeys or whatever.

I think the basic premise of peoples input/suggestions for this bug such as from Steve or James, is good. Actually how this content would be revolved is largely down to User Agent support - we just need to ensure that the spec allows vendors to make provision for the creation of accessible content - using this or indeed any other method.
Comment 9 Edward O'Connor 2012-09-08 03:01:10 UTC
Here's some new text that addresses both the jurisdiction issue captured in this bug and the technical precision issue of bug 18745. I'm pretty happy with how this addresses the various technical issues that have been raised. Looking forward to finding out what people think!



Accessibility APIs are encouraged to allow a way to expose structured
content while marking it as hidden in the default view. Such content
should not be perceivable to users in the normal document flow in any
modality, whether using Assistive Technology or mainstream User Agents.

When such features are available, User Agents may thus expose the full
semantics of hidden="" elements to Assistive Technology when
appropriate, if such content is referenced indirectly by an ID reference
or hash-name reference. This allows Assistive Technologies to access the
content structure upon user request, while keeping the content hidden in
all presentations of the normal document flow. Some examples of where it
would be appropriate for the structure of hidden="" elements to be
exposed to users of AT with such an API include:

 * a <map> referenced from <img usemap>
 * table headers referenced with the headers="" attribute

Cases where it would be inappropriate include

 * <a href> containing a hash name reference to a hidden="" element in
   the same document
 * <label for> referencing a hidden="" form element

Other specifications which define elements and attributes which may be
included in valid HTML documents (such as SVG, MathML, and WAI-ARIA) may
define how or whether this applies to their elements and attributes.
Comment 10 Joshue O Connor 2012-09-08 07:11:39 UTC
Thanks for that Edward. One of the issues that I am interested in is with the use of HTML content being hidden via the CSS declaration <display:none> etc. While this may be an issue for the CSS WG, there are many times where text strings hidden using this method can be of use to screen reader users and a way of showing/hiding this using ARIA 'as an override' to the CSS declaration - would be great. If it already exists if someone would point out a best practice example to me, I'd appreciate it. It may be a UA issue, and just a matter of joining the dots with an appropriate method.

(In reply to comment #9)
> Here's some new text that addresses both the jurisdiction issue captured in
> this bug and the technical precision issue of bug 18745.[....]

> Accessibility APIs are encouraged to allow a way to expose structured
> content while marking it as hidden in the default view. Such content
> should not be perceivable to users in the normal document flow in any
> modality, whether using Assistive Technology or mainstream User Agents.

While I don't agree with Johns stance on this issue, he does bring some interesting points (as usual ;-)

I'm not sure I know what 'normal' document flow means - the paragraph may benefit from removing the reference and rewriting it to:

"Such content should not be perceivable to users in any modality, whether using Assistive Technology or mainstream User Agents."
 
> When such features are available, User Agents may thus expose the full
> semantics of hidden="" elements to Assistive Technology when
> appropriate, if such content is referenced indirectly by an ID reference
> or hash-name reference. This allows Assistive Technologies to access the
> content structure upon user request, while keeping the content hidden in
> all presentations of the normal document flow. Some examples of where it
> would be appropriate for the structure of hidden="" elements to be
> exposed to users of AT with such an API include:
> 
>  * a <map> referenced from <img usemap>
>  * table headers referenced with the headers="" attribute

I'm not sure I understand the use case of the latter example. If table headers exist - why would they be hidden? If there is a valid use case then please let us know.
Comment 11 Maciej Stachowiak 2012-09-08 07:21:37 UTC
(In reply to comment #10)
> > 
> >  * a <map> referenced from <img usemap>
> >  * table headers referenced with the headers="" attribute
> 
> I'm not sure I understand the use case of the latter example. If table headers
> exist - why would they be hidden? If there is a valid use case then please let
> us know.

James told us about an example of this. The "Stocks" widget in the Mac OS X Dashboard uses hidden table headers. The layout is a table showing various pieces of stock info, but because it's such a well-known format, visible headers are not shown. However, header info is still useful when using a screen reader or other assistive technologies, as additional explanation of the columns.
Comment 12 steve faulkner 2012-09-08 07:29:57 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > > 
> > >  * a <map> referenced from <img usemap>
> > >  * table headers referenced with the headers="" attribute
> > 
> > I'm not sure I understand the use case of the latter example. If table headers
> > exist - why would they be hidden? If there is a valid use case then please let
> > us know.
> 
> James told us about an example of this. The "Stocks" widget in the Mac OS X
> Dashboard uses hidden table headers. The layout is a table showing various
> pieces of stock info, but because it's such a well-known format, visible
> headers are not shown. However, header info is still useful when using a screen
> reader or other assistive technologies, as additional explanation of the
> columns.

This is a scenario that we at TPG do encounter in our work, from time to time, and I consider that being able to reference hidden headers in this way would be a useful technique.
Comment 13 Joshue O Connor 2012-09-08 07:49:33 UTC
Thanks for that Maciej and Steve - thats good enough for me.
Comment 14 Leif Halvard Silli 2012-09-08 16:47:55 UTC
(In reply to comment #9)

At first, I was puzzled about the fact that Steve proposed a positive example (see comment #3) which included <label>,  wheras Ted proposed a negative example which included <label>. But then I saw that in Steve's case, it was the <label> that was hidden, whereas in Ted's case, it was the <input> that was hidden. 

   Having noted that diff, I'd like to suggest some improvements:

(1) Describe the principle. Summarized, we could say that Ted’s new text recommends that, in case of indirect relations between hidden  *labels/captions* and some visible content then the hidden label/caption content should be exposed. Whereas when visible label/caption content  reference hidden *content*, then the hidden content should not be exposed.  Could a summary along those lines be added to the text? I think it would be useful if readers were able to discover a pattern.

(2) Improve the positive examples by adding a <label> example: I think it would be very useful to include Steve's positive <label for> example - along side with Ted's negative <label for> example. If both examples are there, then it prompts readers to analyze and discover the difference.

(3) I think the text 

      """Cases where it would be inappropriate include""" 

should be congruent with the text about when it *would be* approriate. For example like this: 

      """Cases where it would be inappropriate for the structure
         of hidden="" elements to be exposed to users of AT with
         such an API include"""

(4) Regarding the negative examples, then they should be described more congruently with the positive examples. For the positive examples, then the hidden="" element is mentioned first: "a <map>" and "table headers". Please do the same for negative examples. For example like this:

]]
 * a hidden="" element referenced by a hash name in a [visible]
   <a href> within the same document
 * a hidden="" form element referenced by a [visible] <label for>
]]
Comment 15 Maciej Stachowiak 2012-09-08 20:00:27 UTC
(In reply to comment #14)
> (In reply to comment #9)
> 
> At first, I was puzzled about the fact that Steve proposed a positive example
> (see comment #3) which included <label>,  wheras Ted proposed a negative
> example which included <label>. But then I saw that in Steve's case, it was the
> <label> that was hidden, whereas in Ted's case, it was the <input> that was
> hidden. 
> 
>    Having noted that diff, I'd like to suggest some improvements:
> 
> (1) Describe the principle. Summarized, we could say that Ted’s new text
> recommends that, in case of indirect relations between hidden 
> *labels/captions* and some visible content then the hidden label/caption
> content should be exposed. Whereas when visible label/caption content 
> reference hidden *content*, then the hidden content should not be exposed. 
> Could a summary along those lines be added to the text? I think it would be
> useful if readers were able to discover a pattern.

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

> 
> (2) Improve the positive examples by adding a <label> example: I think it would
> be very useful to include Steve's positive <label for> example - along side
> with Ted's negative <label for> example. If both examples are there, then it
> prompts readers to analyze and discover the difference.

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.

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.

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.

 
> (3) I think the text 
> 
>       """Cases where it would be inappropriate include""" 
> 
> should be congruent with the text about when it *would be* approriate. For
> example like this: 
> 
>       """Cases where it would be inappropriate for the structure
>          of hidden="" elements to be exposed to users of AT with
>          such an API include"""
> 
> (4) Regarding the negative examples, then they should be described more
> congruently with the positive examples. For the positive examples, then the
> hidden="" element is mentioned first: "a <map>" and "table headers". Please do
> the same for negative examples. For example like this:
> 
> ]]
>  * a hidden="" element referenced by a hash name in a [visible]
>    <a href> within the same document
>  * a hidden="" form element referenced by a [visible] <label for>
> ]]
Comment 16 Leif Halvard Silli 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.
Comment 17 Leif Halvard Silli 2012-09-08 21:43:09 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #9)


> I think <label for> isn't quite like the other cases. Reasons:

Upon a second thought - and som brief testing that made me think ..., I can see your point. I think the most backward thing probably is that when the AT see an <input> with an @id, then it cannot know why that @id is there - whether it is references by a <label> or for some other reason. So I guess authors have to make sure the <label> is not hidden ...
Comment 18 Maciej Stachowiak 2012-09-08 21:49:30 UTC
(In reply to comment #16)
 
> 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.
> 

Actually, I agree with you that this is the goal. In particular, for <map> I believe it is existing practice to expose full semantics even when the map is hidden.
Comment 19 Benjamin Hawkes-Lewis 2012-09-09 21:41:26 UTC
(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.

You might have the same control referencing multiple descriptions and hide all but the currently relevant one, and in fact authors try to do this:

http://www.nvda-project.org/ticket/2597

Previously brought to the WG's attention:

http://lists.w3.org/Archives/Public/public-html/2012Aug/0212.html

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

Are you suggesting that <label for> should have the implicit semantics of @aria-labelledby but not when the label element is hidden with @hidden or display: none?
Comment 20 Leif Halvard Silli 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?
Comment 21 Maciej Stachowiak 2012-09-10 00:16:51 UTC
(In reply to comment #19)
> (In reply to comment #15)
> 
> > 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.
> 
> Are you suggesting that <label for> should have the implicit semantics of
> @aria-labelledby but not when the label element is hidden with @hidden or
> display: none?

Currently the Editor's Draft does not define any implicit ARIA semantics for the <label> element or its for attribute. 

I would guess this is because ARIA does not have a property that directly corresponds to the reversed label-for mapping as opposed to the usual labelled-by mapping. So you can't actually provide literally equivalent aria markup. You would not only need to imply aria-labelledby on the target 

It may be worth discussing whether the spec could in fact describe an equivalent ARIA semantic for <label for>, but that seems beyond the scope of this bug.

That being said, I do think a <label> element that is hidden should create no labeling association, but labels or descriptions referenced from non-hidden content actually should. The common principle being that the side creating the reference must not be hidden in order to create the reference.
Comment 22 John Foliot 2012-09-10 16:05:49 UTC
(In reply to comment #8)
> I don't know if I understand such fierce opposition John. The fact is no matter
> what 'term' is used much of the good practice that is used to support
> accessible content development for screen reader users will also be very good
> for other basic IO or serial input AT devices such as every single one that you
> mentioned; switches etc.

How? If you are sighted and using a foot switch and ZoomText, and the following content is hidden, how will this work?

<div id="hidden" hidden>
 <ul>
  <li><a href="this.html">This</a></li>
  <li><a href="that.html">That</a></li>
  <li><a href="other.html">The Other</a></li>
 </ul>
</div>

It's not just the vague reference to the term Asssitive Technology that irks me, but that a significant user-interaction is being left undefined. If we have learned anything with the @longdesc fiasco it is that if we do not specify how this user-interaction is to manifest, then we do not get a common user-experience, the technique is abused, misused and/or under-used, and a decade later a whole slew of engineers, not around from the previous round of discussions, seek to toss the whole mess out, citing alleged problems and a desire to re-invent the wheel.

Despite repeated requests and urging, everyone appears to be ignoring this particular elephant in the room.

> 
> I think the basic premise of peoples input/suggestions for this bug such as
> from Steve or James, is good. Actually how this content would be revolved is
> largely down to User Agent support - we just need to ensure that the spec
> allows vendors to make provision for the creation of accessible content - using
> this or indeed any other method.

In an earlier series of emails, I attempted to press Maciej to better explain how a sighted user, using a screen reading technology would be able to see this hidden content that was being read aloud.  Ultimately, he punted, wanting to have a telephone conversation with me (I accepted the offer, but my phone sits silent) - the only other response I got was that with VoiceOver activated, then the sighted user would also see the hidden content via what I understand to be some form of modal overlay.

This is all well and good when a screen reader is integrated with the OS and browser, but outside of the Mac/iOS platforms (and Google's attempt to integrate a screen reader with ChromeOS/ChromVox), I am unaware of efforts with any other OS or browser to actually provide for, say, the ZoomText user.

"FULL" Semantics includes supporting the <a> element, and WCAG 2 specifically mandates that all links must preserve visible tab focus. 

Until this dichotomy is addressed, I will remain resolute with my Formal Object against this decision. Until such time as this is clearly addressed and defined to respect the needs of sighted, keyboard-only users who may also benefit from these hidden hyperlinks, this proposal is fundamentally flawed.
Comment 23 Maciej Stachowiak 2012-09-10 16:48:36 UTC
(In reply to comment #22)
> 
> In an earlier series of emails, I attempted to press Maciej to better explain
> how a sighted user, using a screen reading technology would be able to see this
> hidden content that was being read aloud.  Ultimately, he punted, wanting to
> have a telephone conversation with me (I accepted the offer, but my phone sits
> silent) - the only other response I got was that with VoiceOver activated, then
> the sighted user would also see the hidden content via what I understand to be
> some form of modal overlay.

John, I think that is dishonest bordering on slanderous. Here is the email where I offered a phone conversation if there were further repetitions of the same questions:
<http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0169.html>

Here's the email where you noted that, and said that you preferred to have further public discussion, this is your last email in our exchange:
<http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0185.html>

Here is the email where I answered your new round of questions:
<http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0186.html>

You *never replied* to this final email, at which point I reasonably assumed the point was sufficiently explained. To claim I "punted" is not a fair characterization of the record. Rather, you stopped participating after I answered your last round of questions.

Incidentally, the email you never replied to explains pretty clearly some possible answers to your question, namely how a hidden description could be presented to a sighted or partially sighted user. I believe the latest proposed text in comment #9 also addresses your seeming concern that such text might be presented to a user who did not explicitly access a description: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744#c9>. That new text also avoids using aria-describedby as an example and explicitly defers to ARIA on that.

I'm still happy to provide further explanation by phone.
Comment 25 James Craig 2012-09-10 22:41:55 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #9)
> 
> > 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.)

While the typical use of <label> is merely for text labels, I frequently see labels containing links or other elements. I think the general principle of exposing content semantics is potentially useful here even for typically simple elements like <label>.
Comment 26 James Craig 2012-09-10 23:59:11 UTC
(In reply to comment #19)
> (In reply to comment #15)
> You might have the same control referencing multiple descriptions and hide all
> but the currently relevant one, and in fact authors try to do this:
> 
> http://www.nvda-project.org/ticket/2597
> 
> Previously brought to the WG's attention:
> http://lists.w3.org/Archives/Public/public-html/2012Aug/0212.html

I don't necessarily agree with that design pattern, but there is a potential here to have a more explicit way for users to switch this explicitly for the example you describe.

  aria-hidden="false"

Hides from accessibility APIs no matter if the content is shown or hidden. I think aria-hidden should override hidden="" in all cases, regardless of modality. The flipside applies, too: 

  <div hidden aria-hidden="false">…</div>

That is, specifically hidden from mainstream interfaces, but overridden so that that the structure is available in Accessibility APIs. (Disclaimer: to my knowledge, no Users Agents currently expose hidden content this way.)
Comment 27 James Craig 2012-09-11 00:00:00 UTC
(In reply to comment #26)
> (In reply to comment #19)
> > (In reply to comment #15)
> 
>   aria-hidden="false"

That first one was supposed to be aria-hidden="true"
Comment 28 Benjamin Hawkes-Lewis 2012-09-11 07:12:01 UTC
(In reply to comment #26 and comment #27)
> I don't necessarily agree with that design pattern

This is something I expected authors to try, because authors have for years tried to hide/show error messages for all modalities using "display: none". This is one of the use-cases @irrelevant/@hidden was supposed to address, back in the day.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Mar/0173.html

http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Aug/0479.html

>, but there is a potential
> here to have a more explicit way for users to switch this explicitly for the
> example you describe.
> 
>   aria-hidden="true"
> 
> Hides from accessibility APIs no matter if the content is shown or hidden.

If an element with @aria-hidden=true is referenced by @aria-describedby it still contributes to the computed accessible description.

http://www.w3.org/WAI.new/PF/aria/roles#namecalculation

http://www.w3.org/WAI.new/PF/aria/terms#def_hidden

Therefore it's not hidden from accessibility APIs … right?

The only way for the author to do what he was trying to do is add/remove the referenced element from the DOM or to add/remove the id from @aria-describedby.

> think aria-hidden should override hidden="" in all cases, regardless of
> modality. The flipside applies, too: 
> 
>   <div hidden aria-hidden="false">…</div>
> 
> That is, specifically hidden from mainstream interfaces, but overridden so that
> that the structure is available in Accessibility APIs. 

That does seem to be what the main spec says:

http://www.w3.org/WAI.new/PF/aria/states_and_properties#aria-hidden

FWIW the text in the UA implementation guide seems to be saying "host language semantics" like CSS "display: none" ("host language"? "semantics"?) win here however:

http://www.w3.org/WAI.new/PF/aria-implementation/#exclude_elements2

> (Disclaimer: to my
> knowledge, no Users Agents currently expose hidden content this way.)

I'm surprised this wasn't cited as a "feature at risk".

PFWG will wait for implementations of that before letting it pass CR … right?
Comment 29 James Craig 2012-09-11 17:19:29 UTC
(In reply to comment #28)
> (In reply to comment #26 and comment #27)
> > I don't necessarily agree with that design pattern
> 
> This is something I expected authors to try, because authors have for years
> tried to hide/show error messages for all modalities using "display: none".
> This is one of the use-cases @irrelevant/@hidden was supposed to address, back
> in the day.
> 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Mar/0173.html
> 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Aug/0479.html
> 
> >, but there is a potential
> > here to have a more explicit way for users to switch this explicitly for the
> > example you describe.
> > 
> >   aria-hidden="true"
> > 
> > Hides from accessibility APIs no matter if the content is shown or hidden.
> 
> If an element with @aria-hidden=true is referenced by @aria-describedby it
> still contributes to the computed accessible description.
> 
> http://www.w3.org/WAI.new/PF/aria/roles#namecalculation
> 
> http://www.w3.org/WAI.new/PF/aria/terms#def_hidden
> 
> Therefore it's not hidden from accessibility APIs … right?

Yes and no. The hidden node is completely hidden from the accessibility API, but the calculated label/desc of the element referencing it is exposed as a string property on the visible element. This bug, and Issue 204 is about encouraging APIs to allow exposing the semantic of hidden elements in a way that makes programmatic introspection of the structure possible, while still clearly marking them as hidden so that AT doesn't stumble upon that content at inappropriate times.

> The only way for the author to do what he was trying to do is add/remove the
> referenced element from the DOM or to add/remove the id from @aria-describedby.

Currently, yes.

> > think aria-hidden should override hidden="" in all cases, regardless of
> > modality. The flipside applies, too: 
> > 
> >   <div hidden aria-hidden="false">…</div>
> > 
> > That is, specifically hidden from mainstream interfaces, but overridden so that
> > that the structure is available in Accessibility APIs. 
> 
> That does seem to be what the main spec says:
> http://www.w3.org/WAI.new/PF/aria/states_and_properties#aria-hidden
> 
> FWIW the text in the UA implementation guide seems to be saying "host language
> semantics" like CSS "display: none" ("host language"? "semantics"?) win here
> however:
> 
> http://www.w3.org/WAI.new/PF/aria-implementation/#exclude_elements2
> 
> > (Disclaimer: to my
> > knowledge, no Users Agents currently expose hidden content this way.)
> 
> I'm surprised this wasn't cited as a "feature at risk".
> PFWG will wait for implementations of that before letting it pass CR … right?

You raise a good point which I will escalate in PFWG. The aria-hidden property has been most useful for marking visible elements as hidden, but there are certainly some good use cases for the flip side, too.
Comment 30 Edward O'Connor 2012-09-12 19:19:02 UTC
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: Accepted
Change Description: https://github.com/w3c/html/commit/ca896aab1f7a3ad54b36721c6a32da5cf243d65f
Rationale: Adjusted spec text per the chairs' request. This new text removes the WAI-ARIA scope restriction that was present in the old text.