Re: unifying alternate content across embedded content element types

On 7/14/07, Robert Burns <rob@robburns.com> wrote:
> I'm not asking about the history of @alt and @longdesc. There's a
> definite block to you understanding what I"m saying. I've tried
> several different ways and I have no more ideas, so I just let it go.
> If anyone else has a suggestion for the log-jam, please join inn the
> conversation.

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.

cheers
Ben

Received on Saturday, 14 July 2007 03:11:01 UTC