[html4all] Request for review of alt and alt value for authoring or publishing tools
Leif Halvard Silli
lhs at malform.no
Tue Apr 15 16:16:36 PDT 2008
Ian Hickson 08-04-15 23.14:
> On Tue, 15 Apr 2008, John Foliot wrote:
> > Ian Hickson wrote:
>
> > But in this particular case, the spec is excusing a key player (the
> > authoring tool/web-app) from it's role in ensuring that the playing
> > field remain level. You are saying "we can't come up with a solution,
> > so AT needs to do so" while at the same time giving AT *absolutely*
> > nothing to work with.
>
> The server has nothing to work wither either. None of the players here
> have anything to work with. It sucks, but that doesn't make information
> magically appear out of nowhere.
>
There ought to be several things to work with on the page you provided
below: The image caption, the name of the user, date/time, title of the
photostream.
> > > We can get better accessibility by letting user agents compete on best
> > > handling of these images than we can by letting servers, who have near
> > > zero motivation to address this issue, try to come up with some
> > > half-baked solution.
> >
> > But if the servers *must* provide part of the solution (to be
> > "conformant" servers) you have given them the motivation.
>
> Well, we can test that now, can't we? Since HTML4 require the alt=""
>
HTML 5 gives many examples. That is an improvement. It is not only
demanding that matters, but showing the way as well.
> attribute, your argument is that servers have the motivation to include
> alternative text on images for which the user has not included any
> alternative text.
>
> So let's look at a random image on Flickr:
>
> http://flickr.com/photos/18356286@N00/854359279/
>
> What's the alternative text on the critical image?:
>
> <div id="photoImgDiv854359279" style="width:502px" class="photoImgDiv">
> <img src="http://farm2.static.flickr.com/1378/854359279_73592d7334.jpg?v=0"
> alt="" width="500" height="375" onload="show_notes_initially();"
> class="reflect"></div>
>
> The empty string! That's the single _worst_ value you can give in this
> case. What we learn from this is that requiring alt="" attributes on
> images ends up motivating the servers _to lie_. They say the image isn't
> important, that it's decorative, when in fact it is the single most
> important piece of information on the page.
>
>
20 of 26 images all together have alt text and are just site stuffing.
(And 4 of the <A> elements also have alt attributes ...). The 6 other
images have emty alt. At least half of those 6 belong to the user/reader
generated content/stream.
So, there is a some kind of pattern there. If thoe images could have
meaningful text, it would matter.
> > > Reserved values are just syntactic variants on omitting the attribute.
> > > There is no practical difference. (Well, other than reserved values
> > > being significantly less usable in today's UAs, and omitting the
> > > alt="" attribute being cleaner, which is why the spec says to omit the
> > > attribute instead of inventing some new reserved value.)
> >
> > Yes and no. Reserved values can be programmatically assigned whatever
> > values/uses a user-agent needs or wants. By using a reserved value, AT,
> > all AT not just a particular flavor or brand of AT, can parse the value
> > and say "oh, one of those... I do this with those" consistently. While
> > there is a weak semantic value to a reserved value, there is *some*
> > value, whereas the vacuum of not having any alt value is just that, a
> > vacuum, and asks essentially for a guess, without providing *ANY* clues.
> > Visual users can see the photo, non-visual users are discriminated
> > against by being handed nothing.
>
> This is incorrect. There is absolutely no practical semantic difference
> from the UA's point of view between an omitted alt="" attribute when
> omitting hte attribute is defined to mean "the image is critical but has
> no content" and a special reserved value which is defined to mean "the
> image is critical but has no content". It is merely a syntactic detail.
>
I agree that there is no practical semantic difference then. And for the
sake of semanticness, it could be possible to define several equally
bad/good solutions. (Some migh prefer no alt, som an alt with a reserved
word, others would prefer enumeration.)
But there might be a practical user experience difference, depending on
what the user agent is prepared to make something out of.
--
leif halvard silli
More information about the List_HTML4all.org
mailing list