W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 1999

Minutes of 22 March WAI GL teleconference.

From: Ian Jacobs <ij@w3.org>
Date: Mon, 22 Mar 1999 21:59:44 -0500
Message-ID: <36F703A0.A5E3CEAA@w3.org>
To: w3c-wai-gl@w3.org
Attendance:

Ian Jacobs (Chair, scribe)
Eric Hansen
Daniel Dardailler
Jason White
Charles McCathieNevile
Gregg Vanderheiden
Judy Brewer

Regrets: 
 Chuck Letourneau
 Wendy Chisholm
 
Agenda [0].
[0] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0469.html

Reference document [1]
[1] http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19990316


A) RESOLVED: To clearly indicate the division between author
responsibility
          and user agent responsibility:

   a) All checkpoints involving interim responsibility from
      authors will contain the wording "Until user agents ..."
      These checkpoints are: all of guideline 9, all of guideline 12,
      checkpoint 15.4 (group related links), and 1.7 
      (Provide redundant text links for each active region of an 
       image map.)

   b) For each checkpoint, include the "until" wording since
      checkpoints may be read on their own. It is not sufficient
      to say it in the guideline rationale.
 
   c) Include an explanation of what "Until user agents..." means
      in the glossary section.

   Proposed text:

   <BLOCKQUOTE>
    In some of the checkpoints below, content developers are
    clearly the best candidates for ensuring accessibility.
    However, there are times when user agents would be the better
    choice. Unfortunately, not all user agents or assistive
    technologies provide the accessibility control users require
    (e.g., some user agents may not allow users to turn off blinking
    content, or some screen readers may not handle tables well). 

    To address cases where the responsibility for providing
    accessible control lies with the user agent or assistive
    technology but that control is not yet easily available, certain
    checkpoints contain the phrase "until user agents ...". When
    content developers see this phrase, they should recognize that
    they are being asked to provide additional support for
    accessibility until most user agents meet users' needs. 

    For each checkpoint with this phrase, content developers must
    consider: 
        1.What is their anticipated audience? For example,
          designing for a company intranet where everyone uses
          the same browser is different than designing for the
          World Wide Web. 
        2.Do those users have tools available that satisfy the
          demands of the checkpoint? 

    If the answer to the second question is yes, content developers
    are not required to satisfy the checkpoint. 

    How will content developers know when most user agents or
    assistive technologies meet specific needs? The W3C WAI will
    make this information available from its Web site (either directly
    or by providing links to the information). Content developers
    are encouraged to consult this information regularly for updates
    on accessibility support. 
   </BLOCKQUOTE>

   ACTION WG: Review this proposal.


B) RESOLVED:
  Divide checkpoint 9.2 into two checkpoints:

     a) Priority 1:  Until user agents allow users to 
                     control it, avoid causing the screen to 
                     flicker. [Add note about epilepsy here.]

     b) Priority 2: Until user agents allow users to control it, 
                    avoid causing content to blink (i.e.,
                    change presentation at a regular rate, 
                    such as turning on and off).

C) RESOLVED:
 Proposed change in wording of Note in guideline 12.

         The following checkpoints apply until 
         user agents and assistive technologies address
         these issues.

D) RESOLVED:
   Do references designated the latest versions
   of documents or dated versions?

   Proposed:
     a) Add a link from checkpoint 13.1 (Use the latest W3C specs)
        to the references section.
     b) In the references section, add a statement about
        where to find the current versions of W3C specs.
     c) The list of references will contain dated versions so
        that readers will know what existed when the guidelines
        were created.
     d) To each entry in the list, add a link to the latest
        version.

   ACTION IAN: Inform Misha, who raised this issue in [2]

 [2]
http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0333.html

E) RESOLVED: 

   It's to say in guideline 1 that when text equivalent
   is long, use description.

   /* Note: This resolution is subsumed by a later one */

F) RESOLVED: 

   In 6.3, add to checkpoint the following text:
   "including text equivalents (e.g., captions)"

G) RESOLVED:
   All checkpoints in guideline 9 priority 2
   except for the one about flicker.

H) RESOLVED: Changes for guideline 15.

   a) Move note about LINK relationships from 15.3 to 15.2
   b) Move 15.10 to after 15.3.
   c) Change priority level of 15.6 to 2.
   d) Merge 15.4 and 15.5 into a priority 2 checkpoint.
      Proposed wording:  
           Provide information about the general layout 
           of a site (e.g., a site map, or table of contents). 
   e) For 15.9:
      i) Proposed wording: 
           Provide information about document collections
           (i.e., documents comprising multiple pages.).
     ii) Make this an "until user agents" checkpoint.
    iii) Techniques: LINK relationships, archives.
    iv) Add more rationale (e.g., performance or cost
         requires offline browsing)

