- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 07 Sep 2001 18:35:43 -0400
- To: w3c-wai-gl@w3.org
As I re-visited Bill's visual summary of the WCAG at <http://rdf.pair.com/xguide.htm>http://rdf.pair.com/xguide.htm I began to get an idea. The idea started as "you can't separate the treatment of media diversity and expository mode diversity under major sections for presentation and comprehension, because the remedies are the same." The content provider isn't supposed to provide equivalent alternatives addressing sensory barriers, and then different equivalent alternatives addressing cognitive barriers. You want to leap as many of the phase boundaries in "what mode works" as you can with the minimum redundancy in terms of parallel data. _Any text_ synchronized with video supports search and recovery. It doesn't matter if it is caption or transcript. _Any non-text_ aids the reading impaired, whether it is graphics, reading the text, styling motifs or sonicons (mouse-over leitMotifs, for example). The bottom line image is that our product is techniques. It is a response to 'how.' What we offer is how to cover the diversity of disability needs with the minimum of wasted effort and the maximum gain (in usability by all) for your pains. It's _Web_ content accessibility knowledge, a domain that is scoped or bound in the technology dimension. It is the marriage of user needs and technological capabilities. We can generalize and raise the level of abstraction with regard to these techniques. But the techniques are the product. Until we make the connection with the technology, all we have provided is motivation, is heuristics. Our first job is to be informative as to what techniques work. We can worry at our leisure how and who shold make what normative thereafter, if we are doing Our Job which is that. One of the top level strategies is this business of hitting two birds with one stone. Let one split into redundant expositions of an idea serve more than one access failure repair. This is a message that can't be left to a subsequent commentary. That is major business between us and our customers. Sorting what we have to say by function that gets impaired and then repaired is one axis of the plot. But the technological resources to synthesize the web content are another equally important dimension of the plot. We are helping people build bridges between these two edges of the chasm. Redundancy is a major strategy. There is a user-derived requirement that the redundancy span the critical divides, the "phase boundaries" of content usability. Although some of the failures arise in sensory functions in the user, and others arise in failures deeper in the processing, the response is clear. Reiterate in different ways. Show and tell. Text and image. The details of what gotchas to avoid in user disability and the details of how to indicate this in SVG vs. VoiceXML are equally subordinate details. Not the major categories we are talking about. On the technology side, there is the requirement that the linkages between equivalents or feasible alternatives be machine comprehensible, so that user agents can implement systematic and easy to use methods of content control that get the actual usage in the configured delivery context to be something that the user can and wants to use. The diversity requirement on the content is a both and of crossing the phase boundaries in Person With a Disability usability, and the formal semantics requirement of User Agent machine recognizability and operability (in content control, see UAAG 2.3). Kelly's remark helped to pull this into focus, too. Our number one enemy on the Web today is not missing ALT text but inscrutable form controls. This fits into our mandate as follows: General HCI principle: - Classic version: The system response to user input should be predictable. - QuickTips version: Let the user know what they can do. That's above the level of the WAI problem but we need to point out the traceability to that general principle. Our contribution is how to satisfy this guideline in the presence of disabilities. Web major subcategories of the above: + Form controls + Hyperlink navigation + Navigation within the page Web techniques for these: + text labels + intrapage structure and containers + link text front-loaded, diversified in initial letter (see list of links view) + icons + mode switches + alternate sites + content negotiation + Mention non-Web options for equivalent service (800 numbers, email, etc.) + etc. So we set the context in terms of a major HCI principle and major Web functions. Then we get down to surveying the failure modes, the technology resources, and the known good techniques. Job done. In other words, the outline should follow a general outline for web content design, without regard to disability, and the disability particulars should enter as an inner, not an outer, loop variable. That would be something interesting to try. We can talk about this more in the discussion of who does what about what parts of the answer concerning the XMLGL. We realized too late in the development of the current draft to make a change that many of us wanted, to take this sort of approach to the organization of that volume. This is beginning to take the shape of answers to some of our long-running problems. Yes, the charter that says our product is guidelines is broken. Deferring techniques to an afterthought document is not our strongest play. Our market opportunity is for techniques. We can't steer the work toward guidelines and then do an about face and say "W3C just does technology, not policy." We need to pitch our work so that even dummies can see we are not trying to tell them what to do. What we have to offer is how to do something that they can decide to do or not to do. We offer them what we know about who they leave out if they don't do it, and how these techniques are beneficial across the board. But the mood of the utterance is 'here's how." Second, the relationship between accessibility and usability. The answer is that we use accessibility to detect problems, and we use usability to optimize solutions. The techniques that we offer are honed for broad-spectrum effectiveness, not for mere problem avoidance. The optimization techniques are as important to our customers as are the failure avoidance techniques. So let's give them equal time in our work. This is what we need to carry to the Device Independence community. Maximizing the flexibility of the morphs you archive and serve minimizes the count of the morphs you have to archive and serve. Use diversity and flexibility together, it works better that way. Al
Received on Friday, 7 September 2001 18:12:52 UTC