Re: The alt="" attribute

Hi T.V. Raman

Some further thoughts on your proposal[1].

On Aug 27, 2008, at 6:42 PM, T.V Raman wrote:
> 1.1 Executive Summary:
> 	• Make alt optional.
> 	• Define additional role values for use with graphical elements  
> including images.
> 	• Add new DOM method img.getEXIFData to pick out metadata from  
> images generated from digital cameras.


Let me first change the order of presentation:

> • Define additional role values for use with graphical elements  
> including images.


Here I completely agree. Gregory, I and others have been advocating  
for this for some time. I feel that we should: 1) provide a global  
role attribute that accepts aria and xhtml keywords, 2) require the  
role attribute on all embedded media elements (especially for non-text  
media) and require at least one of a set of specific embedded media  
keywords, 3) define a set of role keywords for embedded media that  
authors can use to convey important, often indispensable, information  
to AT users. (BTW, I've added your suggestions for keywords to the  
wiki: satelliteimage and drawing[2]).

> • Make alt optional.


Given the adoption of a required role attribute on embedded media, I  
think we can make alt optional in some cases. Though I think we can  
also make the attribute and significant text required/recommended (as  
in error/warning respective) for certain role keywords. For other role  
keywords the same semantics of HTML4 null alt is already implied  
(e.g., decorative, illustrative)[3].

My earlier response still applies[4] her as well. For authoring tools  
(such as Flickr) where the alt text has not been provided by the  
author (or even where the required role keywords are not provided and  
machine derived) , the best thing to do is leave the document in a  
machine verifiable non-conforming state. There is no option, but to  
leave the document non-conforming and adding alt or placeholder alt  
text to fool the machine is counter-productive. So we should raise the  
conformance standards for accessibility, but also raise the  
conformance standard for authoring tool so that they re even required  
to produce non-conforming HTML whenever the author provides  
insufficient information to make the document conforming.

> • Add new DOM method img.getEXIFData to pick out metadata from  
> images generated from digital cameras.

I think the importance of the media metadata is typically  
underestimated. The repeated implementation of server-side solutions  
to provide EXIF metadata demonstrates the use case demand for this  
feature. And it make a lot of sense to provide it client side since  
the image is already in the user's cache, so why require another round- 
trip just to get the metadata the user already has.

However, I think more important than EXIF metadata is other human  
authored metadata that can also be stored immanent to the media file.  
This other metadata is what the wiki currently addresses[5]. One way  
might be to extract XMP metadata, or to even develop a separate media  
file metadata specification within the W3C (though the W3C could also  
define one or two or more specific XMP properties that make use of  
XHTML within the XMP XML inside the image file format). To me the use  
case for this is even more important than the EXIF metadata both for  
accessibility and for general usability. The exposure of title,  
caption and description metadata immanent to the media file addresses  
the needs your proposal highlights.

For example your logo example:

> 	• A yelow Labrador saying "Emacspeak — the complete audio desktop!".
> 	• Raman's guide-dog, Hubbell Labrador saying "Emacspeak — The  
> Complete Audio Desktop!".
> See discussion about the role attribute later in this document for a  
> solution.

Their are two separate needs text equivalents can serve. One is as  
alternate replacement text where the text conveys the meaning of the  
media within the present context. For your logo that might be:  
"Emacspeak — the complete audio desktop". However, there's another (at  
least one) text equivalent that AT users also find useful: that is a  
text description of the media. In this case "Raman's yellow Labrador  
guide-dog, Hubbell Labrador, saying "Emacspeak — The Complete Audio  
Desktop!". Both types of text equivalents can be important to  
understanding the image and its relation to the prose and the  
subculture within which the logo has meaning. Other text equivalents  
such as titles, captions, etc. provide further information. Some of  
these text equivalents are related only to the media in is present  
document context (e.g., alt text, caption) while other text  
equivalents remain a part of the media wherever it appears (e.g.,  
description, title).

Also by using the metadata we make media more useful and searchable.  
Servers might also add access to this metadata. Imagine doing a 'head'  
request (or a newly specified request method) for http://www.example.com/images/photos/photo1.jpeg 
  and getting back the EXIF, XMP, W3C and other metadata for the file  
(without needing to burden the network by downloading the file  
itself). Similarly other authoring tools, photo manipulation tools,  
and other UAs can add similar metadata read and edit support.

Finally, by encouraging description, title, and other immanent text  
equivalents within the media file formats themselves, we promote more  
ubiquitous text equivalents (doing for image formats just as we're  
planning to do for video and audio formats). Even when an author  
neglects to add suitable alt replacement text, there may be something  
meaningful in the image's own immanent metadata. So authors end up   
authoring more accessible documents than they otherwise would and they  
don't even know it.

The promotion and use of standardized immanent metadata for audio  
formats has already yielded great user benefits, but those benefits  
have not yet been migrated to image formats.

In response to Lachy's issues, the actual structure of the DOM  
attributes and methods can be worked out. The important thing is that  
we provide some DOM access. Yes we could require UAs to provide this  
access separate from the DOM though some UI, but it would be better  
code design to place this feature in the DOM of rendering engines so  
that other UAs built on those rendering engines can present the data  
in a manner suitable to their user base.

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0829.html>
[2]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-610fd0a42b1d8af2253378db31d9d28bd22988b9 
 >
[3]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-d3e478ffe75eb909774fb779e1a90b0e22688b67 
 >
[4]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0834.html>
[5]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>

Received on Thursday, 28 August 2008 21:36:32 UTC