Re: Improving alt (was handling fallback content for still images)

Here's an idea for alternative/related content (perhaps an alternative
to @longdesc).

There is already advice, for authoring with HTML4, that additional
information should be drawn from the surrounding HTML (context). I've
mentioned in previous posts it's one suggested as an alternative to
img@alt and table@summary, primarily where using those elements would
be redundant.

What if we looked at formalising this practice a bit? It could be
rules that set the options authors use and possibly the priority that
they are given?

Maybe ... for alternative content (and/or expanded context) UAs can refer to:
- the alt attribute (for a short, text alternative)
- content referenced by the longdesc attribute (for a
document/fragment alternative)
- the legend from a parent figure element that has a legend child
- surrounding content, constrained by:
-- the figure element (if we allowed more than <legend> in there)
-- the containing section (section, article, aside, header/footer/nav, etc.)
-- a containing div with a class matching those tag names, e.g. <div
class="section">


Hope this is making sense. Here's a little example. I'm building this
example from webaim's example of alt text here:
http://www.webaim.org/techniques/alttext/#example1

<figure>
<video src="media/gw.ogg">
  <img src="media/gw.jpg" alt="">
</video>
<legend>George Washington</legend>
<p>Because of his role as  the Commander in Chief of American forces
in the  Revolutionary War, and, later, the first President of the
United States,  George Washington is often called the &quot;Father of
his Country&quot;.</p>
</figure>

This is not currently conforming. I suggest it could be interpreted as follows:
- it's a figure
- "George Washington" is the caption
- show the video if possible
- show the (fallback) image if video can't be handled
- do nothing if video and images can't be handled (no alt needed as
context is already clear)
(that much *is* conforming, this next bit is my suggestion)
- use the rest of the content in the <figure> (the paragraph) as more
contextual information... this is in place of @longdesc (in this
instance) and also supports the <video>.

Could we allow extra content in the figure like this? It would always
be rendered (by default, CSS could be used to alter presentation). If
not with <figure>, then with "section" elements perhaps?


On 7/7/07, Sander Tekelenburg <st@isoc.nl> wrote:
>
> At 15:53 -0500 UTC, on 2007-07-05, Robert Burns wrote:
>
> > <x-flowed>
> >
> > On Jul 5, 2007, at 1:11 PM, Sander Tekelenburg wrote:
> >
> >> I think whether all UAs support alt is debatable. Test case:
> >> <http://santek.no-ip.org/~st/tests/altlength/>.
>
> [...]
>
> > I like this proposal.
>
> Thanks. I added it to the wiki:
> <http://esw.w3.org/topic/HTML/LongdescRetention#line-40> and
> <http://esw.w3.org/topic/HTML/LongdescRetention#head-ef01c5377a967ead313aeecea431de086517670a>
>
> > We definitely need to provide clearer
> > prescribed behavior for UAs: especially visual UAs. I wonder if this
> > should be extended to provide a mechanism for full fallback content
> > as well.
>
> Well, I mentioned longdesc in purpose in this proposal. Basically just
> emphasizing what HTML 4.01 already says: alt is for short textual
> alternatives, longdesc for long ones.
>
> [...]
>
> > I present this example because I'm wondering whether we need @alt in
> > addition to @title?
>
> We do (as long as we're stuck with img). @alt and @title have very different
> semantics.
>
> Don't let yourself be fooled by the unfortunate current situation that most
> popular UAs present both through the exact same mechanism. That's just an
> implementation mistake. Even amongst the specialists in this WG it causes a
> lot of confusion, so it's obvious that this needs to be fixed -- that the
> spec will have to require that UAs present @alt different from @title.
>
> > Does it provide something necessary that longdesc
> > does not.
>
> Yes. Both @alt and @longdesc are about *alternatives*  to the image. @title
> is for a certain type of *additional* information.
>
>
> --
> Sander Tekelenburg
> The Web Repair Initiative: <http://webrepair.org/>
>
>

Received on Saturday, 7 July 2007 08:35:13 UTC