I) RESOLVED:
   In the Abstract, make clear that this is a reference document
   and that for more practical information, 
   readers should consult the WAI Web site.

J) RESOLVED: 
    Add a definition of "assistive technology" to the glossary.

K) RESOLVED:
    Add a section about document conventions, including:

   a) Element names are uppercase.
   b) Attribute names are quoted lowercase.
   c) Linking conventions (to techniques document, to references,
      to glossary, etc.)

L) RESOLVED:
   All discussion of browser support for elements and attributes
   is outside the scope of this document. State this in 
   the front matter.

M) RESOLVED:
   Do not discuss accessibility v. usability in the document.

--
The following resolutions refer to the issues list [3] and
the numbers given here are those in the open issues list.


[3] http://www.w3.org/WAI/GL/wai-gl-issues.html

19) The Specifics of Conformance Claims
    See proposal [4] from Judy and comments.

[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0483.html

20) Priority of checkpoints related to color 
    RESOLVED: For checkpoint 4.2, 
              [Priority 2 for images, Priority 3 for text].

21) Marking up lists 
    RESOLVED: Priority 2. This is not an editorial
    issue (i.e., it's not about choosing to use lists).

22) BLOCKQUOTE for indentation 
    RESOLVED: Priority 2, notably since style sheets
    can address this. Also, the way braille works
    (according to Jason), blockquotes and inline are
    treated identically. 

23) Use of "title"
   RESOLVED:
   a) Say to use "title" according to HTML 4.0 spec.
   b) Don't say anything about using "title" for images
      that are not in links.

24) Priority of "Use latest W3C technologies" (Checkpoint 13.1) 
   RESOLVED 
      a) Wording: Use W3C technologies and use the latest
                  versions when they are supported.   
      b) Link to the discussion of "until user agents"

25) Priority of "Avoid deprecated features" (Checkpoint 13.2) 
   RESOLVED Wording: Avoid deprecated features of W3C technologies. 

26) Priority of "Divide long lists into groups" (Checkpoint 14.5) 
   RESOLVED: Create a single Priority 2
             checkpoint for managing groups of information.
   Wording: Divide large blocks of information into more 
            manageable groups where natural and appropriate.

27) Who's responsible - author or user agent?
   See point "A" above.

28) Clarity of natural language guideline (Guideline 6) 
   RESOLVED: Addressed with new guideline wording: 
     Clarify natural language usage.

29) URIs for references 
   See point "D" above.

30) LINK types. 
   See point "H" above.

31) Off-line reading techniques
   See point "H" above.

32) Additional natural language issues?
   See point "F" above.

33) Section numbering
   RESOLVED in 16 March draft.

34) Consistent use of double priority
   Proposal dropped

35) Statement of audience
    RESOLVED: Don't add any statements in abstract about 
              intended readership.
    PROPOSED: Add reference to policy makers to conformance
              statement.

36) Information about assistive technologies
    RESOLVED: 
     Create a W3C NOTE for this information rather
        than including it in the guidelines other than
        minimally. The glossary does contain some
        short definitions. 

37) Clarity of link destination
    RESOLVED:
     a) Many links cleared up in 16 March draft
     b) Will add section on conventions.

38) Support for new elements and attributes

   RESOLVED: All proposals are out of scope, covered already, 
             or will be dealt with at WAI Web site.
             Support for "longdesc" doesn't belong here; UA 
             guidelines probably.

39) Interim support for table header info 
   RESOLVED: No change. (Lean to the future, use correct markup)

40)  Proposal that background/foreground be specified 
     together to ensure contrast 

   RESOLVED: No additional checkpoint. This is a technique.

41) Proposal to restructure first three guidelines 

/* 
   NOTE: At this point in the teleconference, the only participants
   were Charles McCathieNevile, Jason White, Eric Hansen, and
   Ian Jacobs. Judy was present, but working on the conformance
   proposal. 
*/

RESOLVED:

   - Change priority of 3.4 to Priority 1:
    (Provide a text version of the auditory
    description and collate it with the text 
    transcript (captions) of the primary audio track.)

The last part of the teleconference call involved an
in-depth study of the first three guidelines, their purpose,
and their checkpoints. The following is a proposal to restructure
these guidelines.

RATIONALE: 
  i) The first three guidelines not organized clearly. 
 ii) There are several axes to consider here, including: 
      1. The format of the "primary" information: audio or visual 
      2. The format of the alternative information: text, audio, or
