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

Comments from Tim Berners-Lee about Web Content Guidelines

From: Ian Jacobs <ij@w3.org>
Date: Sun, 14 Mar 1999 18:44:37 -0500
Message-ID: <36EC49E5.BA82643D@w3.org>
To: w3c-wai-gl@w3.org
CC: timbl@w3.org
Hello,

This is a summary of a discussion with Tim Berners-Lee and 
Judy Brewer about the Web Content Accessibility Guidelines [1]. 
The notes are followed by suggested actions for the editors
and chairs. Where the WG reached consensus on chair actions
in the 11 March teleconf [2], the resolution is indicated.

[1] http://www.w3.org/TR/1999/WD-WAI-PAGEAUTH-19990226 
[2] http://www.w3.org/WAI/GL/meetings/19990311.html#actions


----

-  Ensure that the Guidelines document is entirely independent
   of the Techniques document. In order for the Guidelines
   to become a Recommendation, it must not rely on the Techniques
   for definitions or clarification of meaning. The Techniques
   Doc should be used for language-specific examples and 
   elaborations, but all meanings should be clear with the
   Guidelines alone. Thus, for example, the definitions of
   equivalent text and descriptions belong in the Guidelines
   document. Their implementation in HTML belongs in the Techniques
   document.

   Action Editors: review document for independence from
                   Techniques Doc.

   Action Editors: Move definitions from 2.1 of Techniques
                   to Guidelines.

   Action Editors: Ensure that the term "text equivalent" is
                   used consistently in the Guidelines.

   Action Editors: Ensure that the examples in the Techniques document
                   (and Guidelines examples sections) use
                   the proper conventions (i.e., are consistent
                   with accepted use and the guidelines).

- Ensure that the line between author responsibility and
  user agent responsibility is clearly drawn. This is done
  to a certain extent with checkpoints of the form "Until 
  user agents do such and such". However, the division needs
  to be made clear in other checkpoints as well. For example,
  Checkpoint 9.4 talks about freezing motion. This should be
  done by the user agent (allowing the user to turn off 
  certain types of movement).

  Action Editors: Read checkpoints and where the burden
                  in the long run falls on user agents,
                  clarify that the author burden is a
                  short-term solution.

- Ensure that the checkpoints do not force authors to sacrifice
  features useful to many. 
  Ensure that the checkpoints say clearly, "If you do this thing,
  do it accessibly". We do this for frames, for example - we don't
  say "Don't use frames!" we explain how to use them accessibly.
  Ensure that we make this clear in the checkpoint wording.

  Thus, for 12.1, the checkpoint should be
  more clearly understood as: "Separate windows may be useful
  to some people but when a window will be opened, be sure the user
  is notified." In short, ensure the checkpoint clearly
  states that the accessibility issue in question revolves
  around sudden changes, not separate windows. Also, this one seems
  like the burden falls primarily on UA developers, not authors.
  (Thus, "Until UAs....").

  Action Editors: Review checkpoints with this in mind.

-  There are (more or less) four classes of links in the document:
   a) Links to the techniques document
   b) Links to the glossary (e.g., for "best efforts", "important",
etc.)
   c) Cross references within the Guidelines document
   d) Links to the references section.

   Each type of link should be identifiable to the reader.

   Action Editors: Find a mechanism for identifying link "classes"
         so the user can distinguish. Also ensure consistent usage
         throughout the document. Also, describe more clearly in
         the introduction the conventions for how checkpoints
         are linked between the Guidelines and the Techniques.
         [Also: Ensure that it's clear that the List of Checkpoints
          is part of the Guidelines and thus the Recommendation.]

   Furthermore, the links in the checkpoints are "not conventional"
   in that the link text is a verb phrase rather than a noun that
   is the target of the link. Should this be changed? 

-  The "title" attribute in HTML is meant for advisory
   titles (e.g., on a link, to describe the target). It should
   not be assigned the exclusive role of providing a description
   of an image, script, etc.

   Action Chairs: Raise this issue with the WG.

   RESOLVED Item 7: The Guidelines will not discuss 
                   "brief descriptions" as a separate topic.
                   The editors will review the use of the
                   "title" attribute.

   Action Editors: The example with title="Hello!" in the 
                 techniques document should be reviewed.


