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

RE: Update and Proposal for going forward - REVISED

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Thu, 22 Dec 2005 13:23:27 -0600
To: "'Bailey, Bruce'" <Bruce.Bailey@ed.gov>, <w3c-wai-gl@w3.org>
Message-ID: <007b01c6072d$3124dce0$ee8cfea9@NC6000BAK>
Hi Bruce.  

 

 

If you have some good examples (see #2 below) please send them on.  That is
not our priority right now (which is focused on getting the success criteria
right) but would love to have more in there.  If you have some please send
in. 

 

Usability testing is part of implementation - which is the next phase. 

 

You wrote:

 

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.

Yes - you are correct.   Blinking is a distraction issue - flashing is a
seizure issue.  They are covered in different places in WCAG 2.0

 


Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

 

 


  _____  


From: Bailey, Bruce [mailto:Bruce.Bailey@ed.gov] 
Sent: Tuesday, December 20, 2005 10:06 AM
To: Gregg Vanderheiden; w3c-wai-gl@w3.org
Subject: RE: Update and Proposal for going forward - REVISED

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:
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=200#c0

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.

Thanks.

-----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:


Stages 


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.  

 

So.

 

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. 

Gregg,  

For the chairs and staff contact. 
Received on Thursday, 22 December 2005 19:23:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:41 GMT