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

Revised text of guidelines in response to action item

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Sat, 9 Sep 2000 11:50:16 +1100 (EST)
To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.SOL.4.10.10009091135540.23710-100000@ariel.ucs.unimelb.edu.au>
Several weeks ago, I accepted an action item which involved an undertaking
to rewrite the guidelines (not including the technology-specific checks)
to clarify the concepts and reflect some of the recent discussions which
have taken place within the working group. The results of this effort are
included below. It should be emphasized that what follows is not an
"official" working group draft. All members of the group are, therefore
welcome to propose alternatives, At this stage, I have not incorporated
William's proposed introduction, pending further discussion. Wendy's list
of characteristics of accessible web content could also be integrated into
an introductory overview.

Draft text, for your consideration, follows:


          Draft Reformulation of Web Content Accessibility Guidelines
                                       
   
Introduction

   This draft is intended for internal discussion by the working group.
   Consequently, all introductory and explanatory material, together with
   the technology-specific checks, have been omitted. For the sake of
   consistency with recent working group drafts, the terms principle and
   guideline have been retained, notwithstanding the proposal advanced by
   several members of the group that the words guideline and checkpoint
   respectively, be substituted. This decision should not be regarded as
   an endorsement of the present terminology.
   
Principles and Guidelines

  Principle 1: Design content which can be presented visually, auditorily
