- From: Robert J Burns <rob@robburns.com>
- Date: Tue, 13 May 2008 13:52:51 +0000
- To: Andrew Sidwell <w3c@andrewsidwell.co.uk>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, "public-html@w3.org" <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, wai-liaison@w3.org
Hi Andrew, On May 13, 2008, at 12:53 PM, Andrew Sidwell wrote: > > I have reservations about adding to this thread, but so it goes... > (I fear I'm making the same point Dave Singer rather excellently > made.) > > Steven Faulkner wrote: >> dear maciej, >>> It is not a matter of opinion. Making a use-case non-conforming is >>> by >> definition not handling it for purposes of document conformance. It >> may be a >conscious choice to reject a use case, but it is not >> support. >> you assume without justification, that it is desirable or right to >> accommodate use cases that result in important data and/or data >> relationships not being provided. i don't subscribe to this. > > I would be happy if someone (or several someones) in favour of > making alt mandatory in all cases would answer very simply: How does > a blind photographer mark up a photo, which is known to be critical > content, but which she herself cannot describe? According to the new draft section, the alt attribute is not to be used for description of photographs that are critical content. You're thinking of the current editor's draft that attempt to expand the alt attribute to cover many more accessibility functions. However, according to best practice recommendations descriptions — including descriptions of photographs — should be handled through other means. For a blind author they would likely not even think in terms of using an image of rich text or an iconic image or a chart to convey their meaning. Rather they would work in the opposite direction which many here could benefit from doing. In this case, they would start from the issue of conveying meaning with text. A graphic designer might then take that recurring text and apply an icon or rich text to it. A blind graphic designer might draw from a library of existing icons (previously described and stored in the files metadata). Likewise a blind graphic designer might make the text into rich text beyond the capabilities of present-day (or legacy) CSS. However, the necessary alt text is already available to the blind author and the blind graphic designer author because the meaning is conveyed in the the of the document: it merely needs to be moved to the alt value of an img element that embeds the rich text or icon. On the other hand, the description of the image is not a requirement nor a proposed requirement here. The description falls in the SHOULD or MAY language (perhaps "authors SHOULD provide a descriptive title and MAY provide further subject and visual descriptions of images referenced by the longdesc attribute). So to summarize critical content text alternative is not a description of an image. It's the necessarily brief text that would be required for a user to comprehend the document in the absence of the image. > Is it: > <img src="photo"> > <img src="photo" alt="Photo"> > <img src="photo" alt="Exposure 2s, f/12"> > or something else? Something else (a photo will rarely require anything but null alt): <img src='photo1' alt='' longdesc='descriptions#photo1' > or something else (for an icon that draws the visual user's eye): <img src='important-item-icon' alt='important item' > or something else (for rich text such as text written on a path or text painted with a color gradient or text with an affine transformation): <img src='InvitationSalutation' alt='You are cordially invited' > or something else (a chart intended to visually convey the breakdown of electricity production among various methods): <figure> <legend>The breakdown of electricity production in Illinois</legend> <img src='InvitationSalutation' alt='Nuclear 50%, Coal 30%, Natural Gas 15%, Other 5% ' > </figure> In all of these cases the blind author has all of the information necessary to construct conforming alt text (according to the newly drafted section). The rest of your questions I'll leave for you to answer. As you can probably see now, they were based on a fundamental misunderstanding of the alt attribute. Take care, Rob > Furthermore, should a blind photographer who cannot provide alt text > be able to author conforming HTML5? (I ask this without prejudice; > maybe the answer should be no.) > > This is essentially what "handling the use case" would consist of. > Guidance needs to be given in cases like these-- "cases that result > in important data and/or data relationships not being provided", > whether you want to accommodate them within the spec or not. > > Why? Because there *is* content with no textual alternative and > there will be whether you say there should be or not. The > interesting question is not "should alt be mandatory?" but "how do > you mark up critical content with no known alt text?". Saying "but > alt text should be available" does not change the fact that > sometimes, it is not. With me? Just because you set up your > goalposts such that the interesting question is outside them does > not remove the question. > > As a photographer, I do not have the time or the money to pay > someone else to have the time to provide anything resembling > alternate text for 99% of my photos. I am quite willing to produce > non-conforming HTML5 if alt was to became mandatory in all cases, > but the question remains-- how should I mark up the photos I don't > have the resources to provide alt text for whilst still saying that > they are critical content? > > (Call me someone with disregard for disabilities if you like, but I > see putting photos online for those who can view them analogously to > showing my friends prints of photos in real life. IRL I don't write > alternate text for every print I make in case someone who can't > adequately view the photo wants to know what it's about, and so I > don't expect to do the same online. I would be happy to describe a > photo in such an instance, but it's something I would do on-the-fly, > and not at upload-time/print-time.) > > > Andrew Sidwell > >
Received on Tuesday, 13 May 2008 13:53:47 UTC