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

Hi charles,
> - this means that accessibility is harmed by the summary attribute.

As I have pointed out previously on this point, many of the bogus
examples of summary attribute use are never announced by screen
readers (that support @summary) as they are found on tables used for
layout, which the screen readers ignore via the use of heuristics to
filter out inapropriate table use.

regards
stevef

2009/6/8 Charles McCathieNevile <chaals@opera.com>:
> 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
>
>



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

Received on Monday, 8 June 2009 10:10:36 UTC