Re: Accessibility, disability, all and some Re: Request to Strengthen the HTML5 Accessibility Design Principle

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