W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

RE: New guidelines draft

From: Tim Noonan <tnoonan@softspeak.com.au>
Date: Thu, 13 Jul 2000 22:51:44 +1000
To: <w3c-wai-gl@w3.org>
Cc: "Jason White" <jasonw@ariel.ucs.unimelb.EDU.AU>
Message-ID: <LOBBLDNHMBHIEEPNKJKFGEEGDMAA.tnoonan@softspeak.com.au>
This is an annotated version of Jason's re-drafting of the WCAG guidelines.
My comments are within square brackets.  I've deleted paragraphs which I
have not commented on.

My notes mostly relate to the language, terminology and word of items,
rather than the recommendations they imply.

I have attempted to read this document as if I were a relative new-comer to
the area, looking for things that would make me confused, or where words
might make me wonder "what does that mean" thus distracting me from the
important principles the document presents.

I am very excited about this kind of structure and approach to the new
document, as I think it addresses many of the concerns I so frequently
encounter and try to defend about the readability of the current guidelines.
In a word, the document is "clear" but isn't waffly.

I also like the increased hierarchical structure which can lead to both a
brief and a detailed view of the document, something we all agreed was vital
at the face-to-face meeting in March.

this more hierarchical structure coupled with plainer less jargonistic
language will, I believe, make understanding the principles of accessible
web design magnitudes clearer for new-comers to the area.

The table of contents will- at a glance - give people a sense  of what we
are on about.

Thanks Jason for offering such a mature document as a starting draft.

Some of these notes may seem pedantic and picky, but in some public
documents I think that we need to keep Consortium-specific terms to a
minimum if there are other clearer and more accessible alternatives.]

   1: Principles
          These are the highest, most abstract general maxims [can we find
another word?] of
          accessible design, from which the concrete requirements are
          derived. In effect, they serve as subject headings under which
          the guidelines are categorized. They correspond to what were
          called "guidelines" in WCAG 1.0.

   2: Guidelines.
          These requirements are more specific and detailed than the
          general principles; however, they are not specific to any
          particular technology. Some of the requirements may be
          applicable only to a certain range of protocols or data
          representations (E.G. multimedia formats), but they are not
          restricted to the features or capabilities that may appertain [can
we find another word]         to any particular, existing standard,
specification or
          implementation. Guidelines in this sense sometimes correspond
          to [what were termed ] "checkpoints" in WCAG 1.0, but only in
those instances where
          the latter are expressed in general (rather than
          technology-specific) terms.

   3: Checkpoints [not shown in this draft].
          These are the technology-specific requirements, suitable for
          implementation by a content designer or authoring tool, which
          have been derived by applying the guidelines to a specific
          technology, whether it be a communication protocol, software
          interface, or a combination of markup and/or style languages.
[Should we add: checkpoints may also be one basis for automated review of a
webpage by validation tools.]
software           Checkpoints are non-normative, in that there may exist
other,
          equally effective means of satisfying the requirements
          specified in the guidelines. However, proper application of the
          checkpoints is deemed to constitute a correct and adequate
          implementation of the guidelines. Stated differently, the
          checkpoints operate as sufficient, but not as necessary
          conditions for determining whether the guidelines have been
          followed.

Principles and Guidelines

  Principle 1: Provide alternatives to auditory and visual presentations
  [if this wording, rather than Gregg's is adopted, then maybe change word
"presentations" to "information"]

    2. Until user agents can automatically read aloud the text equivalent
       of a visual track, provide an auditory description of the
       important information of the visual track of a multimedia
       presentation. [I think this needs to be much clear, and multimedia
presentation needs to be closer up-front for this point, so the reader knows
the context of the guideline.]

    3. For any time-based multimedia presentation (e.g., a movie or
       animation), synchronize equivalent alternatives (e.g., captions or
       auditory descriptions of the visual track) with the presentation.
[should we talk about "textual captions" or "text captions" instead of just
captions. Reasoning is that multimedia is across mediums (media) and its
easier to focus on which medium is being focused on here.]

  Principle 2: Separate [both] content and structure from presentation, and
ensure
  that significant structural or semantic distinctions are captured in
explicit
  markup.
[we use the word semantic a lot in WAI materials, could we define it
somewhere, or even in the introduction.  Although people with a linguistic
or programming background understand the term, we don't want to lose readers
in the first instance.]

    1. Use markup languages properly and in accordance with
       specification.
[some people will interpret this guideline as stating the obvious, could we
sharpen it a bit or imply why its important?]
    2. Use style languages, where available, to control layout and
       presentation.
[should we say such as cascading style sheets in html?]
    5. Ensure that distinctions which are necessary or beneficial to the
       rendering of the content in different media (E.G. auditory or
       tactile) are reflected in the markup. For instance, use markup to
       identify changes in the natural language of a document, or to
       distinguish fragments of mathematical notation or computer program
       code from the surrounding text.
[can we give an example of a change in natural language?]

  Principle 3: Provide default presentations, while facilitating the
  application of user-specified presentations
[the word application is somewhat ambiguous in this point.  Are we saying
"the use of"? I'm not fully clear on what this principle is trying to get
at.]

    Guidelines

    6. Place distinguishing information at the beginning of headings,
       paragraphs, lists, etc.
[such as numbering items etc?  or does this mean something else?]
    7. Use the clearest and simplest language appropriate for a site's
       content [and being mindful of its audience].
    8. Supplement text with graphic or auditory presentations where they
[this]
       will facilitate comprehension of the content.
    9. Use headings, labels and titles appropriately [and consistently] to
identify
       structurally significant divisions within the content. Note that
       in addition to full, descriptive labels, it may also be
       appropriate, in designing complex structures such as tables and
       forms, to provide abbreviated labels which can be used when the
       content is rendered on small displays or via speech output.
   10. Provide an overview or summary of highly structured [or
two-dimensional] materials,
       such as tables.

  Principle 6: Compensate for older technologies and missing or incompletely
  implemented features of user agents

    Guidelines

    1. Make sure that web sites which use newer technologies transform
       gracefully. [I think the term "transform gracefully" is meaningful to
some, but we need to be clearer about what it means to less technical
readers.]
Received on Thursday, 13 July 2000 08:53:20 GMT

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