Re: Spam:******, What makes a failure? (@summary, et al)

Thank you for writing this. You have said what many people have been struggling
to find the words.

The content of this message, edited as may be required, should be included
in the WG's Design Principles.



At 11:48 AM 6/8/2009 +0200, Charles McCathieNevile wrote:
>X-SpamDetect-Info: ------------- Start ASpam results ---------------
>X-SpamDetect-Info: This message may be spam. This message BODY has been 
>altered to show you the spam information X-SpamDetect: ******: 6.344000 
>Content: cidB8(1.2) 2, SpamUrl1, To: repeats address as real name4, 
>X-Verify-SMTP present6
>X-SpamDetect-Info: ------------- End ASpam results -----------------
>
>There has been a lot of discussion about how various accessibility
>features have, for various reasons, failed on teh web.
>
>The most recent such argument I read was this morning, and stating what I
>understood it runs:
>
>- the summary attribute (in this case) more often than not contains stuff
>that isn't a valid and useful value.
>- this means that in most cases of its use, accessibility is not served.
>- this means that accessibility is harmed by the summary attribute.
>- this means it is a failure and we should use something else.
>
>It is specifically the third step (which is often the most implicit part
>of the reasoning) that I think needs to be examined more carefully.
>
> From my understanding and experience, accessibility of the web overall is
>not very good. There are lots and lots of things that cause problems.
>However, in various specific cases it has improved.
>
>For example, when working on WCAG 1 a decade ago people said it is simply
>outrageous to demand alt attributes in order to ensure accessibility -
>despite the fact that without them, it is completely obvious to everyone I
>have talked to that there will be major accessibility issues. Alt
>attributes are still used badly or not at all in many cases (and despite
>our best efforts, even here at Opera we have a few such cases pop up from
>time to time), but I believe there are far more good uses of alt text than
>there were 10 years ago.
>
>Further, I believe that this represents an improvement in accessibility.
>This is despite the common use of alt="" or some other default meaningless
>text where it is inappropriate, which actually reduces the accessibility
>of the particular page even in comparison to simply leaving off alt, by
>actively misleading the user. (Leaving off alt is still going to break
>accessibility in such cases, it is just a slightly lesser among available
>evils, in a case where it is possible to do good).
>
>In other words, my experience in accessibility leads me to believe that in
>general, the presence of lots of broken and harmful content is not
>necessarily a failure of a feature. Otherwise I would conclude that the
>effort to achieve accessibility has failed - and while I believe that
>unfortunately accessibility is still woefully inadequate (and have some
>blame to share around...) I think that there has actually been real
>improvement, measured in terms of people's increased ability to do things.
>
>A clear assumption here is that failure is a relative, rather than
>absolute term. And this invites the further reflection that using
>something which is less good may be blocking us from implementing
>something that would be used better - i.e. would lead to a higher
>incidence of people being able to do things, as a measure of accessibility.
>
>Indeed, finding a better solution is why we don't simply make something
>and then stop. Promoting a better solution over a worse one is valuable.
>But measuring better is based on guesswork. I have argued (for many years,
>in particular with my friend John Foliot) that the accesskey attribute in
>HTML has suffered from terrible advice leading to unworkable browser
>implementations (a generally recognised statement), but that this is
>actually very easy to fix, only requiring a few browsers to change their
>implementation in relatively simple ways. And I have argued that this
>would be better than implementing the new access element proposed by the
>XHTML2 WG.
>
>I cannot prove that argument, since it is based on predicting the future.
>I can point to the large amount of data that will not need to be changed,
>although in practice that argument will lose its value over time as less
>of that data remains important (or even available) and it becomes an
>increasingly small fraction of the web. I can explain that as well as the
>data, the tools and knowledge that lead to its production are going to
>hang around - and will be used to generate new content the same as old
>content for some time (looking at the state of HTML on the web, one would
>suspect that it will be a long time before poor old tools are replaced),
>which delays the previous replacement effect. Some people upgrade faster
>than others - corporate environments, university laboratories, private
>users with specific requirements, poor schools and rich start-ups are all
>different environments. And so on...
>
>It has been proposed to remove a number of accessibility features of HTML
>on the basis that they don't work well - and on the basis that this is
>therefore harmful, so just removing them is better than doing nothing. I
>argue that this is not true.
>
>There are other factors. Accessibility attributes can be used for Search
>Engine spamming, and this is obviously counter to the specific interests
>of some WG members (and not a great thing for the web as a whole). The
>failure of accessibility frustrates users, and leads to criticism of the
>technology. The fact that upgrading systems and knowledge of those systems
>is extra difficult for many people who require accessibility features,
>leading to people not adopting things that are "better" when they are
>available, can complicate the picture by misleading casual observers as to
>the relative value of various features (and by making it unclear even to
>experts). And so on...
>
>It seems to me that we should be far less hasty to remove things from HTML
>which were designed to support accessibility - and far more hasty to work
>on adding an alternative which is better, in order to actually field test
>the two side by side for long enough to understand which of our
>assumptions were brilliant insights and which were foolishness... because
>I am certain that we will all find things we backed on both sides of that
>continuum.
>
>cheers
>
>Chaals
>
>--
>Charles McCathieNevile  Opera Software, Standards Group
>     je parle français -- hablo español -- jeg lærer norsk
>http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Monday, 8 June 2009 14:42:00 UTC