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

IBM Comments on WCAG 2.0 Public Draft 22 August 2002

From: Andi Snow-Weaver <andisnow@us.ibm.com>
Date: Tue, 29 Oct 2002 17:41:09 -0600
To: w3c-wai-gl@w3.org
Cc: "Phill Jenkins" <pjenkins@us.ibm.com>
Message-ID: <OF986D603A.B6B27BDA-ON86256C61.0081C418@boulder.ibm.com>

Here are the IBM comments on the WCAG 2.0 Public Draft, dated 22 August
2002.


Front matter

   Add the following links in the section where the links to "this
   version", "latest version", and "previous version" are.

   - Errata: The Comm Team policy is now that errata and translations links
   must appear in at least the head of the document.

   [1] Example of errata & translations in top matter of W3C spec

   http://www.w3.org/TR/P3P/



   - Related Documents: There needs to be a link to a related documents
   "page", that can change so as WAI documents are added or rearranged, you
   have a place to go to find out how they are related.  As techniques,
   checklist format versions, and other guidelines documents are added,
   this "related docs" page could sort them all out and present them is a
   logical manner and not depend on the reader to have to read and gather
   bits and pieces along the way from each WAI recommendation to construct
   the organization and relationships.



   - Table of Contents: A link on the top of the page that "skips over" all
   the top matter and gets to the table of contents is needed.  Everyone is
   equally hindered by having to page down and tab forever to get to the
   meat - the Table of contents of the recommendation.



Checkpoint 1.1

   Minimum success criteria

      - There should not be a success criteria for non-text content that
      "cannot be expressed in words". Checkpoint 1.1 begins with the phrase
      "For all non-text content that CAN be expressed in words". Worded
      this way, the checkpoint does not apply to "non-text content that
      canNOT be expressed in words".

      - the sub-bullet under item 2 seems to belong with item 1. Item 2
      states that non-text content that cannot be expressed in words should
      have a descriptive label as its text equivalent. The sub-bullet goes
      on to say that the text equivalent should fulfill the same function,
      present all the intended information, and achieve the same function
      as the non-text content. How is this possible if the non-text content
      cannot be expressed in words in the first place.

   Level 2 success criteria

      - this criteria should be moved to Level 3.

   Definition of Non-text content

      - The focus of this checkpoint should be about the content, not the
      method delivered. Applets and "programmatic objects" should be
      removed from the definition of non-text content because they are the
      delivery method and are covered in checkpoint 5.4. If applets or
      programmatic objects "deliver" non-text content such as graphics,
      audio, or video, then that non-text content should have a text
      equivalent - transcripts for audio, captions and descriptions for
      video, etc.  Scripts should also be removed because they deliver
      content. The content delivered is what needs to be part of the
      success criteria no matter how it is delivered.

Checkpoint 1.2

   Level 2 success criteria

      - item #1 should be moved to Level 3

      - Item 3 ends with the phrase "... view only the captions, the
      captions with the audio, or both together." "Both together" is the
      same as "the captions with the audio". It should be: "only the
      captions, only the audio, or both together".

   Benefits

      - The Note ends with a sentence that sounds like a success criteria:
      "Where possible, provide content so that it does not require dual,
      simultaneous attention or so that it gives the user the ability to
      effectively control/pause different media signals."

Checkpoint 1.4

   Minimum success criteria

      - Both items include the phrase "seriously interfere". This is very
      subjective. It sounds like rationale, not success criteria.

      - The requirement at this level should be that the author should
      implement the content using methods that allow the user to turn off
      the background image or turn off background audio.

   Level 2 success criteria

      - there should be no criteria at this level. These should be moved to
      level 3.

      - A simulator for "major types of color blindness" is a testing tool,
      not a success criteria. The guidelines should specify the exact
      criteria to be met similar to the one defined in level 3 for
      background sounds in audio content.. A simulator may exist or may be
      developed that automates the process of evaluating against the
      success criteria but but the tool itself should not be the success
      criteria.

   Level 3 success criteria

      - the criteria at this level should result in a choice of either you
      don't have background images/audio or your images/audio meet criteria
      that are not a problem (pass color blind criteria, background sounds
      at least 20 db lower than foreground content, etc.)

      - for the audio criteria, is there a time consideration here? For
      example, if the background sound is not 20 db lower than the
      foreground content but it only lasts for a second, is that a problem?

