- From: Al Gilman <asgilman@iamdigex.net>
- Date: Mon, 20 Aug 2001 15:11:24 -0400
- To: "WAI Guidelines WG" <w3c-wai-gl@w3.org>
At 07:45 AM 2001-08-20 , Anne Pemberton wrote: >Chas, > > As it is, we have four guidelines 1) accessibility, 2) >navigability, 3)comprehensibility, and 4) technology > > You suggest moving the technology checkpoints under which? > > Why not simplify further ---- two guidelines: 1) insure that all >content is accessible and comprehensible >and 2) insure that users can navigate the page/site. AG:: Disclaimer: How not to make these remarks sound conclusive? I wish to share some bias and some background without presuming what I say is the right answer for the group. For the moment, I would tilt toward separating cognitive barriers from sensory and actuation barriers as major forks in the development of our message. The objective to maximize what the user can get out of the Web, and I mean the whole Web, is shared, but the gotchas that break the achievement of this goal involving sensory-motor and cognitive issues are sufficiently separately to be treated separately in detail with supporting connecting threads. I don't believe that we can remove cross-linking between any two of Chas's proposed three foci, but this doesn't mean that it doesn't make sense to give the developments in each area a measure of autonomy. Part of our problem is that we are still trapped in legacy-think concerning what is _a document_ and what is _normative_. There has to be a bit of promotion in every engineering specification; mostly by linking but partly inline. That is just because you can't entirely trust readers to read the glossary or to follow hyperlinks, etc. Our expository style has to have a measured dose of both-and; both indication and evocation, both words and pictures, both extract the essence and illustrate the application. In an ideal world already adapted to the Web we would not be talking about one document vs. three. We would know that our product is a web of Web content, and we would be working on site organization, in which these four areas are our working definition of centers of accumulation that have a measure of autonomy, or principal-parts standing relative to the whole. And that the whole WCAG only has that limited degree of autonomy from the whole web of wisdom that the WAI publishes, and the WAI only a limited degree of autonomy from what the W3C technology community and the HCI community and so forth publish. The point is that each of Chas's proposed triple is a major, semi-separable subtopic dealing with HCI -- making it work for people. The fourth area, technology, is making what works for people automatable by machines. It's almost like 'comprehension' and 'navigation' are the two functional outcomes that we support and 'sensation and actuation' and 'automation' are the two instrumentalities that we have to work through to accomplish these. In regards to comprehension, I don't think that we will ever get past the fact that "Your Mileage May Vary." There is a diversity of cognitive constraints and preferences, and you cannot reach all of the people all of the time. In the particular case of people with disabilities which mean that alphabetically encoded words just don't work, I believe the highest and best answer we can come up with is to enable these users to navigate and actuate, and that "comprehending all the information" is beyond what we can come up with in terms of readily achievable techniques. But retail merchandising on the Web can probably be made to work with just the pictures and the controls, so long as the navigation mechanisms to get to the pictures of the individual products offered for sale is recognizable without the words. And that is probably achievable. At times we used to say "text is king" and I think we have [as a consensus] recognized the problems with that summary. But there is still a sense in which "navigation is the queen" of web actions. The great thing about the Web is how it _gives people alternatives_ by the common mode of access to myriad resources on the Internet. The trick is to make browsing and user-driven selection of what one choses to work on comprehending really slick, really facile. Because comprehension is such a hit-or-miss thing, browsing is a key component of our strategy to improve performance against cognitive obstacles. Skimming and drilling down. Those are the coordinates of browsing. This makes our achievements relative to 'cognitive' objectives heavily dependent on the 'ensure navigation works, well' nap of our solution strategy. Oh, I said 'nap' there. This raises an image that I think we can perhaps express by a 3D visualization of the soap-bubble structures that we in physical chemistry call phase diagrams. In the review of a draft for the ISO/IEC Handbook 71, Gregg pointed out that they had butchered the gross shape of the problem/solution connection by lumping all visual disabilities together. The key here is that the phase boundary of tipping point in what kinds of strategies work comes not between normal vision and impaired vision but between some vision and no usable vision. Working with a screen magnifier it is clear that incremental changes in the visual presentation are essential. Working with a screen reader, they are immaterial. The deeper access to the textual code for text-to-speech or text-to-touch transformation is what is key at this point. So there is a both-and in our message: both make each thing you do to communicate as robust and flexible as you can, and also incorporate redundancy that crosses the major mode boundaries. What we haven't convinced ourselves we know, is what all the major modes are. The failure we face is if the alternatives provided, taken together with the flexibility embodied in each alternative major mode, don't reach all the corners of our demographic space of human and device abilities. In the cognitive arena, taking reading-affecting disabilities as an example, I believe the 'operating point' we can reach is where a) incremental techniques are used to level and minimize the linguistic challenges of the verbal content, b) alternatives in non-visual media and non-verbal modes of expression are also used to convey the same message or content and c) metadata and other navigation facilitators are used to aid in finding an expression that works around a particular sensory, motor, language or background-driven obstacle. How much of each is 'enough' may be unanswerable, other than some diversity or distribution of approaches is required and the methods to apply in each approach are laid out. In the User Agent guidelines we rely on the argument that "in the end, only the user knows for sure" what works for them and what doesn't to argue for algoritms of content control which give the user the last word. In the content guidelines, for cognitive effectiveness, we face the same fact. Only the user knows for sure what is working for them and what is not [educational testing aside]. Here the result is a both-and distribution requirement. Both make your message as multimode as you reasonably can, and cooperate in web-wide strategies to facilitate the user's search and browse process to find equivalents and or adjuncts that work for them or make your bit of Web work for them, drawing not only on what you have provided but on what others have provided. My own 'modest proposal' on document scopes has been that the next round of documents should unify work across the areas that we divided out as document topics in the previous round. Rather than dividing by author tool, content model and encoding, and user tool divisions, we should attack specific functional areas where we feel the technology and our advice as to how to use it is under-performing, and address them on an end-to-end basis giving coordinated suggestions in all of the above areas as a bundle. Particularly, in the UAAG we felt that the current format definitions give inadequate support for cues as to what constitutes the principal parts of a web page, suitable for automatic extraction of a Table of Navigation such as used in the digital talking book specifications. In the XMLGL we are exploring the hope that with the new language-building technologies particularly schema-based syntaxes, that we can do better on this score. But it won't work without suitable authoring-time interactive methods being applied, IMHO. So navigation remains a central area where we could do well to take an integrated look at what the notation, the author tool, the author, the baseline browser and assistive add-ons to the browser should all do to make this work better under more circumstances of "delivery context" as the Device Independence working group would say. Coping with the increasingly dynamic and interactive nature of web content is yet another area where our grip is weak. This deserves focused attention, and cross-old-document-boundaries integrated work. There are incremental techniques that can be applied in the domain of writing in HTML+ECMASCRIPT and there are more radical approaches extending the outcome-schema strategy exemplified by X-Forms. It is impractical to think that we can just pick one of these strategies to pursue; advances in either direction will make a contribution, no matter how well we do on the other. As Chas and Anne are agreed, dealing with cognitive challenges is another under-performing area. Perhaps we can agree to disagree, or defer decision, on the ultimate algebra of document scopes, while we agree we agree that this is an area where we have miles to go yet, and it deserves focused attention in a semi-detached or encapsulated work item. At the moment, we have a 'WCAG' scoped group which has position and momentum to take this on, so we don't have to wait for a more radical reorganization of the groupings to get going on this. Al >...There will be too >many cross links between accessible and comprehensible, and they both have >a common goals -- for the user to be able to use the content. > > Anne > >At 04:30 AM 8/20/01 -0700, Charles F. Munat wrote: >> From a previous post: >> >>"If it were up to me, I would break out [navigability] and >>[comprehensibility] and make three guidelines: WCAG, WCNG, WCCG, for >>Accessibility, Navigability, and Comprehensibility respectively. If we did >>this, I expect that WCAG would be slightly smaller, WCNG would be of >>moderate size, and WCCG would be as large or larger than the current >>guidelines." >> >>I continue: >> >>I don't expect to convince many, but I'm going to state this for the record. >>The best we're going to do on the WCAG if we try to include navigability and >>comprehension in with accessibility (strict sense meaning ability to "get >>to" the data) is half-assed. More likely quarter-assed. It's just too much >>for one document. >> >>IF (big IF) we split the documents: >> >>1. We could have the WCAG 2.0 ready to go in a week (and with almost NO >>quarrelling over the details -- this stuff is mostly old hat). >> >>2. The Web Content Navigability Guidelines could be done fairly quickly, I'd >>imagine. A few months? >> >>3. The Web Content Comprehensibility Guidelines would take a while. At least >>a year, I'd think. BUT (big BUT): We could issue a temporary set containing >>the comprehensibility checkpoints currently in WCAG 2.0 (including the >>dreaded 3.3 and 3.4). They would be without official status (whatever that's >>worth) but would be enough to get people thinking about it. We could also >>promote them and try to get people thinking more about comprehensibility. >> >>THINK OF THE BENEFITS: >> >>1. We get access out of the way. This would refocus our goal. No longer >>would there be the tug of war between access advocates and comprehensibility >>advocates. >> >>2. A new, small, fast-working group could be formed to handle the >>navigability guidelines. Without the burden of having to figure out >>comprehensibility (a much more difficult proposition) or simple access, >>these guidelines could be produced quickly. >> >>3. COMPREHENSIBILITY IS NO LONGER ACCESSIBILITY'S UGLY HALF-SISTER, VYING >>FOR ATTENTION. This group could morph into the Comprehensibility WG, minus >>those people who are more interested in access or navigation. The group >>would be focused on ONE goal. Better still, we could PROMOTE this idea more >>effectively because comprehensibility is more *comprehensible* when were not >>trying to call it accessibility. Finally, we could go out and actively seek >>experts on comprehension (and cognitive disabilities) to join the experts >>already in this group, bringing in fresh blood and new ideas and >>rejuvenating the group. Who knows, maybe without the drag of constant access >>vs. comprehensibility wars, the WCCG could be completed in record time. >> >>The only detriments I see are these: >> >>1. It takes longer to get the comprehensibility guidelines out. As I see it, >>this delay would be more than compensated for by the MUCH clearer nature of >>the WCCG guidelines. And, when users looked to the WCCG, there would be no >>doubt about what they were trying to accomplish (e.g., a person who just >>wants to ensure access to users with visual disabilities will not look >>there). Another mitigating factor would be the temporary stop-gap measure of >>an "unofficial" release of "methods to aid comprehensibility while waiting >>for the release of the WCCG 2.0." >> >>2. Without the "accessibility" angle, comprehensibility might lose some >>leverage. Solution: Define accessibility twice (as we already have, I >>think). GENERAL accessibility includes SPECIFIC accessibility, navigability, >>and comprehensibility. PUT THIS IN THE INTRODUCTION TO ALL THREE SETS OF >>GUIDELINES, thus: >> >>"There are three parts to ensuring an accessible Web site. First, users must >>be able to access the site. Second, they must be able to navigate the site, >>to find the data they're looking for. Finally, they must be able to >>comprehend -- to understand -- the data once they've found it. The W3C >>provides three sets of guidelines related to Web site accessibility: the Web >>Content Accessibility Guidelines (WCAG), the Web Content Navigability >>Guidelines (WCNG), and the Web Content Comprehensibility Guidelines (WCCG). >>All three sets of guidelines are necessary to ensure accessibility on the >>Web." >> >>This gets us out of the "usability" trap. It clarifies (and actually >>simplifies) the guidelines. It refocuses the guidelines by allowing each set >>to concentrate on one area. >> >>There could be overlap. A checkpoint that affected access and navigability, >>for example, could appear in both. The non-normative data could explain how >>it affected access in the WCAG version and how it affected navigability in >>the WCNG version. >> >>Another option is to reorganize the current guidelines into access, >>navigability, and comprehensibility sections, but this is much less >>desirable. I envision a significant expansion of the comprehensibility (and, >>to a lesser extent, the navigability) portion. This is going to take some >>time. If we keep them in one document, we will delay the access portion by >>quite some time. Why? Let's get it out of the way. Then let's create a set >>of comprehensibility guidelines that will blow the lid off this subject and >>will focus everyone's attention on the need to make sites comprehensible to >>everyone. (Note to Anne: this puts the needs of people with cognitive >>disabilities front and center.) >> >>I ask everyone in this group to think seriously about this idea. WE CAN DO >>THIS. IT IS NOT TOO LATE. WCAG 2.0, stripped of nav and comp can sail >>through to recommendation status and we can give the remaining two aspects >>of accessibility the attention they truly deserve. >> >>Since the current draft is scheduled to go public in the next 48 hours, if >>you think that this is worth at least a telecon, please SPEAK NOW. >> >>Chas. Munat > >Anne Pemberton >apembert@erols.com > ><http://www.erols.com/stevepem>http://www.erols.com/stevepem ><http://www.geocities.com/apembert45>http://www.geocities.com/apembert45 >
Received on Monday, 20 August 2001 10:58:53 UTC