- 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>
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 agnostic. > > 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 avoided. >> 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 true". JF
Received on Wednesday, 26 September 2007 00:23:44 UTC