W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2005

RE: Update and Proposal for going forward - REVISED

From: Bailey, Bruce <Bruce.Bailey@ed.gov>
Date: Tue, 20 Dec 2005 11:05:40 -0500
Message-ID: <CCDBDCBFA650F74AA88830D4BACDBAB50B2D4A83@wdcrobe2m02.ed.gov>
To: "Gregg Vanderheiden" <gv@trace.wisc.edu>, <w3c-wai-gl@w3.org>
I am concerned that WCAG 2.0 seems to be on a fast track when, to my mind, there are some significant rough edges.  Sure, no amount of work will make the document perfect, but there still exist large gaps.  The three biggest IMHO:
(1)  Success criteria are too sparse to justify three conformance levels.  There is still one guideline with zero level 1 success criteria.
(2)  The Understanding WCAG 2.0 document is a fantastic approach and the current version does more than provide excellent proof of concept, however, it lacks sufficient examples, especially with regard to non-HTML technologies.  (This is category 2 in the list of priorities below.)
(3)  From browsing bugzilla I noted that the need for usability testing was identified over three years ago.  As far as I know, this is a significant that has yet to be addressed:

Two other issues/questions:

The 16 December Editor's draft hasn't helped with one area of difficulty for me.  I am still having a great deal of difficulty discriminating between 4.1.2 and 4.1.5, and the presence of 4.1.3 and 4.1.4 muddies this up even more.

I like the definition of blink (turn on and off between .5 and 3 times per second) but it is somewhat in conflict with the values used in 508 (and associated with flicker for WCAG 1.0) and perhaps even with the definition for general or red flash threshold (there are more than three flashes within any one-second period).  Am I correct to understand that something cycling at 3 hertz is blinking but not (per WCAG 2.0) flashing?  This distinction might be deliberate.


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Gregg Vanderheiden
Sent: Wednesday, December 14, 2005 12:26 PM
To: w3c-wai-gl@w3.org
Subject: Update and Proposal for going forward - REVISED 

Update and Proposal for going forward


Congratulations working group members on the Nov 23rd draft and Understanding doc.   

The good news

I have gotten many compliments and some notes of amazement at the progress.    I believe we will get a strong review of this draft and should have good feedback on any areas of concern.    

The rest of the story.

We still have work to do and issues to clear.  I have also heard from higher up in the W3C that there is a feeling that our guidelines are becoming quite mature and quite overdue.   They would like to see us dig in and move this through the final steps without further ado.   They reminded us that no amount of work will make the document perfect - much to the disappointment of many of us. 


For those not familiar with the final steps they are: 


Last Call

      A Working Group's Last Call announcement is a signal that:

*	the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; 

*	the Working Group believes that it has satisfied significant dependencies with other groups; 

*	other groups SHOULD review the document to confirm that these dependencies have been satisfied. 

*	a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. 

Candidate Recommendation (CR)

A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.

Proposed Recommendation (PR)

A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement.

W3C Recommendation (REC)

A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations. 


Each of these takes work and is subject to external review.  For a description of the process I recommend reading section 7 of the W3C process document. It doesn't take long and it is located at    <http://www.w3.org/2005/10/Process-20051014/tr.html> http://www.w3.org/2005/10/Process-20051014/tr.html

As I mentioned there is great pressure for us to actually get to last call.    Many don't think we will ever finish -  and some are starting to go off on their own.  That is their choice but if they do we start getting standards fragmentation and all the problems that creates.  




What do we need to do to get to last call?  We looked over our bug lists and we have closed an amazing number of them. We are getting there!  After this week's call we will be logging all closures and will give you some counts.   But we are closing on it.  


We have also been talking about how to move forward - and one suggestion we would like to implement is to separate all of our outstanding issues into those that we need to close before going to Last Call - and those that are informative parts of support docs and can be cleaned up later.   We are proposing to dividing up current (and future) issues into the following categories.  


