Technology-specific checklists

Hi,

 

As an introduction to our discussion of what the Technology-specific
Checklists layer of WCAG 2.0 might look like, Paul, Wendy and I have
been working on a few sample pages and collecting issues and ideas for
the group to review as we begin the process of making decisions about
how the checklist should take shape. The checklists, which are described
in the second section of "How to read this document" in the latest
draft, are intended to "provide information on what is required when
using different technologies in order to meet the WCAG 2.0 Working Draft
access guidelines."

 

Much of the information included below is a compilation of ideas and
discussions that began in small group work at the July face to face in
Linz. In case anyone is interested in reviewing the discussion that took
place there, I've added links to the original draft pages that were
presented at the end of the face to face to the minutes, which are
available at
http://www.w3.org/WAI/GL/2002/07/f2f-minutes.html#subgroup-checklist.
Many thanks to Paul, Bengt, Avi, Christian and Wendy for help in
brainstorming and working through these ideas. 

 

Issues and questions:

 

*	In addition to understanding how to succeed in meeting the
guidelines, how can this checklist also describe how and where
techniques or technologies might fail? For example, should the document
make it clear that, for a technology that by definition can not address
a specific checkpoint, make a statement asserting that meeting a
checkpoint in a given technology is not possible? Some suggestions for
addressing this issue include: 

1.	only generate techniques documents for technologies that meet
WCAG 2.0 at the minimum level 
2.	include a "not possible" category that describes how some
techniques or technologies may fail and suggest alternatives 
3.	create an other technology that allows for newer technologies
and techniques to be used in meeting a checkpoint. That way, the message
isn't that authors shouldn't use a technology. Instead, it simply means
that we don't have techniques yet and provides an opportunity for author
to explain how the checkpoint was addressed. 

*	How much ongoing work will the group be able to do on this layer
(and the techniques documents) after WCAG 2.0 becomes a recommendation? 
*	If the checklists include all of the checkpoints (21 in latest
draft), success criteria (80 in latest draft) and techniques (there will
likely be multiple techniques for each success criteria) in one place,
the document is likely to become quite long. How can we best optimize
the checklists so that they are optimally usable and minimally
overwhelming?    
*	At this point, it's not clear exactly how the techniques relate
to whether or not an author has passed or failed a given success
criteria. For example, where 5 techniques exist to address a single
checkpoint, it's not clear how the techniques would be prioritized. Is
it possible that in some cases one technique will be
preferred/recommended over another given the current state of user agent
support? Will it be possible to insert something that, for example, says
you will have passed a success criterion if you have applied x number of
techniques below? 
*	For level 2 assurance type success criteria (e.g. the content
has been reviewed and .), should a unique set of techniques be included
for each? Would all of the review requirements of this type be addressed
with the same set of techniques or would these recurring techniques be
described elsewhere? Also, does it make sense to include a space for a
reviewer/author to document what they've done or observed related to the
review process? 
*	Checkpoint 3.3 was included in the sample checklist drafts so
that we could take a look at how a checkpoint that includes additional
ideas might look. Does it make sense to include the ideas here or is it
likely that each idea will need its own list of techniques?
*	The drafts currently don't link into the techniques documents
because there's nothing to link to at this point in time. When we do add
links, do we want the entire rule element that will be pulled from the
techniques to become a link or should we consider including a techniques
numbering system and provide shorter links at the front end as we have
with checkpoints and guidelines?

 

Draft pages:

 

*	An example of a basic checklist layout is available at
http://www.w3.org/WAI/GL/2002/08/checklist_proposal_example1.htm. Though
there are a number of areas where information is missing, not yet linked
in, or not yet available, it illustrates how we might handle different
types of checkpoints and success criteria in checklist form and puts
forth some ideas for addressing some of the issues described above. 
*	An alternate example, available at
http://www.w3.org/WAI/GL/2002/08/checklist_proposal_example2.htm,
illustrates how the checklist may be presented in a more block-level
organization. This layout provides some more explicit grouping of
success criteria under their respective checkpoints as well as changes
the order in which the information is presented by presenting the
techniques available for addressing a particular success criteria before
querying the user for pass/fail decisions. Additionally, this layout
provides additional space for an author or reviewer to include notes as
to how a success criteria passed, failed, or did not apply. 

 

Next steps:

 

*	Paul has been working with some of the ideas surrounding
creating static and interactive renderings of the checklist document and
will be posting a follow-up note describing some of the issues and ideas
we've addressed thus far. 
*	Wendy will create a page to add to the above collection of links
that will show how an author might utilize the checklists to evaluate a
page or site. 
*	A number of organizational changes will need to be made to the
current working draft in order to effectively refer to individual
success criteria. 
*	Once we have consensus on how the checklists will take shape, a
transformation to automate the process of pulling the appropriate
information from the guidelines and techniques documents will need to be
developed so that we can easily update the checklist as each source
documents evolves. 
*	We'd also like to tie in some of the work that is being done at
W3C in the internationalization group regarding implementation
guidelines to generate more dynamic views of the checklist. Richard
Ishida, who is a W3C team member and has had some experience developing
implementation guidelines for Xerox has been sharing some of his
philosophies about creating checklists with us recently and we're hoping
to collaborate further with him to explore some ideas for creating
document views that are somewhat more interactive and flexible. An
example of this might be to utilize an expanding/collapsing mechanism
that would allow users to drill down through the checklist, exposing,
for example techniques for a given success criteria one at a time. 

 

Discussion on this topic is on the Agenda for the September 5 Telecon.

 

Thanks,

 

-Ben

--
Ben Caldwell |  <mailto:caldwell@trace.wisc.edu> caldwell@trace.wisc.edu
Trace Research and Development Center ( <http://trace.wisc.edu>
http://trace.wisc.edu)