Re: handling fallback content for still images

Authors have struggled very hard to have richer fallback. A good place
to look for these struggles is the various "image replacement"
techniques that are around. They don't generate the buzz today that
they did a few years back. Here is a place to start:
http://www.stopdesign.com/articles/replace_text/

The concept of "image replacement" is to have (potentially rich) HTML
(fallback), and use CSS to replace this with image.

A typical case is pretty headings. One could (and perhaps should)
argue that such cases point to limitations with fonts/typography
online, rather than a particular issue with image fallbacks. They can
also be handled with existing HTML: <h1><img src="welcome.png"
alt="Welcome"></h1> This is not a strong use case for richer image
fallbacks (imo), but the techniques can be applied to richer HTML than
"<h1>". Mostly I want to highlight the difficulties that authors went
through trying to implement "image replacement", which was a kind of
inverted "html fallback for images" using CSS (because HTML could not
solve the problem).


I still see a much broader issue (beyond images): associating
information with embedded content. There are a few scenarios.
"Fallback" is one, and is served by @alt, @longdesc, and the
object/video/audio/... models. "Rich fallback" is a particular case of
fallback, cannot be served by @alt but can be by @longdesc,
object/video/audio/...

There is confusion about "fallback". Scenarios (in my mind are):
1. fallback for UAs that don't understand HTML 5
2. fallback for UAs that don't support a particular plugin/media type
used within a document
3. fallback for accessibility (a need to access alternatives instead
of the embedded content)
please note this last option is completely different to making
embedded content accessible.

I assume all can be served by the same fallback mechanism(s) and this
may be incorrect?

Another case is not a fallback, but dealing with related content in
the page (and a way to express the semantics of that relationship
through markup), figure/legend is an example of this, and @longdesc
can also support this. There is no markup for other situations, and in
those situations, if this relationship were clear, it could also serve
as the fallback content, which would boost accessibility (or is
accessibility just fine without it? I do not have the answer).

It is at the author's discretion which method is best, for example,
whether I should use alt="Portrait of George Washington" or alt=""
because there is a heading/caption (i.e. context) that already
clarifies this. Far more eloquent explanation available in four
examples (in the section "Context is Everything") from WebAIM's
article on appropriate use of alt text. These make excellent use
cases. Please read: http://www.webaim.org/techniques/alttext/#context

They do describe techniques that are effective today (HTML 4). It
would be nice have better semantics in HTML 5 to capture these
relationships. figure/legend is a good addition to HTML. I think
working through the webaim examples using HTML 5 markup might be
productive, to see how far we get and tease out where the (perceived)
gaps truly are.


I also think this same issue — "associating information with embedded
content" — applies to table@summary (except tables aren't "embedded
content"). Sometimes an author wishes to "summarise" a table
explicitly in the document, outside the <table>. This practice is
endorsed by WCAG Samurai: http://wcagsamurai.org/errata/intro.html,
where they state:
"You have more than one way to explain the purpose of data tables
(including the use of plain-text explanations), so there is no reason
to require the use of the summary attribute, which, by specification,
is hidden from anyone who can see, including persons with
disabilities."

This same issue can be oberved on <abbr>. Use case: Three letter
abbreviation (TLA)
Here it is used badly (redundant): Three letter abbreviation (<abbr
title="Three letter abbreviation">TLA</abbr>)
Here's a thought for making the association: <dfn id="dfn-tla">Three
letter abbreviation (<abbr longdesc="#dfn-tla">TLA</abbr>)</dfn>

Personally I'm pretty comfortable with "Three letter abbreviation
(TLA)" and no <abbr> tags anywhere. Just as I am happy using
punctuation characters rather than <q>. Is that a bad thing?

Maybe we don't need markup to capture these associations.
Maybe we do.
Maybe we need to provide authors with a language that supports
implementation of informed choices.

That last statement is *the* killer argument for image with fallback,
imo. And it is because of the design principle: 3.2. Priority of
Constituencies
http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#priority-of-constituencies


Some authors can and will make use of this, if it's able to further
improve accessibility. It will require support from UA and AT vendors,
and the accessibility field (WAI, webaim etc.) Now read the webaim
article about context again :)
http://www.webaim.org/techniques/alttext/#context


I apologise for the lengthy post.

ps: fight the melancholy Philip!



On 7/5/07, Philip Taylor (Webmaster) <P.Taylor@rhul.ac.uk> wrote:
>
>
>
> Henri Sivonen wrote:
>
> [all snipped, too depressing]
>
> wall.against.beat (head)
>
>
>
>

Received on Thursday, 5 July 2007 14:58:15 UTC