Bug triage sub-team thinks this is not a A11Y TF priority, can be worked out by original filer.

Wouldn't a better fix here be to change ARIA such that pointing @aria-labelledby or @aria-describedby at a link should allow the reader to follow said link?

No matter what the outcome of the @longdesc discussion is this seems like a useful feature. This would allow a longer description on elements that doesn't have @longdesc, as well as allow multiple descriptions, some of which are longer.

As comment 0 states, even the people on the HTML WG (me included) made the mistake of thinking that this was allowed. Given that the vast majority of the documents on the web does not pass a HTML validator without errors, I think we can safely assume adding another error to the validation will leave a vast majority of documents unaffected.

So while adding an error to the validation will possibly cause some number of people to go find an appropriate workaround, it will leave a larger set of documents with an erroneous link. On the other hand, adding the ability to point to a link would make a much much larger set of documents working better for AT users, while at the same time preventing authors from having to find workaround.

SUMMARY: It is correct to, in HTML5, treat ARIA 1.0 as it is specced.

DISCUSSION:
a)  There is an idea about a @aria-descriedAT for pointing to external sources:

http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Use_aria-describedby_for_internal_description_references_and_create_aria-describedat_for_external_description_references

b) If a change of aria-describedby is wanted, then the appropriate thing to do would be to file a bug against ARIA 1.0. 


c) Nevertheless, here is a short exploration of the idea to use aria-describedby to present links to the user:

In ARIA, @aria-describedby is made use of in the main step of the 'accessible name computation', namely in the socalled 'text alternative computation'. 

http://www.w3.org/TR/wai-aria/complete#textalternativecomputation

And the presentation of links or other markup element semantics, is not part of the text alternative computation step. In the text alternative computation step, the idrefs of the current element's aria-describedby is just one of many places were the text alternative could be taken from.

It seems *another* step is needed if in order to use it as link. However, my personal view is that it would be better to then add something like a @aria-describedAT because 

   1) by the mere opportunity to use an describedbAT attribute [perhaps the name could be improved - would @aria-href be better?], authors would not so easily suffer from the possible confusion - that you mention - that pointing to the link via aria-labelledby or -describedby could achieve the same thing. One would then see that there is an attribute for links and use that attribute.

   2) links need to be added consciously - it is no guarantee that the aria-describedby idrefs that happens to point to a anchor elements really *would* serve well as links. (And while aria-describedby can have several idrefs in its value, I am not sure that it would be useful if @aria-describedAT/@aria-href were able to take more than one URL.

 (In reply to comment #2)
> Wouldn't a better fix here be to change ARIA such that pointing
> @aria-labelledby or @aria-describedby at a link should allow the reader to
> follow said link? [...]

* Here you ask for a change of the ARIA feature.

> As comment 0 states, even the people on the HTML WG (me included) made the
> mistake of thinking that this was allowed. Given that the vast majority of the
> documents on the web does not pass a HTML validator without errors, I think we
> can safely assume adding another error to the validation will leave a vast
> majority of documents unaffected. [...]

* It is posible to have the view that "normal" validators shouldn't focus on ARIA errors *without* simultaneously demanding that ARIA should change how aria-describedby works.

As for what authors will misunderstand: Why do you believe that authors will, in particular, misunderstand the fact that links are "dead" whenever they are referenced via the ARIA-describedby intereface?

The thing is that aria-describedby has the same "issue" with <table> as it has with <a>. Namely: when the table is presented via the "aria-describedby interface", then the table is not presented to the user as a table, but as a plain and simple string.

I think that once authors understand the fact that ARIA very often turns things into dead text strings, then they are not anymore prone to think that @aria-describedby works anymore "well" together with links than it works with tabls.

(In reply to comment #2)
 
Through some off-bugzilla debate, I believe I have some better answers:

> As comment 0 states, even the people on the HTML WG (me included) made the
> mistake of thinking that this was allowed. Given that the vast majority of the
> documents on the web does not pass a HTML validator without errors, I think we
> can safely assume adding another error to the validation will leave a vast
> majority of documents unaffected.
   
The basis for this bug is the the assumption that idrefs of anchor elements will be *especially*  useless to use inside aria-describedby. Texts like  "please visit this page" are hardly useful as description of anything  inside the page within which the link is situated.

So the bug report is not based on the belief that authors will be especially prone to include idrefs of links inside aria-describedby and aria-labelledby. It is instead based on what is likely to be useful to the AT user. 

Also, I do think that we should at least please avoid that authors get the wrong ideas. It is enough to take @longdesc as example: Had the W3 HTML4 validator had URL valdiation, then misunderstanding that some developed (namely the belive it could contain text) would not have affected the HTMLwg in its work with speccing HTML5. 

The fact that HTML5 includes URL validation for all *valid* attributes that can take URLs, is a sign which shows that there is faith in performing attribute value validation. 

Meanwhile, the kind of warning I suggest for aria-describedby is not a normal error warning, but ratheer a "this is probably wrong" kind of warning.

(In reply to comment #5)

> So the bug report is not based on the belief that authors will be especially
> prone to include idrefs of links inside aria-describedby and aria-labelledby.
> It is instead based on what is likely to be useful to the AT user. 

To be consistent: ther are probably many other elements to which it would be useless to point. For example <link> elements. And <meta> elements ...

Actually, (In reply to comment #0)
>    However, this is not the case: According to ARIA 1.0, any element pointed to
> via @aria-labelledby and @aria-describedby, is presented to the user in the
> same way that the @alt attribute is presented. Thus, all the AT user would get,
> would be a dead link text - the text without the link.

Can you point to where in ARIA 1.0 it says this?

(In reply to comment #7)
> Actually, (In reply to comment #0)
> >    However, this is not the case: According to ARIA 1.0, any element pointed to
> > via @aria-labelledby and @aria-describedby, is presented to the user in the
> > same way that the @alt attribute is presented. Thus, all the AT user would get,
> > would be a dead link text - the text without the link.
> 
> Can you point to where in ARIA 1.0 it says this?

In comment #3, I pointed to section '5.2.7.3. Text Alternative Computation' in ARIA 1.0.

You will find that the entire parent section, '5.2.7. Accessible Name Calculation', describes @title, @alt, @aria-label as well as - as I said -  @aria-labelledby and @aria-describedby. All in one "chunk".

(In reply to comment #8)

And for that matter,  it also describes elements. All, IMHO, is said in the very start of '5.2.7. Accessible Name Calculation': [1]

]]
1. author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.

2. contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Note: Priority is defined by the text alternative computation algorithm.
[[

[1] http://www.w3.org/TR/wai-aria/complete#namecalculation

First, section 5.2.7.3 describes how to calculate a text alternative, not a description which is what aria-describedby is. Section 5.2.7.2 is what describes how to get a description and only says:

"An accessible description may be computed by concatenating the text alternatives for nodes referenced by an aria-describedby ... outlined below in the section titled Text Alternative Computation"

So I see no requirements on that that is how it must be done. In other words, I see no requirement that methods that produce more semantically rich descriptions can't be used.

Second, where does section 5.2.7.2 say to only use the text contents of the elements?

Third bullet in step 2.A says

"Check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative". Hence it says to use the native semantics of the elements unless overridden by aria- attributes by the earlier two bullets.


Of course, the best would be if the spec editors clarified what they meant. I.e. if they really wanted semantics to be dropped when following IDREFs in aria-describedby etc.

(In reply to comment #10)
> First, section 5.2.7.3 describes how to calculate a text alternative, not a
> description which is what aria-describedby is. Section 5.2.7.2 is what
> describes how to get a description and only says:
> 
> "An accessible description may be computed by concatenating the text
> alternatives for nodes referenced by an aria-describedby ... outlined below in
> the section titled Text Alternative Computation"
> 
> So I see no requirements on that that is how it must be done. In other words, I
> see no requirement that methods that produce more semantically rich
> descriptions can't be used.

Quoting your quote:

  "outlined below in the section titled Text Alternative Computation"

'Text Alternative Computation' is the section I spoke about.  First point in the Text alternative computation mentions both aria-labelledby and aria-describedby:

" 1. Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby [snip]"

But I agre with you a little bit that aria-describedby is not as well described as aria-labelledby. (But then, I also think that they could have been more clear about @alt.)

> Second, where does section 5.2.7.2 say to only use the text contents of the
> elements?
> 
> Third bullet in step 2.A says
> 
> "Check for the presence of an equivalent host language attribute or element for
> associating a label, and use those mechanisms to determine a text alternative".
> Hence it says to use the native semantics of the elements unless overridden by
> aria- attributes by the earlier two bullets.

It says to use the native semantics for a specific purpose: "to determine a text alternative". And the example it gives is @alt (which is just the host language variant for aria-label).

Step 2C should be very relevant to you, as it speaks about collecting text from elements:

"2C Otherwise [snip] text is collected from descendant content [snip]. The text alternatives for child nodes will be concatenated [snip]"

This the wording "will be concatenated" tells to me that the elemetns will presented as text.

Ok, so it seems like we agree that the ARIA spec does not prescribe that the elements pointed to by aria-describedby should be treated as just their textnodes concatenated. Exposing the semantics of the elements it points to is allowed.


As for aria-labelledby, it sounds like you are doing an awful lot of interpretation. First off, saying that "text alternative" automatically means that it has to be a string that doesn't contain semantics is a stretch to me.  Why couldn't "text" as opposed to for example visual images?

Are you basing your interpretation on something I'm missing?

Also, I agree that step 2.C says that the textual content of an element is the textual contents of its children concatenated. However that step doesn't say how to build the text contents of the children, so it could certainly include the semantics of the children. Also, step 2.C only applies if step 2.A and 2.B hasn't yielded anything, and I those are the steps that bring up semantics.

Even if we grant the original premise, it's not clear to me that this should be fixed in HTML rather than being fixed in ARIA. Surely we don't want every host language to have to repeat this constraint?

(In reply to comment #12)
> Ok, so it seems like we agree that the ARIA spec does not prescribe that the
> elements pointed to by aria-describedby should be treated as just their
> textnodes concatenated. Exposing the semantics of the elements it points to is
> allowed.

Yes, ARIA has some encouragement to reveal markup semantics:

ARIA 1.0 says (http://www.w3.org/TR/wai-aria/complete):

landmark (abstract role)
#
A region of the page intended as a navigational landmark.
Assistive technologies SHOULD allow the user to quickly navigate to 
landmark regions. Mainstream user agents MAY allow the user to quickly 
navigate to landmark regions.

ARIA implemenation says: (http://www.w3.org/TR/wai-aria-implementation/)

Note that aria-describedby may reference structured or interactive 
information where users would want to be able to navigate to different 
sections of content. User agents MAY provide a way for the user to 
navigate to structured information referenced by aria-describedby and 
assistive technology SHOULD provide such a method.


But I still think the issue described in comment #0 is important, and related to - for instance - the importance that the HTML5 work has placed on uniformity between browser due to the fac that authors typically only test in a single web browser. 

Likewise, if one AT presents markup, while another present 'string', and an author is testing in only an AT which presnts it as string - or only as markup, then it is likely that the content pointed to by ARIA will be work suboptimal, in that kind of AT that  does not work like the one the author was testing.

E.g. imagine that aria-describedby points to a table - user experience will be completely different depeninding on whether the AT present it as mark-up or as 'string'.

HTML5 ought to put as much weight on uniformity in this field as in other fields, no?

> As for aria-labelledby, it sounds like you are doing an awful lot of
> interpretation. First off, saying that "text alternative" automatically means
> that it has to be a string that doesn't contain semantics is a stretch to me. 
> Why couldn't "text" as opposed to for example visual images?
> 
> Are you basing your interpretation on something I'm missing?

My interpretation is based on experience with how AT is presenting ARIA. But also on the ARIA specifications, which uses special encouragmeent language - SHOULD - whenever it wants to emphasize that markup semantics could be presented.

That said: For the IMG element, then if the IMG is kept inside e.g. <strong>, then the words in the @alt should probably be presented with strong emphasiz. At least if the IMG could be given role=text (this is a role that Steve proposed in wai-xtech@ recently.) That's an example of where structural markup merely provides a presentational enhancement. But if aria-labelledby points to e.g. a table, then it would constitute the same problem as if aria-describedby did it - see above about the probelms whenever AT interpret the same thing differently. Even for @longdesc we have this: one of the arguments against @longdesc is not every AT or browsers presents it to the user, leading to different experience etc.

> Also, I agree that step 2.C says that the textual content of an element is the
> textual contents of its children concatenated. However that step doesn't say
> how to build the text contents of the children, so it could certainly include
> the semantics of the children. Also, step 2.C only applies if step 2.A and 2.B
> hasn't yielded anything, and I those are the steps that bring up semantics.

Sometimes it is useful to present things as text, compared to mixing in further semantics. It is not completely clear to me what you have in mind. But let me take an example: 

AT currently have poor support for the OBJECT element, they don't read the fallback, typically. However, by pointing to the OBJECT element with aria-describedby, then one can make the AT read that content. Currently, this means that the content is read as a string. Which is already progress. But what if the fallback is a table that represents a graphical representation of the same data? It would then be great if it was possible to make AT read it as table. That said: the very best thing would have been if AT simply interpreted the OBJECT correctly. 

The most important argument against presenting the content of aria-describedby as structured text is, IMHO, the issue of interoperability. Authors must be given clear guidance about how it works, and must be able to expect how it is to be intepreted and presented. 

But a quite good argument in favor of presenting it as markup, could be this: Steve has said that at least one AT developer wants the browser to do all the dirty work. And clearly, if the content is interpreted as markup, then browsers already have ways to handle markup, obviously.

mass-moved component to LC1

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: Rejected
Change Description: no spec change
Rationale: If this is anywhere, it should be in ARIA, not in every host language.