Re: Request for Review: WCAG 2.0

August 22, 2003 - A group* of UW-Madison staff gathered to discuss the WCAG 
2.0 draft. The individuals gathered represented technology 
instructors/trainers, faculty support, consultants, web site and web 
application developers-all are web accessibility advocates who work with 
instructional, department faculty and staff. We have been involved with web 
accessibility issues and support on the UW-Madison campus for several years.


1. In general, is this WCAG 2.0 Working Draft easy to understand? Please 
identify sections or phrases that are difficult to understand. Please 
suggest alternative wording for the Working Group to consider.

We are familiar with, and often reference or make recommendations based on 
the work of WCAG 1.0. Our campus' original web accessibility policy 
(December 2000) was based on WCAG 1.0, level AA+.  Many of us gave input to 
the original policy. That policy was revised (October 2001, and again April 
2003) -the revised policy  endorses compliance with Federal Rehabilitation 
Act's Section 508 standards. None of us were involved with the October 2001 
change-several did give input to the 2003 revision.

We found that the WCAG 2.0 deviates too much from 1.0, both in terms of 
content and organization. We struggled with mapping. Our brains wanted to 
reference what we were familiar with.

Overall,  we felt the document no longer was for our audience (we are in 
support roles) - the document feels highly technical and specialized. We 
had difficulty mapping WCAG 2.0 with 1.0. Our brains were trained and 
familiar with priorities and levels, and we struggled with not being able 
to make correlations and  connections with what we knew and were familiar 
with and the new document.

A more general comment is that the "Perceivable" category we found to be 
very subjective, and difficult for us to get agreement or  understanding on 
- apologies, but we don't have a substitute term - we are not in agreement 
if this term or the concepts in this category add to the strength or 
confusion of the document.

2. The conformance structure of this WCAG 2.0 Working Draft differs from 
WCAG 1.0 and from the previous WCAG 2.0 Working Draft. Is the concept of 
Core and Extended checkpoints easy to understand? Is this an effective 
structure?

We appreciate that now with WCAG 2.0 is referencing four (4) guidelines 
(Perceivable, Operable, Understandable and Robust) instead of fourteen (14) 
guidelines. The "Benefits" of each checkpoint are valuable . . . especially 
when they extend beyond benefits to people with disabilities. We also value 
that eh design principles represent broad concepts, situations and 
technologies, including those that do not yet exists.




3.     If your site or organization already uses WCAG 1.0, do you think it 
will be difficult to migrate from WCAG 1.0 to WCAG 2.0, based on the 
current draft? Please note that the Working Group is developing supporting 
documents such as technology-specific techniques documents and checklists 
for WCAG 2.0.

Our campus policy is based on 508 (which we feel in many ways borrow from 
or parallels much of WCAG 1.0, level A+). We have done a great deal of work 
to educate our campus web developers and those who maintain websites, 
develop curriculum , and tools for evaluating web site compliance. Tthe 
giant leap necessary to relearn terms, layout (structure) etc. for WCAG 2.0 
would jolt our audience into "shut down" or "turn off" - It's been a long 
hard road to get to where we are now, and we don't believe our audience 
could handle the transition.

We often used WCAG1.0 as reference. For example if someone was having 
trouble constructing an accessible table, we knew exactly where the 
reference was, and it wasn't clear in the table of contents.  We were not 
clear  (from the table of contents) where to look - other areas such as 
style sheets, deprecated HTML, fonts are additional examples-we were not 
sure how / where to look. The table of contents was described as a Rabbit 
Warren from "Watership Down" - needing to be indexed.

We valued having examples follow benefits. We question what skill level 
your target audience is.

Checkpoint 2.5 Example 1: a search engine. A search engine is provided with 
a variety of search options for different skill levels and preferences. It 
includes a spell checker and offers "best guess" alternatives, 
query-by-example searches, and similarity searches.

This is an example of "high technical level" - a skill that a faculty, 
instructor or teaching assistant on our campus would not possess. In fact 
only one in our group possesses this skill. This example would send people 
we work with out of the room in a state of overwhelm.  Perhaps if it was 
possible to provide levels for web developers to identify with or relate 
to, for example, if you are:

- I.   New to the Web or have little experience . . . (core)
- II.  Experienced Web  Developer. . . (core plus)
- III. Extensive Experience as a Web Developer . . . (extended)

We also struggled with how we would evaluate or validate sites if our 
campus policy were based on WCAG 2.0?

We recognize that there other supporting documents being developed to 
support the guidelines, however if our users shut down at this stage, we've 
lost our opportunity if they shut down.




*group =
Alice Anderson,  Division of  Information Technology, Technology 
Accessibility Program (administrative)
Blaire Bundy,  Division of  Information Technology, Learning Technology and 
Distance Education, (faculty and instructional staff support)
Greg Konop,  Division of Information Technology,  Professional and 
Technical Education,
(campus technology training)
Lisa Jansen,  Letters & Science,  Learning Support Services 
(department  support)
Kevin P. Thompson, Professional and Technical Education,
(campus technology training)
Wei-zhong Wang, Division of Information Technology, Help Desk, (Help Desk 
Web site, and campus "web doctor" campus web validation)

Received on Wednesday, 3 September 2003 09:32:21 UTC