Originally Posted by
Hixie
I don't think it would be wise for me to name names.
Incidentally, another point I should make, which applies equally to users with disabilities as it does to everyone else, is that users in general are woefully unable to report their own needs. Usability studies are a classic example of this — if you ever get the opportunity to watch a software usability study, you will see that it is very common for users to claim a particular need, despite acting in a manner that shows that they are completely mistaken about that need.
An example from the accessibility sphere is the "longdesc" attribute. If you ask users what they want in terms of images, they will frequently claim that what would be most useful for them is a way of getting longer descriptions of what images are. However, if you actually look at how AT users interact with the Web, it becomes abundantly clear that this isn't true: by and large they never actually seek out longer descriptions of images; indeed, they generally don't find any need to even know that there _are_ images.
We found similar things when we did the usability studies for the microdata feature (yes, we actually did usability studies for parts of HTML!). For example, people would claim to understand certain aspects of the feature, but would be unable to actually use them. It was only when we simplified the model beyond the point where authors claimed understanding that we ended up with a model that authors actually, in practice, understood.
The net result of all this is that when a user or author reports a bug, one has to be very careful to actually examine whether their request is actually sensible or not. The true experts are the ones who can tell the difference.
Another common mistake is to view the Web as primarily a visual medium, which must then be adjusted to work for AT users. This is the kind of approach that leads to "bolt-on" accessibility and poorly-devised features like longdesc="", summary="", or the aforementioned posteralt="". I feel this kind of approach basically is treating disabled users like second-class citizens.
The right way to design a device-neutral, medium-independent, universally accessibly markup language is instead to start from the standpoint of each kind of user — partially blind, hearing-impaired, having reduced motor control, speaking only English, etc — and to ensure that each feature makes sense in that context.
So for instance with video, if you think of it from the point of view of a completely blind user, you quickly realise that the visual part of the video is pointless. Instead what you need is to convey the action aurally — instead of making a video, you actually want to make an audio programme. In practice, this ends up meaning textual descriptions synchronised with the main audio track, since typically making two different programmes is too much effort and the visually-able part of the audience does want video.
Similarly, when you think of how to activate the playback of a media resource for a blind user, you would never consider having the video element be represented by an image, since the user can't see images. You would want instead to just expose playback controls and information about the nature of the video (typically it's title or other advisory information). This information would either be something inline in the page (e.g. in a paragraph adjacent to the video) or in the title="" attribute.
If you instead apply "cargo-cult" thinking, treating users of ATs as second-class citizens, you might come to a different conclusion: you would look at the _visual_ page, think "Well there's an image there, and all images need alternative text", and you would ask for a posteralt="" attribute. But if you think of the AT users as first-class citizens, you would never even notice the poster frame.
Another example of how AT users are often viewed as second-class citizens is the summary="" attribute. If you think of AT users first, you would say "well any complex information structure must be explained to the reader" and you would put explanatory information about the table in the prose around the table (or in the caption, maybe). If you then think of visually-able users and look at the page, with its table description and its table, there would be nothing to change: there's nothing wrong with providing visually-able users lots of information about the table. It's only if you go the other way around that summary="" makes sense: if you start with the visually able, you might not think to include a description; if you then think of the AT users and decide they need a description, you might be tempted to say that the information shouldn't be shown to the visually able since you hadn't thought of it when you were considering them and therefore it should be hidden in an attribute.
I hope that better explains many of the decisions in the contemporary HTML specification. The tl;dr message is just "think of all your users, don't think of disabled users second".