-  STRONG and BOLD presentation is overused in the rationales. 
   Please reduce. Ensure consistent structure for each guideline (e.g.,
   heading, subheading, rationale, checkpoints) and consistent
   and simple presentation for each.

   Action Editors: Reduce bold markup. Ensure consistent usage
                   throughout the guidelines. In particular,
                   the sentence before the checkpoints in Guideline
                   9 needs lots of work.

 - There should be a way in the Techniques document to find out
   where a given checkpoint is discussed. Thus, if checkpoint
   15.9 is discussed in section 1.9 of the Techniques document,
   the user should be able to find that out quickly. 

   Action Editors: Find a mechanism for doing this (preferably
                   automagically!)

 - Ensure proper use of the term "content". Content includes
   markup (thus, fix section A first bullet.) Distinguish
   (logical) structure from presentation.

----------------------
Guidelines/Checkpoints
----------------------

- Guideline 1
  - The example in the rationale about the company logo's function
    needs to be revisited. The text equivalent 
    provides different information than the image conveys visually.

  Action Editors: Review the example.
       
  - Checkpoints 1.1 and 1.2: Don't use "title" for textual equivalent.
    Use the OBJECT's content only.

  Action Chairs: Raise this issue with the WG.

  RESOLVED Item 7: Remove "title" for alt text for the OBJECT element.

- Guideline 7  
  - Checkpoint 7.1. Don't encourage people to use dumb screen
                    readers. In particular, trying to ensure
                    that text doesn't wrap may lead people
                    to use something other than a table
                    when a table is the appropriate structure.
                    Thus, may do more harm than good to
                    independent screen readers. If you 
                    really want to control word wrap, use PRE!

  Action Chairs: Raise this issue with the WG.

  This was discussed at the teleconf (Item 8), but no clear
  resolution about what to do about checkpoint 12.5.

- Guideline 9

  - Checkpoints 9.1 and 9.2. Rewrite to be more clearly
      responsibility of UAs in the long run. See general 
      comment above about ensuring a clear division 
      between author and developer responsibility.

   Action Editors: Review wording.


- Guideline 11

  Action Editors: Need to make the rationale section clearer.

- Guideline 12

  - Checkpoint 12.1. See general comment above about ensuring
                     a clear division between author and developer
                     responsibility.

   Action Editors: Review wording.

- Guideline 13

  - Checkpoints 13.3 and 13.4 are incompatible.
    We should be promoting content negotiation, not the use
    of "type". Thus, authors should not have separate
    links with link text such as "For the English version,
    click here." It should be done at the server level.
    [Note: We reviewed the "Available Formats" section of
     the document, where it is ok to list different formats
     explicitly.]

    Proposal: Delete 13.3 or at least subsume it in 13.4. 
   
    Action Chairs: Raise this issue with the Working Group.

    RESOLVED (Item 9): Merge into one checkpoint. Proposed text:
       Priority: 3
       Text:     Provide information so that users may 
                 receive documents according to their
                 preferences (e.g., language, content type, etc.)
       Comment:  Use content negotiation where possible. 
              
  - In the Note after the checkpoints, rewrite such that
    it reads more like "there is a danger of this happening".

    Action Editors: Review wording.

- Guideline 15

  - Discuss link relationships more explicitly (e.g., as a
    checkpoint). Link relationships (rel/rev attribs in HTML)
    are used already by some UAs to provide navigation tools.
    This may be discussed in relation to RDF.

    Action Chairs: Raise this with the Working Group.

    RESOLVED: Will discuss in techniques document.


  - Checkpoint 15.2: Add that metadata should be used to convey
    information about navigation structure as well.

    Action Editors: Add this.

  - Checkpoint 15.9: The example after the checkpoint is too
      low-level for the Guidelines. Why is the checkpoint
      as a whole important for accessibility? 

    Action Editors: Make the accessibility issue clearer either
      in the checkpoint and/or Guideline 15 rationale.
Received on Sunday, 14 March 1999 18:43:27 GMT

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