Category 1   Issues that affect Guidelines or Success criteria directly or indirectly 

a.	Items that will or are very likely to impact the normative content.  Some of these items may not be normative - but they may determine whether our normative content is worded correctly, is implement-able in a testable way etc. 

b.	These items include       

                                                               i.      Most anything in Guidelines doc except parts of intro and some appendices (e.g. mapping)

                                                             ii.      The "sufficient techniques" section of "Understanding WCAG 2.0"  (UW2)

                                                            iii.      All technique docs (including test for each technique) for those techniques mentioned in the Sufficient Section.

Category 2   Informative Sections of Documents

c.	Informative sections are sections that explain but do not define 

d.	This includes 

                                                               i.      Examples  (except in techniques where they may be required for understanding)

                                                             ii.      Benefits 

                                                            iii.      Introductions (except conformance sections) in Guidelines, Understanding, and Technique collections. 

                                                           iv.      Intent sections of UW2  (mostly done)

Category 3   Optional Techniques - that are above and beyond the Guidelines and Success criteria.

e.	Any techniques in "Advisory section" of   SC or Guidelines in the UW2 doc.  

We suggest that 

1)       The working group efforts and task forces be focused on  Category 1 Issues.

2)       All Category 2 bugs and comments dealing with Informative Sections be delegated to the WCAG 2.0 Editors

a.       Editors would address the informative comments

b.      Anything they feel is controversial they would bring to the working group as survey etc (Iike #1)

c.       Otherwise they will address the editorial material and make edits.  The working group will then review the final text of informative sections and approve or make comments (bugs) for Editors to address. 

d.      (note:  as task forces work on category 1 items they may also pass suggestions to editors for #2 items - but not so that it slows down category 1 work.)

3)       We only work on Category 3 items after we are out to Last call - and are waiting feedback.  We can use this as background work and fill in as we can but don't hold up Last Call publication for them.   They are by definition informative and can be added at any time later.  


We need to remember that we could polish this til the end of time (and still not be done - grin).   We need to get all the substantive edits done (or decide that we can't do it in this version) and move this document out.  (We are wildly overdue).    

We are proposing to

1) re-activated our task forces and have them 

1)       Take each guideline and, for each of its success criteria review the related UW2 sections to create needed technique docs

a.       Make sure a technique doc exists for at least one technique for each "Situation"  in the 'Sufficient Techniques" section 

b.      Make sure there is a 'test' for each of these sufficient techniques.  (test = machine or human procedure for determining if one has successfully carried out the technique).

c.       Create technique (including test) doc if it doesn't exist and bring to WG for approval

d.      NOTE:  we only need to have one technique for each situation described in the "Sufficient Techniques" section-- however, when techniques must be combined in order to be sufficient, we will need to create the set of techniques. (For example, if the Sufficient Techniques section lists technique 1 AND technique 2 AND technique 3, all three techniques must be created.  We will do the rest before CR but we need one for sure for each situation before Last Call so we can ensure they are achievable. 

2)       Propose any new or modified Sufficient Techniques  (if you identify one.  Don't focus on this til #1 is done for all)

3)       Propose any changes to success criteria or guidelines that become apparent through the above activities and are important/critical. (not just fine tuning).

4)       Propose any language to close Type C (informative) items to Editors - or just pass any open TYPE C issues directly to Editors for them to wrestle (not as nice for editors - but much better than delaying steps above) 

2) Have the Guideline editors go through Bugzilla and categorize the bugs as  1, 3 or 3 (per above).  

The editors would then Tackle category 2 issues  (in addition to participating in task forces...). 

3) Leave Category 3 until later 

(along with any Category 2 that are not easily done and not seen as critical to understanding the normative content).  


This proposal will be discussed on Thursday - so give it a think and come with any questions. 


Thanks much. 


For the chairs and staff contact.  
Received on Tuesday, 20 December 2005 16:06:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:57 UTC