Re: unifying alternate content across embedded content element types

On Jul 13, 2007, at 10:10 PM, Ben Boyle wrote:

> I'll try ... note this thread is about unifying alternate content
> across embedded media. This is clearly not a shared opinion as we have
> had many posts from people who think images should be managed
> differently from video/audio and again from object/embed. So that's
> what we're discussing... should the alternate content mechanisms be
> unified (a principle?) and if so, how (implementation details - what
> goes in the spec). I would really prefer WAI representatives gave
> advice on the former and we concentrate on the implementation.
>
>
> The alternate content for images model:
> 1. media (img@src) itself, which may contain it's own accessibility
> support (e.g. captions embedded in the image file)
> 2. short text alternative (img@alt)
> 3. rich HTML alternative (img@longdesc)
> 4. all the content around the <img> (context) within the HTML  
> document.
>
> Combined this gives authors, user agents, assistive technology and
> users themselves many ways to tailor their experience.
>
> Note that HTML 5 (draft) compared with HTML 4 differs in:
> - img@longdesc is absent so there is no rich HTML alternative for img
> - context can be enhanced through figure, section, article, aside,
> etc. and (more explicitly) figure/legend associates a caption with the
> img.
>
> Arguably, some of the above could take the place of @longdesc, though
> they do not functio exactly the same way. It depends on how you define
> the original problem, particularly whether you consider "alternatives"
> to be required (a) "instead of" or (b) "associated with" the embedded
> content in question.
>
> I really think accessibility folks should be guiding us here on what
> HTML needs in order to give authors, UAs, assistive technology and
> users alike a chance at delivering on a rich, inclusive experience.
>
> Representing myself as an author, here's what I want in HTML 5:
>
> 1. a unified approach that can be consistently applied, that simplies
> authoring HTML including doing it myself, training others, and
> implementing systems that produce HTML.
>
> 2. improved accessibility support in HTML 5. I think there is quite a
> bit already that looks very promising, but does lack the "unified"
> angle at this point.
>
> 2. continued support for all legacy accessibility features, no matter
> how "poorly" they may be perceived. They are the standard NOW and I
> would not consider deprecating any until it was well proven (by time
> in the marketplace) that alternative features were suitably supported
> to make them redundant. I want this continued support in both UAs
> (where I know it will be for backwards compatibility) and documented
> in the spec as conforming HTML (because until I have confidence in
> alternative means, I will need to use these aspects of HTML.
> Conceivably I could author confirming HTML 4 documents as an
> alternative, but that will restrict use of new features (such as
> <video) and isn't desirable.
>
> That's what this discussion means to me. My post doesn't follow any of
> the recommendations for supporting evidence, use cases, etc. because
> this isn't a specific narrow problem, it's about the strategies for
> improving accessibility support in HTML.
>
> But I still think WAI should be leading it (the fact that they're not
> communicating to me they are satisfied that the HTML 5 draft is what
> it needs to be) so I'll not say anything further on the topic.
>

Ben's message helped me think of another approach that might convey  
my meaning better. Since, <img> has two separate mechanisms for  
alternate/equivalent content and those mechanisms have become  
differentiated by their length, might it be useful to extend those  
differences to the other embedded content elements?

(I have know idea whether this table will work on the list or the  
list archives or the wiki, but I'll give this a shot. If HTML's not  
supported at the W3C, where will it be supported :-) ) .

The available equivalent (alternate/fallback) content mechanisms on  
each of the embedded content elements.
element
short
equivalent
long
equivalent
note
img
alt
longdesc

object

contents
*
picture

contents
*
video

contents
*
audio

contents
*
canvas

contents
*
embed


*
notes

an asterisk (*) indicates that the title attribute may be used to  
provide additional content that may provide some (alternate)  
information when the embedded content is unavailable or unusable for  
any reason.

As you can see from the table, this short and brief content that can  
be used by screen readers or text- only browsers (in addition to  
visual browsers too), is unavailable for the other embedded content  
elements. Perhaps its unnecessary on those other elements. I'm just  
posing this for others to consider. To me, it strikes me that, if its  
useful to add a short alternate to an <img> element that perhaps  
already has a lengthy and semantically rich description as the target  
of a @longdesc attribute. then maybe it would be useful to do the  
same for other embedded content elements.

The suggestion is not to replace the semantically rich fallback  
inside those other elements, but rather to server this as the same  
brief alternate as a complement to the rich equivalent, just as with  
the <img> element.

If the inclusion of a long equivalent/alternate mechanism and a short  
equivalent/alternate mechanism is not useful for the other embedded  
content elements then why is it useful for <img>?

Does that help explain what I'm posing for discussion?

Take care,
Rob

PS, this table also helps illustrate a use-case I've been trying to  
describe for the @summary attribute. That is the visual depiction of  
a lot of empty grey cells is not easily discernible for those  
listening to the table's contents. A description of that striking  
visual device is not useful to those viewing the table. However,  
providing the summary of that fact to those listening to the table is  
an important use for the summary attribute (or element).