- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 25 Jun 2009 14:34:03 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: "public-html@w3.org" <public-html@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>
On Jun 25, 2009, at 2:31 AM, Charles McCathieNevile wrote: > > There is a concern among many people who work in accessibility that > "access for all" is sometimes used to justify not providing > "Accommodation" - solutions which do not affect everyone but are > necessary in order to ensure that specific groups have the same > quality of access as "the rest of us/them". > > The example above, of having a visual structure which accommodates > the vast majority, and headers which accommodate a group who cannot > benefit from the visual representation of the structure, is > something I think is an example of how things should work. In an > ideal world, a hidden attribute (in contravention of the visible > metadata principle) wouldn't be there - but we live in the real > world, and without it, we will be limiting people's ability to > understand complex structures. I think the very example of headers="" being in the spec, and also alt="", means that this is generally understood and accepted. In my recollection, here are some of the accessibility-specific disputes that we have had, and some of the issues that arose: - should alt="" be mandatory in all cases, or ommittable sometimes? -- main issues: if there are use cases where it is not possible to be truly accessible, should there be direct affordance for such cases at all, and if so what form should it take? - should headers="" be allowed? -- main issues: should we have features that encourage complex table structures? are there tables where headers="" is truly beneficial compared to a good header association heuristic - should <canvas> be removed, or should some more extensive affordances for <canvas> accessibility be provided, or is it basically ok as is? -- main issues: should features be allowed where the developer work to make them accessible is complex? what kind of accessibility affordances work well for very low-level drawing APIs? - should longdesc="" be allowed? -- main issues: is it useful to allow an attribute that is almost never used, and when it is, almost always contains garbage data? does longdesc provide significant value over alt="" and ARIA mechanism? - should <table summary=""> be allowed in conforming content? main issue: is it useful to allow an attribute that very often contains garbage data? if an attribute is designed for presentation to a subset of users, but often contains information that would be of interest to all users, then how can we encourage authors to do the right thing? I think only in the last of these was there a serious concern about hiding information from non-disabled users, or users with a different disability than the intended target audience. I think that was a valid concern, and is reasonable to consider as one of several factors. > I suspect most people working in accessibilty would expect a high > degree of misuse of almost any such feature - unfortunately, just > specifying how things *should* be doesn't mean that people will make > sure things *are* so. But the value that is available in the cases > where this is done right means that it seems worthwhile to continue > with it, and to continue teaching people to get it right. Sometimes there's no practical way to make it easy to do the right thing. But when there is, we should strive to push the design in that direction, instead of pushing harder on designs that aren't getting developer traction. I don't think that is directly related to the Accessibility principle however - it's a difference in design philosophy that comes up in other situations as well. In conclusion, I think you have raised some good concerns, but I don't think they justify the proposed edit to the Design Principles. Regards, Maciej
Received on Thursday, 25 June 2009 21:34:44 UTC