or tactually,
  according to the needs and preferences of the user.
  
    Guidelines
    
   1.1 Ensure, by providing textual equivalents to auditory and graphical
          presentations as necessary, that every component of a document,
          web page or multimedia presentation can be rendered as text in
          a standard character set.
          Note: a textual equivalent can take a variety of forms. It is
          intended to fulfill the same function, and serve the same
          purpose as the auditory or visual presentation to which it
          provides an alternative. Thus, in writing a textual equivalent,
          it may be appropriate, in some contexts, to provide a short
          label or descriptive phrase that can be substituted for the
          auditory or graphical material. In other circumstances,
          however, a longer explanation, description or exposition may be
          required. A textual equivalentmay consist of structured content
          or metadata, if appropriate.
          
   1.2 For any time-based multimedia presentation (e.g., a movie or
          animation), synchronize the textual equivalents (e.g., captions
          of the audio track or descriptions of the video track) with the
          presentation.
          This guideline applies to multimedia presentations which have
          auditory and visual components. Where one component (either the
          audio or video track) contains no significant information, a
          synchronized caption or description need not be provided,
          though a textual equivalent, for example a description which
          can be retrieved by the user in place of the multimedia
          presentation, is still required (see guideline 1.1).
          
  Principle 2: Separate content and structure from presentation, and ensure
  that significant structural or semantic distinctions are captured explicitly
  in markup, or in a data model.
  
    Guidelines
    
   2.1 Use markup languages properly and in accordance with
          specification.
          This guideline requires not only that document instances comply
          with any formal grammar or other test of validity provided for
          in the relevant markup language specification, but also that
          structural elements, attributes etc., be used to convey the
          meanings which have been assigned to them in the secification.
          
   2.3 Use style languages, where available, to control layout and
          presentation. Where practicable, provide (or link to) multiple
          style sheets, each supporting a different output device.
          Style languages permit a high degree of separation to be
          maintained between content and presentation, by allowing the
          rules which control the rendering of the content to be
          separated from the markup codes that denote its structural
          features. Typically, style rules are stored separately from the
          content to which they apply, in resources which are referred to
          in these guidelines as style sheets. To facilitate the
          presentation of web content by a range of devices (high and
          low-resolution displays, printers, speech devices, etc.), it is
          advisable to associate a variety of style sheets with your
          documents.
          
   2.3 Where presentation is used to communicate distinctions of meaning
          or structure within the content, ensure, if possible, that
          these distinctions are captured in equivalent data or markup
          which can be obtained and accessed by a user agent.
          It should be noted that, in accordance with the above
          requirement, the structural markup or metadata, and the
          presentation, respectively, need not reside in the same file or
          logical resource. Thus, purely presentational versions of the
          content (e.g., in a graphical format or a page description
          language) may be provided, so long as there exists a version
          which can be retrieved by user agents and contains markup which
          preserves the same structural and semantic distinctions that
          are implicit in the "presentational" version. In such
          circumstances, techniques of content negotiation may be used to
          select the version which best meets the user's requirements.
          
   2.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. It should not
          be interpreted as discouraging the use of colour or other style
          properties to enhance the presentation of content. It can be
          satisfied by ensuring that the distinctions conveyed by the
          presentation are also reflected in the markup.
          
   2.5 Ensure that the logical structure of the content is preserved in
          the markup or data model, together with any additional semantic
          distinctions that facilitate rendering of the content in the
          visual, auditory and tactile modalities.
          The logical structure of the content needs to be explicitly
          preserved for two purposes. First, it allows style rules (other
          than those provided by the author) to be applied, thus enabling
          the content to be presented effectively and appropriately in
          different modalities, with a range of output devices. Secondly,
          it provides the basis for structural navigation by the user. In
          order for the content to be rendered in all three modalities,
          it is also necessary to capture such distinctions as emphasis
          and changes in the natural language or notation in which the
          text is written. Note also that if this guideline is followed,
          it will enable more sophisticated analysis of the content by
          search engines and other document processing applications.
          
  Principle 3: Design for ease of comprehension, browsing and navigation
  
   Note: this principle is applicable only in circumstances in which the
   web content consists of a document or user interface which is intended
   to be presented to a human reader. A structured data base or
   collection of metadata, in circumstances where the user interface is
   supplied entirely by the client application, lies outside the scope of
   this principle.
   
    Guidelines
    
   3.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.
          The purpose of presentation is to communicate the meaning of
          the content, as effectively as possible. Thus, to aid
          understanding, it is vital that the structure and semantics of
          the content be readily apparent from the presentational
          conventions chosen by the author.
          
   3.2 Provide clear and consistent navigation mechanisms throughout a
          document or web site.
          Such navigational mechanisms may include logically organized
          groups of hypertext links, an overview or table of contents, a
          site map (with an appropriate textual equivalent; see guideline
          1.1), an index, etc. They should be easy to locate within the
          over-all structure of the content and consistent across web
          pages or related documents.
          
   3.3 Divide large blocks of information into more manageable groups
          where natural and appropriate.
          For example, divide user interface controls into logically
          organized groups. Use headings, paragraphs, lists etc.,
          appropriately to communicate relationships among items, topics
          or ideas.
          
   3.4 If search functions are provided by a web site, enable different
          types of searches for different skill levels and preferences.
          Examples needed here.
          
   3.5 Place distinguishing information at the beginning of headings,
          paragraphs, lists, etc.
          Examples? Explanations?
          
   3.6 Use the clearest and simplest language appropriate for a site's
          content.
          This guideline is intended to facilitate comprehension of the
          content by all readers, especially those with cognitive
          disabilities. It should not be interpreted as discouraging the
          expression of complex or technical ideas. Authors should
          however strive for clarity and simplicity in their writing, and
          review the text with these considerations in mind prior to
          publication on the web.
          
   3.7 Supplement text with graphic or auditory presentations where they
          will facilitate comprehension of the content.
          Auditory and graphical presentations can do much to improve the
          comprehensibility of a web site, especially to people with
          cognitive disabilities or to those who are unfamiliar with the
          language in which the textual content is written. Note that
          material provided in auditory or visual forms must also be
          available as text (see guideline 1.1).
          
   3.8 Use headings, labels and titles appropriately to identify
          structurally significant divisions within the content.
          For example, use headings to identify important topics or
          subdivisions within a document. Label table headers, user
          interface controls and other complex structures 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.
          
   3.9 Provide an overview or summary of highly structured materials,
          such as tables and groups of user interface controls.
          A discussion of which types of structures should be considered
          complex, and the circumstances in which this guideline applies,
          should be added here.
          
   3.10 Define key terms, and provide expansions for abbreviations and
          acronyms, which should be identified using appropriate markup.
          Note: only the first occurrence of an abbreviation or acronym
          occurring in a document need be expanded. Expansion
          dictionaries, for instance in metadata, may be provided as an
          alternative to an expansion in the text of a document.
          
  Principle 4: Design user interfaces for device independence
  
   Note: this principle applies only where the content provides its own
   user interface (for example as a form or programmatic object).
   
    Guidelines
    
   4.1 Associate an explicit label with each user interface control.
          This guideline applies not only to individual user interface
          controls, but also to groups of such controls, which should
          likewise be provided with descriptive labels.
          
   4.2 Ensure that user interface controls are grouped logically.
          Note that there is an upper limit to the number of user
          interface controls that should occur in a single group; see
          guideline 3.3.
          
   4.3 Ensure that event handlers are device-independent.
          Examples?
          
   4.4Design user interfaces to be compatible with assistive
          technologies.
          Use standard software conventions to control the behaviour and
          activation of user interface components. Note that
          platform-specific guidance may be available for your operating
          system or application environment.
          
  Principle 5: Design content to be compatible with the features and
  capabilities of user agents, including those which only support older
  technologies or standards.
  
    Guidelines
    
   5.1 Make sure that web sites which take advantage of newer
          technologies continue to be usable when such technologies are
          turned off or not supported.
          Note: it may be desirable to provide multiple versions of the
          same content in order to ensure backward compatibility. In
          determining the extent to which older technologies should be
          supported, content designers should bear in mind that assistive
          hardware and software are often slow to adapt to technical
          advances occurring in other areas, such as web-related
          standards. Also, for significant groups of users, it may not be
          possible to obtain the latest software or the hardware required
          to operate it.
          
   5.2 Avoid causing content to blink or flicker otherwise than under the
          control of the user.
          Note that although some user agents may permit blinking or
          flickering to be suppressed, this is not universally the case.
          Content designers should therefore exercise special care in
          avoiding such presentational effects.
          5.2 Avoid causing pages to be refreshed or updated
          automatically, otherwise than in response to a user's request.
          Note that this requirement can be satisfied by providing an
          option to deactivate automatic updating, or to control the rate
          at which it occurs. User agents may also offer control over
          this effect.
          
   5.3 Where it is likely that some user agents will not support the data
          format or encoding in which the content is supplied, provide
          metadata, a transformation filter, a style sheet or other
          mechanism to enable the content to be processed by the user
          agent.
          This requirement is especially relevant in circumstances where
          a data format or markup language which is not widely supported,
          by default, in user agent software is relied upon. Note also
          the discussion of backward compatibility in guideline 5.1.
          
   Draft prepared by Jason White.
   
   Please direct comments to the working group mailing list at
   w3c-wai-gl@w3.org.
Received on Friday, 8 September 2000 20:52:20 GMT

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