The User Agent Working Group apprised of the issue.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0111.html

A link to UAAG is already included in the "Recommended reading" section <http://www.whatwg.org/html/#recommended-reading>. Is anything else required?

(In reply to comment #2)
> A link to UAAG is already included in the "Recommended reading" section
> <http://www.whatwg.org/html/#recommended-reading>. Is anything else required?

An embedded links seems to be prefer by users in at least one study. The Usability Lab at Wichita did some research into link location some time ago (It is Michael Bernard, Spring Hull, & Denise Drake's classic 2001 study). They studied academic type information - the sort you'd expect a user to read much on screen as they would on paper (ie skim first, then in detail, in the "right" order).

Their conclusions:

"Several observations can be made from this study. First, no significant differences between the four link arrangements were detected in terms of search accuracy, time, or efficiency. This suggests that the link arrangement for documents within a single frame does not have a great affect on its actual navigability."

"However, there were significant subjective differences between the link arrangements favoring the embedded links. That is, participants indicated that they believed that embedding the links within a document made it easier to navigate, easier to recognize key information, easier to follow the main idea of the passages, and promoted comprehension. Moreover, participants significantly preferred the Embedded link arrangement to the other arrangements. Conversely, placing links at the bottom of a document was perceived as being the least navigable arrangement, and was consequently least preferred."

"Although no significant objective differences were found, the consistent results of the subjective perceptions of link navigability, as well as general preference, suggest that the Embedded link arrangement is perceived as being the superior format for online documents within a single frame. For this reason, it is suggested that for documents using a format similar to the type tested in this study, embedded links should be considered."
http://www.surl.org/usabilitynews/32/links.asp

(In reply to comment #3)
> (In reply to comment #2)
> > A link to UAAG is already included in the "Recommended reading" section
> > <http://www.whatwg.org/html/#recommended-reading>. Is anything else required?
> 
> An embedded links seems to be prefer by users in at least one study. The
> Usability Lab at Wichita did some research into link location some time ago (It
> is Michael Bernard, Spring Hull, & Denise Drake's classic 2001 study). They
> studied academic type information - the sort you'd expect a user to read much
> on screen as they would on paper (ie skim first, then in detail, in the "right"
> order).
> 
> Their conclusions:
> 
> "Several observations can be made from this study. First, no significant
> differences between the four link arrangements were detected in terms of search
> accuracy, time, or efficiency. This suggests that the link arrangement for
> documents within a single frame does not have a great affect on its actual
> navigability."
> 
> "However, there were significant subjective differences between the link
> arrangements favoring the embedded links. That is, participants indicated that
> they believed that embedding the links within a document made it easier to
> navigate, easier to recognize key information, easier to follow the main idea
> of the passages, and promoted comprehension. Moreover, participants
> significantly preferred the Embedded link arrangement to the other
> arrangements. Conversely, placing links at the bottom of a document was
> perceived as being the least navigable arrangement, and was consequently least
> preferred."
> 
> "Although no significant objective differences were found, the consistent
> results of the subjective perceptions of link navigability, as well as general
> preference, suggest that the Embedded link arrangement is perceived as being
> the superior format for online documents within a single frame. For this
> reason, it is suggested that for documents using a format similar to the type
> tested in this study, embedded links should be considered."
> http://www.surl.org/usabilitynews/32/links.asp
> 

I don't understand how exactly you want the specification to change.

> I don't understand how exactly you want the specification to change.

The intent of this bug as described above seems to be:

To strike from the spec the sentence:

"User agents may also apply image analysis heuristics to help the user make sense of the image when the user is unable to make direct use of the image, e.g. due to a visual disability or because they are using a text terminal with no graphics capabilities." 

And replace it with a statement something like:

"For User Agent advice on techniques for repairing missing content please refer to the UAAG." 

And then link to UAAG. 

Is this correct, Shelley?

Ian, you might want to ask in the accessibility task force which portion of the UAAG document is best for HTML5 link to. Jim Allan and Kelly Ford are Chairs of the User Agent working group and we are lucky enough to have them as members of the Accessibility Task Force.

(In reply to comment #5)
> > I don't understand how exactly you want the specification to change.
> 
> The intent of this bug as described above seems to be:
> 
> To strike from the spec the sentence:
> 
> "User agents may also apply image analysis heuristics to help the user make
> sense of the image when the user is unable to make direct use of the image,
> e.g. due to a visual disability or because they are using a text terminal with
> no graphics capabilities." 
> 
> And replace it with a statement something like:
> 
> "For User Agent advice on techniques for repairing missing content please refer
> to the UAAG." 
> 

No.

Mixing directives to UAs and authors in the same section is a bad idea. 

I agree with striking the text as regards Issue 66. However, that is a separate bug/issue, though it tangentially related. 

During the Issue 66 discussion, several people made requests to add a link to UAAG within the sections related to UA implementation. This bug is documenting these requests. 

The UAAG 2.0 specification, section 3.4 does discuss "repairing" text alternatives, but that section does not entail image analysis heuristics, which is what is described in the section related to Issue 66. The UAAG 2.0 guidelines are far more practical. 

However, the information in UAAG 2.0 is purely UA specific in nature, and should be separate from the authoring guidelines and the general discussion of the HTML and the alt attribute.

A better place for the link would be in the UA section, or what would be part of the UA webcore split, if this split occurs.

(In reply to comment #6)

> Mixing directives to UAs and authors in the same section is a bad idea. 
> 
> I agree with striking the text as regards Issue 66. However, that is a separate
> bug/issue, though it tangentially related. 
> 
> During the Issue 66 discussion, several people made requests to add a link to
> UAAG within the sections related to UA implementation. This bug is documenting
> these requests. 
> 
> The UAAG 2.0 specification, section 3.4 does discuss "repairing" text
> alternatives, but that section does not entail image analysis heuristics, which
> is what is described in the section related to Issue 66. The UAAG 2.0
> guidelines are far more practical. 
> 
> However, the information in UAAG 2.0 is purely UA specific in nature, and
> should be separate from the authoring guidelines and the general discussion of
> the HTML and the alt attribute.
> 
> A better place for the link would be in the UA section, or what would be part
> of the UA webcore split, if this split occurs.

Yes, placing a link in a UA section makes good sense. Thanks for the clarification Shelley. 

This was marked as RESOLVED FIXED, without any note as to what was fixed, and where. 

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: http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-missing-alt doesn't seem to provide anything that the HTML5 spec doesn't already provide, except that the former is more vague (since it isn't specific to HTML). I don't understand how this would be an improvement or how it would result in browsers doing things better.

Whether we like it or not, a fact of life is that browser implementors don't follow links. (Nothing has made this point better than bz's e-mail to public-html a few weeks ago saying exactly this, especially given that bz is one of the most conscientious implementors in the industry.) Therefore, if we want to have an impact on browser vendors, leading to them making better more accessible browsers, replacing concrete suggestions with a link to an abstract document is not the way to go.

The bug-triage sub-team doesn't think this is a priority for the accessibility task force.