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

New guidelines draft

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Thu, 13 Jul 2000 10:05:45 +1000 (EST)
To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.SOL.4.10.10007130950590.9172-100000@ariel.ucs.unimelb.edu.au>
Over the weekend I wrote a draft reformulation of the Web Content
Accessibility Guidelines which attempts to address many of the issues
that have been considered by the working group since the publication of
WCAG 1.0 as a W3C Recommendation. It should be emphasized that this draft
builds upon, and generalizes, the requirements set forth in WCAG 1.0. It
is being provided as the starting point for discussion, and has not been
endorsed as an official working group draft. The responsibility,
accordingly, for any errors or omissions is entirely mine.

A text version of the draft is included below. The full HTML version is
expected to be made available via the working group's web site shortly.

As a final note, this is an outline only, and as a consequence many
important explanations, qualifications and examples have not been
included.

Please review and comment.

Draft text follows:



          Draft Reformulation of Web Content Accessibility Guidelines
                                       
Introduction

   The following new terminology is proposed in this draft:
   
   1: Principles
          These are the highest, most abstract general maxims 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
          to any particular, existing standard, specification or
          implementation. Guidelines in this sense sometimes correspond
          to "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.
          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
  
    Guidelines
    
    1. Provide a textual equivalent for every non-text (auditory or
       graphical) component of a web page or multimedia presentation.
    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.
    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.
       
  Principle 2: Separate content and structure from presentation, and ensure
  that significant structural or semantic distinctions are captured in explicit
  markup.
  
    Guidelines
    
    1. Use markup languages properly and in accordance with
       specification.
    2. Use style languages, where available, to control layout and
       presentation.
    3. Where presentation is used to communicate distinctions of meaning
       or structure within the content, ensure, if possible, that
       semantic markup is also provided which conveys these distinctions
       equivalently. Note that the semantic and presentational markup
       corresponding to a document need not reside in the same file or
       logical resource; these guidelines mandate only that both must
       exist and be available to the user agent.
    4. Do not rely on presentation alone (E.G. colour or font changes) to
       express semantic distinctions (this is a corollary of the
       preceding guideline).
    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.
       
  Principle 3: Provide default presentations, while facilitating the
  application of user-specified presentations
  
    Guidelines
    
    1. Specify one or more default presentations of the content, for
       example with style sheets, or by supplying pre-formatted versions
       which can be selected via content negotiation or explicit user
       requests. Where practicable, offer a variety of alternative
       presentations suited to different output devices. For example,
       provide style sheets relevant to high and low-resolution displays,
       printers and speech output systems.
    2. To facilitate the application of user-supplied transformations and
       style rules, ensure that documents validate to the formal grammars
       of markup languages which are defined in published specifications,
       and which support the application of these guidelines.
    3. When using style languages which support a "cascade" of authors'
       and users' preferences, ensure that style sheets are designed in
       such a way as to operate gracefully if partially overridden by the
       user agent. For example, specify lengths in relative rather than
       absolute units of measure.
       
  Principle 4: Design for ease of comprehension, browsing and navigation
  
    Guidelines
    
    1. Use a consistent style of presentation in which the structural and
       semantic distinctions expressed in the markup, are associated with
       appropriate formatting conventions that enhance the readability
       and intelligibility of the content.
    2. Provide clear and consistent navigation mechanisms throughout a
       web site.
    3. Supply an overview of the general organization of a site or of a
       document which has been split into multiple, independent resources
       (E.G. in a map or table of contents).
    4. Divide large blocks of information into more manageable groups
       where natural and appropriate.
    5. If search functions are provided, enable different types of
       searches for different skill levels and preferences.
    6. Place distinguishing information at the beginning of headings,
       paragraphs, lists, etc.
    7. Use the clearest and simplest language appropriate for a site's
       content.
    8. Supplement text with graphic or auditory presentations where they
       will facilitate comprehension of the content.
    9. Use headings, labels and titles appropriately 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 materials,
       such as tables.
   11. Define key terms, and provide expansions for abbreviations and
       acronyms, which should be identified using appropriate markup.
       
  Principle 5: Design user interfaces for device independence
  
    Guidelines
    
   These need to be reworked to take account of the separation between
   user interface logic and presentation which is provided by X-Forms.
    1. Associate an explicit label with each user interface control.
    2. Ensure that user interface controls are grouped logically.
    3. Ensure that event handlers are device-independent.
    4. Design user interfaces to be compatible with assistive
       technologies.
       
  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.
    2. Avoid causing content to blink or flicker.
    3. Avoid causing pages to be refreshed or updated automatically.
       
   Any other interim measures which are considered to be of vital
   importance may be included here.
   
  Checkpoints without an obvious place in this scheme
  
   Checkpoint 2.2 from WCAG 1.0 doesn't seem to fit:
   
     2.2 Ensure that foreground and background color combinations
     provide sufficient contrast when viewed by someone having color
     deficits or when viewed on a black and white screen.
     
   Most other checkpoints can be subsumed under the HTML/CSS
   technology-specific checklists, or have been incorporated within the
   generalized guidelines as presented above.
   
                                   Comments
                                       
   Draft prepared by [1]Jason White.
   
   Please direct comments to the working group mailing list at
   [2]w3c-wai-gl@w3.org.

References

   1. mailto:jasonw@ariel.ucs.unimelb.edu.au
   2. mailto:w3c-wai-gl@w3.org
Received on Wednesday, 12 July 2000 20:07:09 GMT

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