Checkpoint 1.5

   We believe the levels of success criteria for this checkpoint should
   fall along the lines of 1 - the content is encoded properly, 2 - the
   language of the page is identified, 3 - you expand on abbreviations,
   acronyms, passages that need more explanation. In this scheme,

   Level 1 is okay

   Level 2 success criteria should be moved to Level 3

   Level 3 success criteria should be moved to Level 2

      However, the real problem with acronyms and abbreviations is how the
      speech synthesizers speak the acronym, not so much how it is
      expanded.  A subcommittee/WG needs to be established to identify the
      various scenarios and apply some logic as to what the author should
      do, what the AT/browser should do, what the synthesizer should do,
      and what the user should do.  For example, the author can expand the
      acronym VoiceXML to "voice extendable markup language", and the user
      can choose to expand to hear the full expansion, but how does the
      user get to hear Voice U.M.L. instead of "voiceuml"?  How the acronym
      is pronounced should be part of aural cascading style sheets, which
      is not well defined in this scenario.

Checkpoint 2.1

   Definitions

      - The Character input definition refers to a character set called the
      W3C Character Model. Are the tab and arrow keys part of this
      character set?

      - Need to link to where this character model is defined.

Checkpoint 2.2

   Minimum success criteria

      - we should not provide success criteria for scenarios that are
      excluded by the checkpoint itself

         - Item 1d concerns time limits that are due to real-time events.
         The checkpoint excludes these types of time limits with the phrase
         "...unless control is not possible due to the nature of real-time
         events"

         - Item 1e concerns time limits that are part of competitive
         activity. The checkpoint excludes these types of time limits with
         the phrase "... unless control is not possible due to the nature
         of  .... competition".

Checkpoint 2.3

   Minimum success criteria

      - Since all success criteria must be testable, and item 1b implies
      that 1a cannot be tested, item 1a should not be included as a success
      criteria.

      - Also, what is the rationale for specifying the range between 3 and
      49? Section 508 specifies a range between 2 and 55. We don't know the
      rationale for that either but do we have specific reasons for making
      WCAG different?

   Level 2 success criteria

      - Items # 1 and # 2 should be moved to Level 3.

Checkpoint 3.1

   Level 2 success criteria

      - probably not possible to determine whether you have done what is
      "possible". May be okay to do what you think is "appropriate". This
      criteria is very subjective, however.

      - this criteria should be moved to Level 3.

   Level 3 success criteria

      - item # 2 on diagram is just repeating the checkpoint. What is the
      criteria that makes a diagram have structure? reading order?

Checkpoint 3.3

   Minimum success criteria

      - Item 1 would be clearer if we said "three or more layers" instead
      of "more than two layers"

Checkpoint 3.4

   Level 2 success criteria

      - this criteria should be moved to Level 3.

Checkpoint 3.5

   Level 2 success criteria

      - this criteria should be moved to Level 3.

   Definitions

      - Under the mechanisms that cause extreme changes in context

         - the first bullet should read simply "opening a new browser
         window". That is the definition of an extreme change in context
         whether it is expected or not. Our guideline is that this change
         should be done in a predictable way so that it is not unexpected.

         - the second bullet should simply read "a change of speaker in an
         auditory presentation". Again, that is the definition of the
         extreme change in context. The guideline is that there should be a
         caption or visual cue so that the user understands it.

   Benefits

      - the user agent knows when it is opening a new window and can inform
      the user. HPR does this. IE can be configured to do it. The author
      should only be required to code it correctly.

      - The "Note" seems like a further elaboration of the first benefit
      bullet. It should be incorporated into that bullet.

   Examples

      - Example 3 is an example of NOT meeting the checkpoint. It should be
      removed or reworked to be an example of meeting the checkpoint.

