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

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 don't have any  
> special
> 'accessibility' software available. If those who do provide me with  
> test
> results, I'll add them.)
>
> Most UAs treat alt quite differently, and most impementations don't  
> appear to
> be exactly useful. No doubt this in part stems from the spec being  
> too vague
> about allt text having to be "short". I would imagine that defining  
> a hard
> limit would be helpful. Both for UA implementors to know how to  
> comply with
> having to make alt available, and for web publishers to know how  
> to  provide
> useful alt text.
>
> So I propose to add the following to
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
> section-embedded.html#alt>
>
> - UAs must make the entire contents of the alt attribute easily  
> discoverable
> and available to users when the image is, for whatever reason, not  
> presented.
> (For example, UAs may present the alt text in place of the image;  
> or through
> a tooltip or in a status bar on hovering the indicator of the  
> missing image;
> etc.)
> - The maximum length of the alt attribute is n characters. UAs must  
> ignore
> the part of alt's conent that exceeds this limit. For longer  
> alternatives
> authors must use longdesc.

I like this proposal. 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. After all, if authors take the time to provide this  
information (even if its fallback) it would be best to provide users  
with the option of exploring this content. Even users of visual UAs  
may face one or another accessibility issue and may benefit from  
having access to fallback content (as well as for author's checking  
documents with visual UAs).

> Obviously n needs to be defined. For backwards compatibility we  
> need to take
> into account that tooltips disappear after n seconds (at least in  
> Mac OS X
> and Windows). For that reason alone the alt text must be kept  
> short. I'd
> think 100 characters, or even less. (Would that number, or that  
> unit, be a
> problem with non-latin scripts?)

I especially like the idea of including a specific number for the  
limit of @alt. To the extent that I'm familiar with Unicode scripts,  
I would say that other scripts would tend to require fewer characters  
than Latin: I'm thinking in particular of the ideographic scripts.  
This might be a good place to use the term grapheme too to help clear  
up (hopefully) issues of composite characters (and other compound  
characters).  Alternatively, for internationalization sake, we could  
make it a word limit and refer to Unicode specifications for word  
boundaries. To my mind, words, as abstractly defined by Unicode might  
more closely match what we're trying to limit here.

Other Fallback Content Ttoo?
For other fallback (whether the contents of an element <object>-like  
or the document fragment referenced by longdesc) I think a more full- 
featured toggling mechanism might be appropriate for UAs, where a  
user toggles through or selects (perhaps from a contextual menu),  
alternate content. This doesn't need to be boldly displayed in the  
users face. A contextual menu submenu would be sufficient.

Apologies for piggy-backing on your proposal, but I've been thinking  
about proposing criteria for handling alternate content  for a while.

Collapsing @alt and @title?
Let me just add one other issue related to @alt that I think we  
should discuss and address in the draft. That is the issue of @alt  
and its relation to @title.

Example: Here are to alternative methods for marking up the same  
content. Both are a paragraph within an inline bar graph. The first  
uses an <object> element. The second uses an <img> element with  
fallback provided by a separate longdesc span. Display is handled by  
a separate stylesheet and maybe some javascript adds some fallback  
presentation support (since UAs aren't where we want them).

<p>Here's an inline graph depicting... <object data='myimage'  
title='a bar graph showing quarterly sales over the last 4 quarters  
trending upwards''><table>... data for the graph as someone else  
suggested … </table></object>... </p>

<p>Here's an inline graph depicting... <img longdesc='#bargraphtable'  
src='myimage' alt='a bar graph showing quarterly sales over the last  
4 quarters trending upwards'' /><span id='bargraphtable'  
class='longdesc' ><table>... data for the graph as someone else  
suggested … </table></span>... </p>

I present this example because I'm wondering whether we need @alt in  
addition to @title? Does it provide something necessary that longdesc  
does not. Its easier to use. Its supposed to be shorter than  
potentially more fully descriptive fallback content may be. However,  
its not available on <object>. There an author would have no @alt  
attribute for the short version of the fallback content. In my  
example, I use @title instead. So do we need @alt at all? Or do we  
need it on any embedded content element? Could @title suffice for  
this information on <img>. Obviously for backwards compatibility we  
would want UAs to continue supporting @alt in the same way they  
already do (or even enhanced for a short-term bridge).

I think making all of the embedded content work as closely in  
parallel will make authoring easier. Authors seeking to meet  
accessibility needs will have a clearer understanding how to do that.  
Right now its quite overwhelming. We have:

1) the surrounding prose
2) the rich fallback (sometimes through @longdesc)
3) the <legend>
4) @alt (on <img> anyway)
5) @title (on everything embedded)
6) media-file-specific fallback content / accessibility hooks /  
textual metadata

I look at this list and it all seems like it has its place. Except  
when I look at @altt and @title. Its difficult for me to think of use- 
cases where I need to say something in both the @alt and the @title  
of the same element. Its hard for me to imagine how I would write the  
spec to explain to authors when to use @alt and when to use @title.  
Or to put it another way, to explain what information belongs in  
img@alt and what information belongs in img@title.

Should we deprecate (omit/drop/leave-out) @alt in favor of @title?  
Should we extend it to all of the other embedded content elements?  
(To me @alt and @longdesc certainly need to be added to the UA  
conformance criteria for <embed> as a bridge measure even if we  
deprecate <embed>). However, should we go ahead and deprecate @alt in  
favor of @title just to make <img> consistent with the other embedded  
content elements and to remove an attribute that has very close  
overlap with @title?

Any thoughts?

Take care,
Rob

Received on Thursday, 5 July 2007 20:53:32 UTC