Re: [html4all] the alt attribute debate

Yo henri,

>Mainly because you have documented the usability bug in connection to
>JAWS specifically.

I also specifically stated in the article that window eyes exhibited similar
behaviour.

>At least with alt text, unlike with spam, most uncooperative data
>sources aren't wanting to hurt you. They just aren't going to help
>you. It doesn't make sense to ask those who won't help you to hurt
>you if you have the option of asking them to neither help nor hurt.

from my perspective you are beginning to babble here, i am unsure of your
point.

>No, I don't think we have yet come to the conclusion that the absence
>of data will continue to be worse than bogus data. This should be
>trivially true: If a consumer prefer bogus data over absent data,
>bogus data can (by definition) be generated out of thin air. OTOH, if
>a consumer prefers absent data over bogus data, telling bogus and non-
>bogus data apart is harder.

lost me here too I am afraid.

>AT UAs need to deal with those cases, too, though. The question is,
>really, whether explicit flagging as "critical" has enough value
>compared to falling in the same bucket with lack of alt for unknown
>reason.

It is the spec that is making this distinction of certain images without alt
attributes being "critical content" it makes the assumption that these can
somehow be differentiated from all other altless images, this distinction is
reliant upon authors following the other recommendations in the spec about
how to mark up images, without them doing this (which as we know is the
likely case), then these magical critical content images will become just
more meaningless noise for the AT UA to filter out as they curently do (most
of the time).

Your arguments also appears to rest on the assumption that automated
software that outputs images to html is providing the alt text because the
current spec says so, i find this rather hard to believe as they don't
appear to be bothered about many other aspects of the spec.

>Of course. But saying "users" is generally understood as short-hand
>for end users--not developers who dogfood their products

What I was trying to say is that it is easy to find reasons to cut users out
of the equation as they may actually disagree with your agument for what is
best for them (or mine for that matter).

See Ya!

On 25/09/2007, Henri Sivonen <hsivonen@iki.fi> wrote:
>
> On Sep 25, 2007, at 14:35, Steven Faulkner wrote:
>
> > >Yes, I have noticed that.
> >
> > so why have you continued to only talk about this point solely in
> > reference to JAWS?
>
> Mainly because you have documented the usability bug in connection to
> JAWS specifically.
>
> > >The point is that no one has so far explained why that behavior
> > >(which is awful in some situations as you have demonstrated) would be
> > >the permanent end state of development for AT and not just a
> > >transient usability bug that is fixable in a handful of
> > >implementations. For example, VoiceOver plus Safari on Mac OS X 10.4
> > >do not share this usability bug, which trivially demonstrates that it
> > >is possible to construct AT that doesn't have the usability bug.
> >
> > nobody has said that it is the permanent end state, of course it
> > would be easy to modify what is announced in response to a an image
> > without an alt in a particluar context.
>
> Yet, I often get a feeling that arguments based on the current state
> of AT (JAWS in particular, sometimes WindowsEyes--everyone expects
> VoiceOver to be a moving target) have an implied premise that AT is
> what it is and as good as it gets. Sometimes it seems like the state
> of AT is taken as the most rigid piece in the overall Web ecosystem
> to the point of suggesting that browsers, authoring tools and
> countless authors change instead.
>
> It has been explained to me why the AT upgrade cycle is slow. But it
> doesn't explain the general defeatist attitude towards AT R&D that I
> often sense in discussions.
>
> There may be forces holding back Web client software changes, for
> example, existing content relying on a bug, major discontinuities in
> getting from here to there or the proposed change requiring the
> participation of competitors in lockstep. However, improving AT
> behavior with missing alt suffers from none of the usual constraints:
> an AT vendor could unilaterally improve it in its own product.
>
> > The issue is not to do so much with what the AT UA can do with an
> > image without the alt attribute, it is about what the UA cannot do.
> > It cannot reliably differentiate between an important image without
> > an alt attribute and an unimportant image. Therefore they generally
> > treat images without alt attributes the same way that they treat
> > images with alt="", that is they ignore them.
> >
> > The argument used to undermine this issue is that the UA can
> > perform heuristics to classify (critical content, spacer,
> > decorative, functional, representation of text etc) the images
> > without alt attributes and then decide what to announce based on
> > their classification. problem being I suggest is that there is no
> > reliable way to provide this classification.
>
> The word "reliable" is the problem.
>
> All too often in these accessibility debates it is taken as a given
> than someone else has to provide something reliable (or "unambiguous"
> or something like that). You don't get "reliable" from an
> uncooperative data source, which the Web is from the point of view of
> an AT UA.
>
> With an uncooperative data source, the overall result is likely to be
> better if you shoot for "reliable enough" instead of refusing doing
> things that aren't totally reliable. With spam, for example,
> expecting the data source to become cooperative would be futile.
> Hence, people rely on measures that are reliable enough.
>
> At least with alt text, unlike with spam, most uncooperative data
> sources aren't wanting to hurt you. They just aren't going to help
> you. It doesn't make sense to ask those who won't help you to hurt
> you if you have the option of asking them to neither help nor hurt.
>
> >  So we come back to the point that not specifying anything for an
> > image is a worst case and will continue to be.
>
> No, I don't think we have yet come to the conclusion that the absence
> of data will continue to be worse than bogus data. This should be
> trivially true: If a consumer prefer bogus data over absent data,
> bogus data can (by definition) be generated out of thin air. OTOH, if
> a consumer prefers absent data over bogus data, telling bogus and non-
> bogus data apart is harder.
>
> > The only way I can see to identify images that are "critical
> > content" but the author cannot or will not specify an alt text for
> > them, is to provide a flag for this in the code,
> [...]
> > in this way it can be differentiated from the millions of images
> > out there of all different sorts that the authors simply did not
> > care to provide alts for.
>
> AT UAs need to deal with those cases, too, though. The question is,
> really, whether explicit flagging as "critical" has enough value
> compared to falling in the same bucket with lack of alt for unknown
> reason.
>
> > >(We shouldn't take stuff under /TR/ as holy writ set in stone when
> > >following it clearly leads to worse usability than doing something
> > >smarter.)
> >
> > who does?
>
> Pointing to the /TR/ space looked more like a justification than a
> mere explanation. (And even as an explanation, it doesn't explain why
> the vendors have settled on something as bad.)
>
> > >That's a good idea. However, I get a feeling that users may not have
> > >a good grasp of what kind of ideas would be implementable and,
> > >therefore, eligible to be suggested.
> >
> > what you are forgetting is that there are AT users who are also
> > programmers and designers and spec writers etc. who may be able to
> > grasp the complex possibilities that reside in a head such as your
> > own.
>
> Of course. But saying "users" is generally understood as short-hand
> for end users--not developers who dogfood their products.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html