W3C home > Mailing lists > Public > public-html@w3.org > May 2008

RE: alt use cases

From: Justin James <j_james@mindspring.com>
Date: Tue, 6 May 2008 12:11:29 -0400
To: "'Karl Dubost'" <karl@w3.org>
Cc: <public-html@w3.org>
Message-ID: <0bb701c8af93$d7d0ae50$87720af0$@com>

Karl -

This ARIA stuff is pretty good. I question the rationale behind making it an
optional "bolt on" to HTML, rather than a direct set of items within HTML. I
know this brings us back to "the other giant argument" from a few months ago
about other namespaces being imported into HTML. But at this stage, the
issues around @alt and the issues around the name spaces are directly
linked. If the ARIA stuff can be mandated by HTML, then what it means is
that the usage of @alt can become dependent upon the ARIA metadata. For
example, an <img> with an ARIA role of "button" would require an @alt, and
that @alt would be recommended to be a description of what happens when the
image is clicked.

Ah, right there, I've found another point of consideration here.

Some elements (included <img>) have multiple event handlers attached to
them, particularly in these AJAX-y applications. For example, an image could
represent a "slider" control, where a drag has one effect, but a click has a
different effect. How do we convey to the user the different descriptions of
this? One giant @alt, like "click to 'set' the volume in place, drag to
adjust the volume"? Or something like, <img alt_click="Set the volume"
alt_drag="Adjust the volume" ... /> ?

J.Ja

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
Behalf Of Karl Dubost
Sent: Monday, May 05, 2008 9:56 PM
To: Justin James
Cc: public-html@w3.org
Subject: Re: alt use cases



Le 5 mai 2008 à 23:09, Justin James a écrit :
> * Considering how much in-accessible functionality is already in  
> HTML 5
> (particularly with regards to support for AJAX-type work), it is  
> clear that
> this is *not* a goal. From the way the spec supports AJAX and  
> multimedia, it
> is clear the accessibility is a "nice idea" but certainly secondary to
> functionality.


   Accessible Rich Internet Applications (WAI-ARIA) Version 1.0
   http://www.w3.org/TR/wai-aria/
   implemented in IE8 beta, in Firefox, in Opera, and being  
implemented in Webkit
   (aria-* syntax)


> * If we are going to mandate al text due to CASE #4, we should make  
> the
> <audio> and <video> tags (and anything that does the same in  
> <object>) have
> a mandatory @transcript system.

   I wonder if there are plug-ins supporting the built-in captioning  
systems.
   SMIL has a feature for this btw.
   http://www.ischool.utexas.edu/~smil/captioning.html



"alt" has known limitations too in terms of internationalization and  
markup. I would be interesting in a system, where it is required to  
give a text alternative somewhere in the page.

Usually a longdesc attribute is used for giving a long description of  
the image. The attribute value must be a URI.

	<img src="beach.jpg" longdesc="http://example.org/foo.xhtml"/>


Let's imagine a page foo.xhtml containing this markup

==============
<p><img src="beach.jpg" longdesc="#foo"/></p>
<p>… blah blah…</p>
<p>… blah blah…</p>
<p><img src="mike-portrait.jpg" longdesc="#author"/></p>
<p>… blah blah…</p>
<p id="foo">A beach is a geological landform along the shoreline of a  
body of water. It usually consists of loose particles which are often  
composed of rock, such as sand, gravel, shingle, pebbles, or cobble.</p>
<p>This text was provided by <a href="mailto:mike.myers@example.org"  
id="author">Mike Myers</a>.</p>
==============

Longdesc could contain URI-reference not only URI. The accessible text  
equivalent could be part of the page and easier to edit and be the  
same than for people with visual abilities.
Things which are only decorative can be ignored.

-- 
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool
Received on Tuesday, 6 May 2008 16:12:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:17 GMT