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

Re: Another summary of alt="" issues and why the spec says what it says

From: Leif Halvard Silli <lhs@malform.no>
Date: Mon, 21 Apr 2008 00:10:44 +0200
Message-ID: <480BBF64.6060501@malform.no>
To: Jim Jewett <jimjjewett@gmail.com>
CC: Steven Faulkner <faulkner.steve@gmail.com>, joshue.oconnor@cfit.ie, Ian Hickson <ian@hixie.ch>, david.dailey@sru.edu, John Foliot <foliot@wats.ca>, HTML4All <list@html4all.org>, Dan Connolly <connolly@w3.org>, HTML WG <public-html@w3.org>, "Michael(tm) Smith" <mike@w3.org>, wai-xtech@w3.org, Al Gilman <Alfred.S.Gilman@ieee.org>

Jim Jewett 08-04-20 22.44:     
> On 4/20/08, Leif Halvard Silli <lhs@malform.no> wrote:
>
> >  [Snipped the aria-describedby=idref programmatic association benefits.]
>
> >  The aria-describedby approach adds new, hidden, meta
> > information whic must be kept in order.
>
> True.
>
> > Instead, I'd like to propose these solution:
>
> >  1. Reserved keywords acting as CSS selectors:
> >  Elements with an ALT attribute or fallback content could have reserved
> > keywords which would point to the element containing its description: A
> > "_prev" keyword could point to previous element, a "_next" to next element,
> > a "_parent" to the parent element.
>
> Unfortunately, so does this -- and the burden is higher, and the
> burder is higher.  It would not longer be enough to to update the
> metadata when you change the element itself (or the pointed-to
> element), you would also have to worry about whether someone inserted
> a new element in between.
>   

Of course it could be done via updating the meta data.

In my post, I merely thought about the most obvious description 
selectors, and tried to show that one could come a long way only with 
them.  But if one are interested in following this path, then such 
"alt=_selectors" could be made just as advanced as CSS selectors, and 
thuse _more_ advanced than I pereive aria-describedby to be.
 
Personally, I think it is a greater risk that a <p id=photo_number_2> 
would become invalid, than there is a risk that <img alt=_next> becomes 
invalid. The author of course placed the description near the image 
because that is where it is most often logical to keep them. And when 
the author sees that something which doesn't describe the image creeped 
between the image and the description, then he is likely to want to 
correct that, rather than wanting to keep the description far away from 
the image.

> > For FIGURE, keywords are not needed and
> > should not be taken account of, as long as FIGURE only contains LEGEND plus
> > one single, embedding element.
>
> WCAG agrees that this would be sufficient if it were part of the
> definition of those elements.
>   
> I would still prefer to see it expressed in terms of aria-describedby,
> perhaps as:
>
> """
> If a figure contains exactly one multimedia element (image, video,
> audio, or object), and exactly one textual element (caption, legend,
> span, div, p), then there is a weakly implied aria-describedby
> relationship from the multimedia element to the textual element.
>
> This relationship is overridden if there is an explicit
> aria-describedby relationship.
> """
>   

I think at the *very* least, the special role of FIGURE's caption 
element - namely the legend element, must be acknowledged: If there is 
exactly one multimededia element and one legend elment, then the implied 
aria-describedby relationship is *strong*.

> and I would still like the alt (or fallback) to be mandatory unless
> there is a (possibly implied) aria-describedby attribute.
>   

I have problems with understanding why not instead let the association 
be done via identifying a class (something like aria-describedby=class) 
or selector rather by identifying a certain idref.
-- 
leif halvard silli
Received on Sunday, 20 April 2008 22:11:37 GMT

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