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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
