W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2007

Re: WL's Relative Priority comment

From: Jan Richards <jan.richards@utoronto.ca>
Date: Fri, 19 Jan 2007 16:49:05 -0500
Message-ID: <45B13CD1.1020104@utoronto.ca>
To: w3c-wai-au@w3.org

Unfortunately, difficulty understanding the relative priority mechanism
seems to be a recurring theme.

I can see several possible routes forward (with B.2.2 as an example):

---------------

(1) Continue with "Relative Priority" but give the explanation a 
thorough re-write.

---
RESULT: Checkpoint B.2.2 REMAINS THE SAME
---

(2) Drop "Relative Priority" and explain it in the checkpoint Priority 
label (we would need to link the WCAG levels to an area that explained 
that it could be WCAG 1.0 or 2.0):

---
RESULT: Checkpoint B.2.2 might look like this:

B.2.2 Check for and inform the author of accessibility problems.
[Priority 1 for *WCAG Single-"A"*, Priority 2 for *WCAG Double-"A"*, 
Priority 3 for *WCAG Triple-"A"*]...REMAINDER IS THE SAME
---


(3) Take a MAJOR plunge and use WCAG 2.0's new multi-Level structure:

---
RESULT: Checkpoint (B.2.2) might look like this:

B.2.2 Check for and inform the author of accessibility problems.

Level 1 Success Criteria

SC1: An individual check must be associated with each requirement in the 
Benchmark Document, where the Benchmark Document has a *target WCAG 
conformance level* of *Single-"A"*.

SC2: For checks that are associated with a type of element (e.g., img), 
each element instance must be individually identified as potential 
accessibility problems. For checks that are relevant across multiple 
elements (e.g., consistent navigation) or apply to most or all elements 
(e.g., background color contrast, reading level), the entire span of 
elements must be identified as potential accessibility problems, up to 
the entire content if applicable.

SC3: If the authoring tool relies on author judgment to determine if a 
potential accessibility problem is correctly identified, then the 
message to the author must be tailored to that potential accessibility 
problem (i.e., to that requirement in the context of that element or 
span of elements).

SC4: The authoring tool must present checking as an option to the author 
at or before the completion of authoring.

Level 2 Success Criteria

SC5: An individual check must be associated with each requirement in the 
Benchmark Document, where the Benchmark Document has a *target WCAG 
conformance level* of *Double-"A"*.

Level 3 Success Criteria

SC6: An individual check must be associated with each requirement in the 
Benchmark Document, where the Benchmark Document has a *target WCAG 
conformance level* of *Triple-"A"*.


---------------

I suggest we discuss these options on a call or F2F.

Cheers,
Jan





William Loughborough wrote:
> 
> I realize I'm a bit late to the party with this, but I've been mulling 
> it over for several years and find it almost as hard to comment on as it 
> was to write this part of ATAG in the first place..
> 
> Specifically, the whole business of relative priorities is 
> dense/opaque/impenetrable and although I have no specific language that 
> will change that, it is important that further effort be expended trying 
> to make this dark thing clear.
> 
> Perhaps if you try to think of it as an English-to-English translation 
> it might help. The basic idea that the priority of something depends on 
> "external" factors should be amenable to some simplified text.
> 
> As it stands, I have always felt that it's a poster child for 
> obscurantism (or is that "obfuscation"?). I urge you to look in 
> isolation at the text starting at ["Relative Priority" Checkpoints] and 
> in particular the part labeled [Relative Priority Checkpoints in 
> Practice] and imagine yourself as someone trying to develop an 
> ATAG-compliant authoring tool. Perhaps it's my creeping senility, but it 
> just puts cognition barriers in my path to understanding what in the 
> world we are talking about here.
> 
> Love.
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896
Received on Friday, 19 January 2007 21:49:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT