1. Steven's proposal at http://www.paciellogroup.com/blog/misc/HTML5/textalternatives.html does a number of nice things. (Recc: adopt this general approach. Rationale is that the user agent and assistive technology support for the elements and attributes in question will be subject to change over time. It's good to have examples, but normative examples are problematic in many of these cases given the state of UA support. Currently, the spec includes roughly 15 pages of alt-related examples, far more extensive than examples provided for any other attribute. Because these concepts apply generally and should apply beyond the scope of the <img> element, the examples should be addressed in a separate section (ex. as an appendix or as part of 18.104.22.168.12. Regarding the specific examples, a number of them still provide conflicting advice from WCAG 2.0, should be reviewed for consistency with the WAI CG Consensus resolutions and should be updated to reflect ARIA integration when it is complete.
2. Regarding, "In a conforming document, the absence of the alt attribute indicates that the image is a key part of the content but that a textual replacement for the image was not available when the image was generated." Propose that, as with previous version of HTML, a valid text alternative be present for conformance with the specification. Refer to WAI CG Consensus Resolutions on Text alternatives in HTML 5.
3. The derivation of caption information in, "If the src attribute is set and the alt attribute is not," (http://dev.w3.org/html5/spec/embedded-content-0.html#the-img-element) lists title at the top of the list. Suggest that it instead be listed second, following the first <dt> of the parent <figure>.
4. The description of text alternatives should include a specific reference to WCAG 2.0 (http://www.w3.org/TR/WCAG/#text-equiv)
5. This element should include some mechanism to programmatically associate a long description with non-text content (ex. aria-describedby)
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:
Status: Did Not Understand Request
Change Description: no spec change
Rationale: Please file just one issue per bug.
Regarding #1, I do not see how the alt="" text advice applies to anything other than <img>. It seems very specific to <img> and seems like it would do the most good slap bang in the middle of that section, in the author's face, as it were. An appendix is too easy to ignore ("I'll read that accessibility stuff later").
Regarding #2, the spec already seems to say what you are asking for.
Regarding #3, why would the title="" attribute on the element itself be less good that the figure caption, given that there might be multiple images in the figure?
Regarding #4, WCAG is already mentioned in the "recommended reading" section. The #text-equiv part doesn't seem to say anything that isn't already covered in more detail by HTML5, though, so referencing it in that section doesn't seem especially useful to readers.
Regarding #5, what's wrong with aria-describedby?
The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.
This general issue has been escalated in ISSUE-31
You are really talking about a label and not a description. Descriptions are longer descriptions of the object other than a label which alt is.
for example, rather than alt use:
<img src="foo.jpg" aria-label="Lady of the Lake"/>
You could simply tell browsers to render the label when images were turned off.
You don't require a labelledby relationship either.
removing accessibility keywords, This general issue has been escalated in ISSUE-31