W3C home > Mailing lists > Public > www-archive@w3.org > September 2007

RE: [html4all] the alt attribute debate

From: John Foliot <foliot@wats.ca>
Date: Tue, 25 Sep 2007 17:22:59 -0700
To: "'Henri Sivonen'" <hsivonen@iki.fi>, "'Steven Faulkner'" <faulkner.steve@gmail.com>
Cc: "'advocate group'" <list@html4all.org>, "'Anne van Kesteren'" <annevk@opera.com>, <www-archive@w3.org>
Message-ID: <00de01c7ffd3$65d9e6b0$bc2b42ab@Piglet>

Henri Sivonen wrote:
> 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.

I believe that it has been repeatedly pointed out that Adaptive Technology
is not an User Agent (browser).  It is a tool that interacts with
user-agents; it is an interpreter that leverages content fed to the real
user-agent - the web browser.  

As we look to write a spec, we should be focused on this - accessibility and
adaptive technology must work hand in hand, but they should not always be
linked when developing a spec or benchmark.  AT needs a stable and robust
spec, to be sure, and it might even lend some hints, but just as the spec is
not being written for a particular user-agent (browser), so too it must not
be written for a particular AT tool (or even class of AT tool - there is
more than just screen readers out there).  This is HTML 101 - user agent

> 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.

It is not defeatist, it is realistic.  These small companies are either Open
source/non-profit, or have very small development teams that must address a
multitude of issues.  For example, every time that Microsoft releases a new
version of Office, the AT vendor must ensure that their tools will work with
the new release.  Sometimes there are no issues, other times there are huge
issues... It all depends - when Microsoft unleashed IE7, it caused all sorts
of problems for JAWS users, to the point where blind/low vision advocacy
groups all over were posting instructions on how *not* to accept the
Microsoft auto-update for IE7.  

So while we might look exclusively at "the web", these businesses must look
beyond just web and web browsers - tools like JAWS must interact with all of
the applications on the end users machine, not just the web browser.  When
it comes to prioritizing issues, which do you think comes first - ensuring
operability with Vista, or coming up with a new system of dealing with
images that have no alternative text?  

Besides, before browser developers start throwing rocks at the AT R&D, it
would be nice if content developers could get away without having to write
multiple style sheets for Firefox, Opera, Safari and Internet Explorer...
(as John struggles with just that scenario this week...)

> 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.

Again this supposes that this is a high priority for the AT vendors.  With
the current suppression of "noise" via alt="", the issue has been, by and
large, addressed as a usability problem - for now.  With the new draft
proposal however, allowing images to exist without alt text re-opens a
"closed" issue for screen reading AT, but as has been pointed out, with
little guidance on how exactly the AT systems should process the data string
that is an image call in HTML.  You keep talking about heuristic analysis,
but this is not science yet, it's alchemy, and expecting AT vendors to lead
the charge and come up with the magic is unrealistic, and unfair.  Perhaps
the deep pockets of Apple, Google, the Mozilla Foundation and Opera could
jump in and provide the resources needed to make this realistic?  

> 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.

How reliable is a void?

> 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.

Exactly, yet this is currently being classified as "bogus".  Providing
absolutely nothing is not reliable, it isn't even reliable enough.  Is it
really an image that should have alt text (but none was supplied) or is it
an image that should have alt="" (as it is non-essential [somewhat
oxymoronic, but whatever])?  Allowing the void to exist in the spec
perpetuates the ambiguity, with the added downside of signaling to the world
that alt text is really not critical, and in some instances can be avoided.
This is a bad social engineering perspective which should (nay, must) be

>>  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.

I would suggest that most of the accessibility community are pretty much in
unison with Steven's assertion, it is you that have not yet agreed to what
it is we are saying: something - anything - is better than nothing.

> 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.

...and how are you going to do this when all that is supplied is <alt src=""
/>?  You've just confirmed what we've been saying all along - there needs to
be some sort of mechanism that signals something about the image.  Without a
specific "hook", the best you can achieve is a coin toss - a 50% chance of
guessing right (it should have alt text, it shouldn't have alt text).  The
hook is, and should remain, the alt attribute.  

>> 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.

With the flag, the chance of "reliability" increases multi-fold - at least
we know "something", even if ultimately it is of little usable value to the
end user: we know that it is an image that *should* have alternative text,
but doesn't. 

Suggestion:  If alt="" is reserved for images without the need for a value,
then perhaps there should be another reserved value that signals that an
image *should* have alternative text, but doesn't.  That certainly would be
more reliable than a 50/50 guess, no?  

Perhaps we need to also reserve alt="_none": automated systems (the Flickr's
of the world) could default to that, WYSIWYG editors could provide that as
an option, and user-agents of all stripes could be programmed to deal with
that instance in a specific way that may or may not be the same process that
is applied to alt="" (for example, screen readers could suppress voicing
both values, or not, as a user-choice setting).  It has been pointed out
that this has already been suggested on the public-html list - I guess it
was during my banishment.

> 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.)

Because given the current state-of-the-art, it is the closest they can
achieve of "reliable enough" - it's something unique about the image file,
even if it is functionally less than great.

>> 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.

Nah, that's a cop out.  Users means just that - users: all of them.  You
know, maybe some of them might not have the technical chops to implement an
idea, but could none-the-less come up with something that is not obvious to
the masses of us who actually "see", and are not dependent on the AT we
struggle to understand.  Henri, on this one, just say "Oops, yes that's

Received on Wednesday, 26 September 2007 00:23:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:14 UTC