- From: Charles F. Munat <chas@munat.com>
- Date: Sat, 25 Aug 2001 13:28:12 -0700
- To: "WAI Guidelines WG" <w3c-wai-gl@w3.org>
I have been thinking about this for a while and I think this is a good time to bring it up. My natural tendency in thinking about accessibility WRT web sites is to think in the following terms: 1. Get the information to the user 2. Organize the information so that the user can find what he or she wants 3. Make the information comprehensible once the user has it I explained this as access -> navigate -> comprehend and even suggested a split in the guidelines along these lines. But I have also been thinking that this is a user-centric view. First the user accesses the site, then the user navigates the site to get the info, and finally he or she processes the data (read, etc.). We, however, are writing our guidelines for *authors* not *users*. So isn't our sequence backwards? As a site developer, don't I usually develop content first, then mark it up, then add presentation? So shouldn't our guidelines look like this: 1. Make it comprehensible 2. Make it navigable 3. Make it accessible (device-independent) After all, how can you create equivalents to text (or vice versa) if you haven't got the content yet? With this in mind, and keeping our current sections, shouldn't we swap Guidelines 1 and 3? Then we would have this: Guideline 1: Comprehension. Make your content easy to understand. Guideline 2: Interaction. Make your content interactive so that it allows organization according to the user's needs and preferences. Guideline 3: Presentation. Format your content so that it allows presentation according to the user's needs and preferences. Guideline 4: Technology considerations. Design for compatibility and interoperability. Or, using my categories: 1. Comprehension: Make content comprehensible. 2. Navigation: Make content navigable. 3. Access: Make content independent of device and representation. What do others think? In addition to making this more author-centric, it has the benefit of putting the checkpoints addressing non-visual needs up front. This may help to address the concerns about bias in the checkpoints without having to do some sort of checkpoint-balancing just for appearances. Chas. Munat
Received on Saturday, 25 August 2001 16:25:50 UTC