Re: using an attribute to categorize the @alt state

Hello all,

In the original thread where the various @alt scenarios topic was  
discussed [1], I had recommended these keywords for the @alt  
attribute itself with leading underscores. So we would adopt  
something like: '_missing', '_icon', '_decorative', '_seecontext',  
and  '_seefallback'. It was pointed out at the time that this would  
cause problems with aural UAs in that they would need to read the  
keywords until they were updated to HTML5 conforming UAs. I  
definitely think that is a serious problem, but I thought I'd just  
put this reminder here, to spark the discussion.

I think other keywords may be appropriate too. Fro example,  
_seefilemetadata might also be appropriate if the author knew an  
adequate description of the image was included in the image itself.  
This is something I think we should add to the UA conformance  
criteria: a SHOULD or MUST for UAs to extract image, video, audio,  
etc description and title metadata for non-visual users and non- 
visual UAs. Especially for the graphics that are not icons or  
decorative, more and more it very much makes sense to store suitable  
descriptions in the files metadata. Rather than requiring authors to  
extract this metadata and include it in an @alt or @longdesc document  
fragment it would be best for UAs to extract it and present it as the  
user needs it. Some of the keywords (_decorative) would help notify  
the UA that the metadata content of the file was not needed (since  
even a decorative image may have an elaborate meatdata description if  
its from a standardized library or maintained within an organizations  
media database).

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0837.html>

original message
------------------------------------------------
On Aug 16, 2007, at 3:03 AM, Robert Burns wrote:

> This is example example where  Ian hasn't even taken his own  
> advice.  He has rightly suggested that we all focus on problems  
> statements and use-cases. The changes he's made to the draft  
> certainly reflect an important problem-statement /use-case.   
> However, the solution fails to benefit from the WG process. Many of  
> the topics slowly developing on the  wiki have benefitted form many  
> back and forth threads discussing the topic. Even the issue of  
> different purposes for images has been discussed in a manner  
> similar to that shown in the changes to the draft.
>
>
> On Aug 16, 2007, at 1:35 AM, Gregory J. Rosmaita wrote:
>
>>
>> 3 questions:
>>
>> 1. why not raise the issue on public-html?
>
> Indeed, some of the discussion have already considered this topic.
>
>> 2. why not cross post your concerns/issues to the WHAT WG list
>>    and the w3c-wai-au@w3.org list, which exists precisely to
>>    address authoring tool issues;
>>
>> 3. how does leaving alt out entirely when an image is not "purely
>>    decorative" "better" serve someone merely by indicating the
>>    presence of an image?
>
> I think a better approach might be to add a new attribute to  the | 
> img| element (and maybe the other embedded content elements too).
>
> I can't think of a good name for this attribute, but consider  
> something like @embedrel (required) for now (name suggestions  
> welcome). The value of this attribute would reflect the scenarios  
> identified in the recent changes to the draft. missing, icon,  
> decorative, seecontext, seefallback. The value 'missing' would be  
> the default value, unless '@a't had a string (or perhaps some other  
> contingencies for content backwards compatibility )  so not setting  
> either @alt or @embedrel would be considered 'missing'.
>
> Considering the scenarios in the draft:
>  • A key part of the content that has no textual alternative  
> (missing; @alt could be left off)
>
> This is the default value. Editing UAs, converting UAs, and content  
> management UAs should ensure "missing" is set unless the author  
> inputs a string in length greater tha n into the value of the @alt  
> attribute.
>
> • An image in an e-mail or document  intended for a specific person  
> who is known to be able to view images (missing)
>
> I think the email delivery situation is not really different than  
> HTML delivery so perhaps the same keywords should apply.
>
>  • Icons: a short phrase or label with an alternative graphical  
> representation (icon)
>
>  • A purely decorative image that doesn't add any information but  
> is still specific to the surrounding content (decorative).  
> Typically CSS would be the preferred approach for these images.
>
> These last two (not the same order as the draft) are the trickiest  
> to capture in a keywords that authors will understand. Perhaps  
> others could come up with better keywords here. The main difference  
> here
>  • A phrase or paragraph with an alternative graphical  
> representation (seefallback; alt required)
>  • A graphical representation of some of the surrounding text  
> (seecontext; alt may be omitted)
>
> To set the keyword missing and to leave it off would basically mean  
> the same thing. However by requiring authors to at least set the  
> value of the @embedrel attribute, the conformance checking process  
> would raise awareness of the need to consider alternative text for  
> images and other media.
>
> in the future, HTML5 conforming aural browsers could easily help  
> users distinguish between these states for any particular non-text  
> embedded content. Authors could easily set "decorative" or "icon"  
> when adding large numbers of decorative and icon content. A  
> contentious  author could recognize the image fit the graphic  
> representation scenario and set the attribute value to 'seecontext'.
>
> Conformance checkers could easily tell at least whether the  
> document meets particular criteria. For example, it would be able  
> to tell when @embedrel is missing or set to an invalid value and  
> notify the author. If @embedrel is set to 'missing' or '
>
> This may be a complication, but I think the default values could be  
> handled based on the state of the @alt attribute. I most cases the  
> default would be 'missing'. However, if the element had exactly  
> alt='' the default value could be 'decorative'. The other values  
> would require explicitly setting the value. These defaults would  
> map fairly closely to the current practices (I think but others may  
> have other information).
>
> Take care,
> Rob