- From: James Graham <jg307@cam.ac.uk>
- Date: Sat, 16 Aug 2008 15:33:59 +0100
- To: Steven Faulkner <faulkner.steve@gmail.com>
- CC: Ian Hickson <ian@hixie.ch>, W3C WAI-XTECH <wai-xtech@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
Steven Faulkner wrote: > The Current HTM5 spec introduces changes to the criteria for > conforming to HTML5 in cases where no 'real alternative text' is > available. > > It would be useful to have some real world use cases clarified in > respect to the changes: > > 1. When a user uploads an image in flickr (http://www.flickr.com) they > are given the opportunity to provide a 'description', if they choose > to provide a description it is placed into the alt attribute of the > image (plus ' by xxxx'). > In the interests of accuracy, I should point out that flickr asks for both a "title" and a "description" of the image. The /title/ is used inline in the page and in both the alt attribute and the title attribute; the description is just used inline in the page. Arguably one could say that a title is not a text equivalent but users would be best served if UAs use @title in a manner similar to @alt if no alt text is available (with freedom to do something like say "image entitled foo" rather than just "foo"). The argument against that is that the title is already available inline so requiring the UA to present it twice wouldn't help anyone. > Is this conforming in HTML5? if not what would be an appropriate alt > attribute content if no 'real alternative text' is available? > I believe the spec currently requires that flickr set @alt={photo} or similar. If you look at how the title and description fields are actually used on flickr it's not clear to me what you would gain by setting the alt to the value of either of these fields; it is unusual for either to provide an actual description of the photo and both are available inline anyway. If flickr were to use the HTML 5 <figure> element, there would even be an explicit link between the figure and its description, without needing it to be repeated.
Received on Saturday, 16 August 2008 14:34:39 UTC