Checkpoint 3.6

   Graceful recovery should be removed from the checkpoint or defined in
   the definitions section.

   Level 2 success criteria

      - this criteria should be moved to Level 3.

   Level 3 success criteria

      - Item 4b ends with the phrase "in advance". In advance of what?

      - It seems like some of these criteria are error prevention and
      recovery methods that would have to be used in order to claim success
      criteria at Level 2.

Checkpoint 4.1

   Partial list of items being explored

      - In Item 10, find a better example than "haven't seen you in a
      coon's age"

   There is a lot of work going on in the working group attempting to
   define objective criteria for this checkpoint. It seems that the working
   group has been wrestling with this for a long time. Perhaps it is time
   to set a deadline for completing this. If the working group cannot reach
   consensus on objective success criteria by the end of the deadline, this
   checkpoint should be removed or moved to an informative section.

Checkpoint 4.2

   As for Checkpoint 4.1 above, we recommend that the working group set a
   deadline for developing objective success criteria for this checkpoint.
   If the working group cannot reach consensus on objective success
   criteria by the end of the deadline, this checkpoint should be removed
   or moved to an informative section.

   The definition of non-text content does not fit what we mean by non-text
   content in this checkpoint. It makes it sound like we are recommending
   that people supplement text with ASCII art, for example. Do we really
   mean illustrations here? We used that term in the informative note on
   this checkpoint.

   We need more rationale here as to why adding non-text content to text is
   a good idea.

Checkpoint 4.3

   Minimum success criteria

      - Item 1 says acronyms and abbreviations should be defined the first
      time they appear. Does this mean the first time they appear on a page
      or on a site?

Checkpoint 5.1

   Minimum success criteria

      - items #2 and #3 are not needed here. Checkpoint 5.4 covers
      programmatic interfaces.

      - minimum success criteria - what does it mean in item 3 to use
      accessibility features if available? If accessibility features are
      not available, can I use the technology or not?

      - in answer to the question asking if protocols are relavant to this
      checkpoint, yes "protocols" are relevant and should be included.

   Examples

      - In Example 2, "Java program" should be "Java applet"

Checkpoint 5.2

   Minimum success criteria

      - Item 2 needs to be clarified. If I declare that scripts and style
      sheets are part of my baseline, are they above it or below it?
      Perhaps this can be clarified by expanding the example.

      - the term "technology" needs to be defined along with adding and
      defining "platform"

      - does the baseline include platform, language? i.e. what are the
      user agent requirements that need to be documented? could be useful
      in documenting the "configuration" that is accessible

      - the success criteria really have nothing to do with designing for
      backward compatibility

         - Level 1 is "declaring" your configuration.

         - Level 2 is testing your baseline.

         - Level 3 is that it works in a text only browser.

Checkpoint 5.3

   This is an important consideration but should not be a checkpoint. If
   you meet all the checkpoints, then you have obviously done this. If you
   haven't, then what difference does this make?

Checkpoint 5.4

   This checkpoint is about making the user interface operable and would be
   better organized as part of guideline 2.



Glossary

      1. The "Glossary of terms" should not be part of the recommendation,
but kept in a separate doc such as the techniques.  The "common WAI
glossary" just needs to include the definitions that the WG proposes.  The
process is key here, that the terms be considered as part of the WCAG
recommendation up to the "proposed recommendation" step, where the terms
and definitions are "removed" from the recommendation and "ensured" are
part of the common glossary for all WAI documents.



Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Tuesday, 29 October 2002 18:39:59 GMT

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