- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Thu, 18 Sep 2003 10:53:16 -0500
- To: <gv@trace.wisc.edu>, "Sailesh Panchang" <sailesh.panchang@deque.com>, "Jason White" <jasonw@ariel.ucs.unimelb.edu.au>, "Web Content Accessibility Guidelines" <w3c-wai-gl@w3.org>
- Message-ID: <B3DC65CD2AA7EF449E554548C6FE1111135717@MAIL01.austin.utexas.edu>
I still have some fundamental concerns about the idea that CORE checkpoints are (or should be) those that don't require content developers and designers to change the default visual presentation. My concern is both philosophical and pragmatic. I am not interested in mere conformance; I'm interested in accessibility. And I'm convinced that accessibility *does* require different ways of thinking about the design of Web resources. The most common design practice is to begin with look and feel; to come up with a compelling visual presentation-- often presented for design review in the form of Photoshop *images*. Once everyone agrees that it *looks* good, someone *may* ask how to make that design accessible. This means that they're retrofitting for accessibility before they've even begun to implement the design! It's *much* more difficult that way, and the results are much less satisfying-- like putting up a brand-new building and then saying, "Oh, where should we put the wheelchair ramp?" I'm sure I would feel differently if more of the default visual presentations of Web content were more usable by the temporarily able-bodied. But there are all those usability studies in which people without disabilities fail to complete routine tasks somewhere between 40 and 60 percent of the time. So what's the point of tying ourselves in knots to preserve default visual presentations that are hard for *everybody* when forcing people to think harder about design might actually make things better for everybody, too? That's the pragmatic concern. The philosophical one goes something like this: Accessible design is an extension of user-centered design. I'm concerned that the current criteria for distinguishing "core" from "extended" is *developer*-centered. Not that developers aren't among the end-users of our documents; but ultimately the guidelines are in the service of end-users who have disabilities. I would argue, then, that extended checkpoints that we agree are truly important to meeting the needs of users with disabilities should go into the "core." John "Good design is accessible design." Please note our new name and URL! John Slatin, Ph.D. Director, Accessibility Institute University of Texas at Austin FAC 248C 1 University Station G9600 Austin, TX 78712 ph 512-495-4288, f 512-495-4524 email jslatin@mail.utexas.edu web http://www.utexas.edu/research/accessibility/ <http://www.utexas.edu/research/accessibility/> -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Thursday, September 18, 2003 10:09 am To: 'Sailesh Panchang'; 'Jason White'; 'Web Content Accessibility Guidelines' Subject: RE: Conformance levels and core /extended In 1.0 it was priority 1,2,3 based on user need In 2.0 the dividing line between core and extended is not user need but whether it involved constraining the content or presentation. Core do not make you change the document visually - just mark it up or add hidden text (or audio) equivalents. There are many extended checkpoints that are VERY important. The closes thing we have to P1 and P2 was the two levels of implementation for each checkpoint. But the discussion of late has been to drop those. The result is (or would be if we have no levels) that we do not have any priority rating or indications of importance. It is true that all the core checkpoints are important. But it is not true that all the important checkpoints are core. We need to think about this.... I like the simpler form we have - but I worry that the simplicity is coming at the expense of completeness or proper comprehension of the checkpoints. Perhaps instead of core and extended we should name them something like - content neutral - content amending or something. I wouldn't suggest those terms but you get the idea..... I just can't think of the right terms off the top of my head. Thoughts? -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Sailesh Panchang Sent: Thursday, September 18, 2003 10:02 AM To: Jason White; Web Content Accessibility Guidelines Subject: Conformance levels and core /extended I do not see how the "impossible/difficult/easier approach worked out in WCAG 1.0" corresponding to P1, P2, P3 terms is different from core and extended. Core checkpoints signify that they are vital to accessibilitty just as the P1 or "impossible to access" checkpoints indicated in 1.0. What is termed as extended now are supposed to enhance accessibility/usability just as P2 and P3 checkpoints did. I fail to see how they are "very different" from the P1, p2 scheme and why the WCAG1 scheme is "untenable". If "conceptions of conformance levels have changed so radically " since 1.0, these are not brought out in the WCAG 2.0 requirements doc nor explained in the WCAG 2. I believe it is really important to convey these differences especially to advocate transition from WCAG 1 to 2.0. Can I turn to some document for the new concepts underlying WCAG 2? Nor have the terms core and extended been defined anywhere in WCAG 2.0. The choice of terms "core" and "extended" certainly need further deliberation and justification. Sailesh Panchang On Tuesday, September 16, 2003 12:07 AM Jason White <mailto:jasonw@ariel.ucs.unimelb.edu.au> wrote Subject: Re: Conformance levels and best practices "Others have argued, however, that precisely because the conceptions of conformance levels have changed so radically between WCAG 1.0 and WCAG 2.0, the same terms (Priority 1, Priority 2 and Priority 3) should not be carried forward into the 2.0 document, as this would create confusion for those who are already acquainted with the 1.0 conformance structure and its definitions. In developing WCAG 2.0, the distinctions underpinning the 1.0 priority definitions were subjected to detailed, critical scrutiny, with the result that the working group decided they were no longer tenable for purposes of the 2.0 document, and that a new set of distinctions was needed to classify checkpoints and success criteria in constructing the 2.0 conformance scheme. The argument for new terminology, then, is that unless different terms were used, readers acquainted with 1.0 would construe 2.0 as following the same, or a similar, system of priorities and conformance levels as WCAG 1.0, and would make policy decisions and claims about accessibility on that erroneous, but tempting, presupposition. The new terminology is supposed to signal the fact that the 2.0 categories of core and extended are very different from the 1.0 priorities, and that the impossible/difficult/easier approach worked out in the 1.0 conformance scheme does not apply to 2.0." My purpose in stating these arguments is not to defend them, though I do happen to find them persuasive, but to attempt to recapitulate the reasons which led the working group to the conclusion that new terminology was needed and that retention of the old terminology would do more harm than good. Comments, counter-arguments and proposals are, of course, most welcome. If anyone is dissatisfied with the working group's prior decisions on this matter, the issue should be re-opened in the context of our ongoing conformance discussion. " On Mon, 15 Sep 2003, Sailesh Panchang wrote: > > 1. I believe the words Priority 1, 2 and 3 with their definitions conveyed that the focus of the checkpoints was on successively increasing levels of accessibility ... vital -essential-desirable for accessibility, in a way better than that conveyed by the terms coreand extended. Admittedly, there are different perspectives on the priority levels assigned to some checkpoints in WCAG1. But a P3 checkpoint enhances accessibility and therefore usability and shows the way ahead as is intended for "best practices". So why not stick with the terms P1, P2 and P3... it will also be "backward compatible"... Goal 6 for WCAG2 in requirements doc. The required success criteria should be categorized as P1 or P2 or P3.
Received on Thursday, 18 September 2003 11:53:18 UTC