RE: Conformance levels and core /extended

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