video. 
      3. The purpose of the alternative information: 
         text equivalent (function) or description (appearance) 
iii) The distinction between "equivalent" and "description" is
      not always clear. Equivalent information often contains
      a descriptive component.

 iv) The distinction between "alt" text and "longdesc" text is
     an artifact of a choice made by the HTML 4.0 designers. 
     That the OBJECT element allows rich text equivalents indicates
     that the "long versus short" argument is an implementation
     detail.

REQUIREMENTS:
  i) The most important concept to convey in the 
     revised guidelines structure is that authors
     must provide information that will be equivalent when
     rendered.
 ii) Text is king (and thus all text equivalent information should
     be Priority 1).
iii) Audio or video representations of information are secondary
     (and Priority 2).
iv) All the visual information checkpoints may be combined into
     one except where qualifications require separation.

PROPOSED:
  i) Move checkpoint 1.5 to Guideline 11 (device-independence)
     (Checkpoint 1.5 is: Provide client-side image maps 
     instead of server-side image maps except
     where the regions cannot be defined with 
     an available geometric shape.)

 ii) Move checkpoint 1.8 to Guideline 5 (Use markup and style
     sheets appropriately).
     (Checkpoint 1.8 is: Provide individual button controls 
      in a form rather than simulating a set of buttons with an 
      image map.

iii) Proposed: For the part of checkpoint 1.6
     involving a link to skip over ascii art, move
     to guideline 15 as a priority 2 checkpoint.

 iv) Proposed: For the part of checkpoint 1.6     
     involving using an image instead of ascii art, 
     create a new checkpoint (priority 2) in guideline 5 about
     using images rather than text to provide visual
     information. Ensure cross references to other
     ascii-art guidelines.

 v) Reduce guidelines 1, 2, and 3 to one Guideline, 
      to read: Provide equivalent information for
               visual and auditory information.

      The rationale will have to be rewritten based on the
      rationales from the three guidelines. The main points
      to emphasize are that:

      a) The goal is to provide information that may 
         be used to create an equivalent browsing experience.
      b) Function is vital, description may be part of 
         function. Thus, there will no longer be a separate
         topic of "description" - this will be included in 
         the definition of "equivalent". The implementation
         details of which attributes to use and when will
         be in the techniques document.
      c) Text is king, audio and video equivalents are
         useful but text can be rendered as speech, 
         graphically, or by a braille device.
      d) Synchronization is important when equivalents
         are interwoven over time.
      e) ASCII art has to be carefully defined (e.g., to
         not include a smiley, which, in certain circles,
         is just a accessible as an abbreviation, and in
         other circles, just as obscure. This is 
         arguably different than using characters 
         to create an image.

  vi) Proposed checkpoints. Each checkpoint will start with 
     its new number followed by a slash and its old number.
     The end of the checkpoint will list the old checkpoint
     number(s).

     1.1  Provide a text equivalent for every
          non-text object. Priority 1. Was checkpoints 1.1,
          1.2, 1.3, 1.4,  2.1, 3.1, 3.3, and 3.4. This includes:
          images, graphical representations of text,
          image map regions, animations (e.g., animated
          GIFs), applets, ascii art, scripts, inserted
          list bullets, sounds, synthesized speech, audio
          tracks of video, and video.

          NOTE: Include a cross-ref here to
          the (proposed) checkpoint in guideline 15 about
          skipping over ascii art. This includes images
          as bullets.

          QUESTION: From "Provide a text equivalent for every
                sound played automatically," 
                What does "automatically" mean?
     
     1.2 Provide redundant text links for each active region of an
         image map. [Priority 1 - if server-side image maps are used,
         Priority 2 - if client-side image maps are used. 
         Content developers will not need to provide redundant text
         links for client-side image maps once most user agents render
         text equivalents for the map links.] Was checkpoint 1.7.

     1.3 Ensure that audio information played simultaneously
         remains comprehensible. Priority 1. Was checkpoint 3.2. 
         Example: Weave audio tracks and audio descriptions
         so they overlap comprehensibly.

     1.4 Synchronize equivalents that evolve together
         over time. Priority 1. Examples:
           a) Subtitles and video must be synchronized.
           b) Collate text equivalents of audio tracks
              and audio equivalents.

     1.5 Provide non-text equivalents where they 
         facilitate comprehension of the page. Priority 2.
         Example: video representation of an applet,
         icon representation of text, audio description
         of video, recorded spoken text, etc.
         Was checkpoint 2.2, 8.5, 16.2
Received on Monday, 22 March 1999 22:00:52 GMT

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