Re: using an attribute to categorize the @alt state

On Thu, Aug 16, 2007 at 05:24:02AM -0500, Robert Burns wrote:
>
> 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.

You could define a PURPOSE attribute to hold this information, or use @role if
it or an equivalent mechanism is provided.

This would complicate the conformance requirements a little, since either @alt
or @role (taking the second alternative as an example) would need to be
supplied, but in principle it is a worthwhile, constructive proposal.
>
> 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).

I agree, and this proposal is worth serious consideration. The only problem
arises if the UA can't process the file format of the image, whereas on the
author's side, this capability is sure to exist.

As a practical example, my braille translation software (which would have
conformance requirements similar to printing software were it to support this
spec) can't parse image file formats now, and there seems little reason why it
should be required or expected to do so in the future, whereas the authoring
application already has this capability.

Received on Thursday, 16 August 2007 10:39:51 UTC