Comments on WCAG 2.0 draft, 24 June 2003

This document has the profound effect of synthesizing 
the needs of those who publish webpages with the needs 
of those who use them. Many thanks to the working group 
for this work.

WCAG questions:

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.

    + Because this document serves such as wide audience,
      it would be helpful to simplify the language a little
      unless the style is a prescribed convention
      for W3 documents. Could a more familiar term
      such as "recommended" be substituted for "normative"?

      I have included notes and suggested a few wording changes.

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?

    + I like the change to two levels rather than three,
      and the new terminology. Perhaps more people
      will try to satisfy both levels when there are only two. 
      Since the new document is general and abstract
      to make it less technology-specific, the forthcoming
      supporting documents will be very helpful for specifics.

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.

    + Experience with WCAG 1.0 will make it easier to figure out
      and use WCAG 2.0. Task-specific documents, such as
      "Programming webpages for accessibility" or
      "Writing accessible content for webpages"
      might helpful in addition to, or as part of,
      technology-specific technique documents.     
      A potential benefit of task-oriented documents is to widen    
      the audience and include more people in accessibility efforts.

NOTES AND SUGGESTED WORDING CHANGES:

How to Read this Document
2 - Technology-specific Checklists

In addition to the forthcoming technology checklists,
I suggest developing task-specific guides, such as
"Programming webpages for accessibility," 
"Writing accessible content for webpages," 
"Editing accessible content for webpages," or
"Accessibility in designing webpages" for instance.

Audience

  Suggested wording change, "many different audiences":

  I suggest something like: "...many different audiences 
  who make policy, create content, and code pages."

Priorities and Techniques

  The mapping document is very helpful. Thank you!

Best Practice for Checkpoint 2.1 (Operability)

  Would it be possible to include an example alternative coding method here? 

  I'm not sure what sort of method I would try, or whether it would be
acceptable. Thanks.

3.3 (Content)

  The recommendations for writing style apply to
  all types of communications media and might be
  too broad or tangential for accessibility guidelines. 

  Maybe the recommendations could be placed
  in a separate list or supporting guidebook for editing web content.

Examples of Checkpoint 3.4 (Informative)

  Example 2

  From a usability standpoint, some designers 
  suggest avoiding arrows before links
  because symbols don't give users enough information about
  the result of clicking the symbol.
  Maybe just text, such as,
  "[OPEN THIS LINK IN A NEW WINDOW.]"  would be sufficient, right after 
  the link, unless a page is loaded with many links of this type.
  More specific examples like this one would be helpful
  throughout the document.

  Example 3

  So many nonfunctional Back buttons appeared with the
  emergence of .jsp and .asp pages that I wondered if
  nonfunctional Back buttons might not be easily controlled 
  through code in some languages. Perhaps an expert
  in those languages has confirmed this example.

Guideline 4 (Robust)

  Wording suggestion: 

  "Use Web technologies that optimize content for 
  compatibility with current and future accessibility 
  technologies and user agents."

  Could an example be included?
-----
Preferred address for accessibility work:
Joyce Tikalsky
jatikalsky@mailbag.com
608/873-6944

Also:
webmaster@engr.wisc.edu
608/265-8669

Received on Wednesday, 10 September 2003 07:49:08 UTC