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

Jim Jewett 21-04-08 01:57:   ­  
> [Individual Cc removed; not sure which lists to trim]
>
> On 4/20/08, Leif Halvard Silli <lhs@malform.no> wrote:
> > 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.]
>
> > > >  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.
>
> ...
>
> >  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.
>
> Ahh.  That is interesting, particularly since most user agents needs
> to implement CSS selectors anyhow.
>
> >  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 risk isn't that alt=_next will become a dangling pointer; the risk
> is that it will start pointing to a different (and wrong) element.
> Since it still points to something, automatic tools won't show the
> problem.  Since it only applies to alt (which isn't typically
> visible), most designers won't notice on their own.
>   

By 'automatic toools won't show the problem', do you mean that you can't 
use a validator or something to check whether there is a match?

At any rate, relying on predefined selectors for the ALT attribute would 
make it quite simple for web designers to perform their own tests via 
CSS. For instance, if I want to see if my choice of using alt=_next was 
correct for all the images I have applied it to, then I could use this 
CSS style:

    img[alt="_next"]+*{border:red dashed thick}

or if I used the _prev keyword:

    *+img[alt="_prev"]{border:red dashed thick}

And such a thing would also be simple to use in Henri's validator, I 
suppose.

With aria-describedby=, however, since it contains a idrefs, and since 
idrefs can look any way you want, it becomes more cumbersome to check, 
via CSS.

And also, just getting a match  is only a ID match. The content of that 
element might still not match.

> >  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.
>
> Would you want 10 elements to all act collectively as the description?
>   

Would it be useful, anyhow, to link 10 paragraph to the same image?

I guess my thought involved that the author could apply a class to a 
description container, and that one would specify that the first (or all 
?) elments with this class, before the next embedded object appeared, 
would describe the image.

However, there is then not very much difference between this thought, 
and what I said about an "alt _selector". Even an alt _selector could 
look for a class, if we defined the syntaxt for it.

> Maybe, but I'm not sure how easy that would be for a UA to handle.
>
> I also suspect we would get quite a few pages like
>
>   <img src=1 alt=_class_photocap>
>   <div class=_class_photocap> ... </div>
>   <img src=2 alt=_class_photocap>
>   <div class=_class_photocap> ... </div>
>   <img src=3 alt=_class_photocap>
>
> So which description goes with which photo?
>   

To make it more CSS selector like, I would perhaps proposed something 
like this:

    <img src=1 alt="_next div.photocap">

And if so, then it should be obvious that the last IMG above did not 
have any description. While if I meant ths:

    <img src=1 alt="_prev div.photocap">

Then only the first IMG would be without a description.

Finally, som questions and claims about aria-describedby:

Steve explained aria-describedby= by comparing it to how for=/id= work 
for the LABEL element. And it is a matter of fact that several LABEL 
elements can point to the same ID. (I now also see that aria-describedby 
can even point to *several* IDREFS, which makes it more similar headers= 
than to the for= attribute.)

Thus, I assume that aria-describedby= could also point to the same 
description.  And thus I foresee that a very simple solution for some, 
could be, if they have 1000 photos, to let all of them point to the same 
description. Voila, case closed. A test would render it valid.

But, it is then I starts to wonder about the programmatic link between 
image and description that Steve talked about.

If the same ID can actually be pointed to from several images, then we 
should also, as well, be able to say that the LEGEND of FIGURE should 
create a programmatic, allthough identical, label for all the embedded 
elements inside the FIGURE element.
-- 
leif halvard silli

Received on Monday, 21 April 2008 02:05:20 UTC