25 Sept WCAG WG telecon summary

Today's discussion was based on the recent reorganization proposal (reorg 
#4) from Ben and Gregg [1].

Summary of action items:
1. action: john, katie, and (others who are interested) work on list of 
terms to use for wcag 2.0.

===
Summary of discussion

Many people were concerned about the number of axes that apply to each 
statement in the document:
- normative vs informative
- core vs extended
- required success criterion vs best practice vs additional note

(During the call, Yvette made a diagram of axes.  description and link at [2]).

Because of the complexity, it is difficult to determine what is required vs 
what is optional.  A variety of simplifications were proposed (and some 
variations also discussed). The common theme among these is to find some 
way to keep best practices distinct from success criteria.
1. combine best practices and additional notes
2. move best practices and additional notes to a separate document, or an 
appendix
3. flatten the layers into a single axis but create 3 levels (similar to 
p1, p2, and p3 in wcag 1.0 but with different terms.  in other words, 
replace the current matrix of distinctions with a linear one)
4. reconstruct the document so that current checkpoints become guidelines 
(or in some way remove checkpoints to decrease confusion with 
technology-specific checklists).
5. rename "best practice" "additional criteria"
6. move best practices to extended checkpoints
7. move additional notes to techniques gateway
8. call best practices "additional measures that go beyond conformance"
9. restructure so that most important stuff stands out most

Concerns about these proposals included:
1. If best practices and additional notes are combined, do we dilute the 
group?  They had been one group (best practices) but were split because 
some of the best practices were testable and seemed more important than 
some of the additional notes.  Do we want to go back to that organization?
2. If we put best practices in a separate document it will not be read.  We 
need to keep all of the information in the document that will help people, 
even if it is not testable.
3. If best practices are included and not testable, do they have a place in 
the document?
4. We attempted to move best practices to extended checkpoints (reorg 
proposal #2) but found it difficult to uniquely name each new extended 
checkpoint.
5. If something is not required, it should not be part of the standard.
6. We should use "must, should, not" language as used in other standards 
(and defined in RFC 2119 [3]).

General concerns that surfaced during the discussion:
1. Which is our primary goal: to write a document that addresses all of the 
needs of people with disabilities or to write a document that is 
testable?  Does our Requirements document accurately and unambiguously 
reflect our scope and goals?
2. "Required Success Criteria" in Extended checkpoints is confusing.  When 
asked if we should remove the word "Required" the group felt there was a 
deeper issue that needed to be addressed and that removing the word would 
not solve the issue.
3. If we want different legislative bodies to create similar policies 
(i.e., adopt what we recommend), even though we are not making policy if we 
don't produce something that is effective legislative bodies will produce 
differing policies.
4. If the document is named "Web Content Accessibility Guidelines" but does 
not address all disabilities it should be renamed.
5.  Only the 4 guidelines are general enough to stand the test of time and 
apply to all technologies; particular concern about voice and mobile 
applications.

Broader ideas that people seemed to like:
1. Write "the book" that includes everything for those audiences who are 
motivated to do more and only include the minimum requirements in the standard.
our primary audiences are:
- people who want to make policy,
- people who care about accessibility and do so without a legal mandate, 
i.e. highly motivated and interested in "doing more")
- people who don't care and will only do the minimum
The minimum set of criteria should be what we assume cynic implementors 
will do. For those who want to do more, have "the book" that describes this 
in prose. The UAWG has "common UA imp problems" we could have a similar 
document that could accompany "how people w/disabilities do the web."  It 
could be "wcag for policymakers" either in an introduction or a separate 
document.  Or "the book" would describe "what is accessibility? what do you 
need to make the web accessible?"
(In his personae document, Tom's matrix lists two types of people in our 
audience those who are willing and those who are not willing. [4])

2. Simplify the language that we use.
Set up focus groups to determine which terminology will work best.  Start 
with the plain language lexicon (1500 words) and see how many more we need 
to add to express the ideas.  (refer to techniques telecon discussion about 
personae, glossary, and cultural issues [5])

IRC Log of this telecon is at:  http://www.w3.org/2003/09/25-wai-wcag-irc.html

Best,
--wendy

[1] http://www.w3.org/WAI/GL/2003/09/reorg4/reorg4.html
[2] http://www.dutchgenealogy.nl/test/wcag_3d.gif
There are three axes:
- the x axis lists core and extended
- the y axis lists success criteria, best practice, informative
- the z axis lists perceivable, operable, understandable and robust
[3] http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2119.html
[4] pdf: http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0497.html
text: http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0499.html
[5] http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0613.html

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Thursday, 25 September 2003 18:39:06 UTC