Sometimes the best thing to do when presented with an unsatisfactory solution, is to walk away from the problem for a while. The continuing arguments in the HTML@W3C arena of accessibility proved an example. After reading through many of the arguments, I was left distinctly unsatisfied with the solutions offered. I had questions and arguments, but nothing better to offer.
The core problem is that I (and the vast bulk of web authors and developers) will never spend very much time writing for accessibility. As a consequence I (and the larger “we”) will always be unskilled in this domain. We need help. What we need is some means that makes writing for accessibility … accessible. Arguing over individual attributes is a waste of time. What we need to understand is the impact of the page as a whole.
Someone (months back) suggested I download one of the specialized browsers, and play with it for a while. Not a bad idea, but not a very good one either … to be honest … the larger “we” will never spend enough time to really make good use of this approach. Someone who has used such browsers for years will have a skills and most likely a different approach that I cannot acquire in a few hours poking around.
We need a bit more leverage. We need to be enlightened.
- The first missing bit is a “best practices” document - something that captures the expertise of skilled disabled-human readers, and captures the most effective implementations of specialized browser software.
- The second missing bit is a visually-oriented test browser that offers a clear presentation of the structure of a page, as seen by a “best practices” browser. Such a test browser would strip out any visual elements, recognize any added bits added for accessibility, and visually highlight the organization and navigation associations - perhaps green background for the main (hinted?) path, and red background for islands of unlinked or ungrouped text - so that the visual aspects of a page are discarded, and the non-visual structure of a page becomes visual. The test browser might well just be an add-in for an existing mainstream browser.
- The third missing bit - only possible after we have the first two - is a clear definition of how to apply minimal additional hints (via styles, attributes, or whatever is needed) so as to make a web page and web application more accessible.
Arguing over attributes - an aspect of the third part - is backwards, and a waste of time without clear understanding and realization of the first two parts.
Creating the first part could be a problem as the software vendors in that domain are likely small, and treat their algorithms as proprietary. Also as the market size is small, the products offered may not be very good, and thus not a good source of enlightenment. The size of the “practices” document should be small. If you present the larger “we” with a 100-page document then approximately no one will ever read the document. Guidelines must be clearly and concisely expressed in a single page of text (with larger explanatory material available to read as needed), if the guidelines are ever to be read by a significant percentage of authors. This is a pretty good test. Writing short, concise, and clear is only possible when you have a good comprehension of the subject. Writing large, fuzzy texts is easier, but less useful. If the field in question is filled with large/fuzzy ideas, you end up with large/fuzzy texts.
The fact that the second part - the visually oriented “test” browser - does not exist is a pretty good litmus test. That lack is a strong hint that this aspect of design is not yet well and properly understood. (Of course that existence of the “test” browser is a threat to small proprietary software vendors, as a subset of the “test” browser could serve as a generic browser for the disabled.)
There is in fact a future mainstream application for this area of study. As use of the internet becomes pervasive, rather than something done always done as a sole activity, then non-visual usage becomes more important. Imagine you are driving a car, riding a bike, or walking down the street. You will want to make queries without staring at a screen. (Running into a tree or a car is at least embarrassing.) This growing/future need could prove a boon to accessibility, if authors and designers are offered a clear and efficient path.
The argument over whether accessibility-oriented attributes should be required for HTML5 conformance is a waste of time. Testing for accessibility is semantically remote and distinct from the concerns of a well-structured HTML page. Better to channel that time and energy into defining and building better tests and development aids.
[Yes, I read some of the ARIA documents. Unless I really do not understand, this is not going to happen … as described above.]