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

Re: Checkpoints for Guideline 6

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 3 Jul 2001 10:29:29 -0400 (EDT)
To: Jan Richards <jan.richards@utoronto.ca>
cc: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.30.0107031017250.11425-100000@tux.w3.org>
I still think what I was saying at the meeting, that documenting howto use
the functions of a tool, and documenting how to make accessible content using
a tool, are different things. The first is "how do I use the features the
tool provides?", while the second includes "what work-arounds can I use to
get to WCAG level something.

My feeling is that the first is a P1 requirement, and that the second is
probably a relative priority requirement. Note that in a tool likely to
comply to ATAG that the first requirements should fulfill the second, but in
a tool that only makes partial conformance the second is an extremely useful
thing to do anyway, because it provides good support for authors.

So I would adjust the minimum requirement section of 6.1 proposed to say

Document the purpose and use of features of the tool that help create
accessible content.

I would propose that the current 6.2 (Include accessibility in all
documentation) belongs in Guideline 5 - it is like a special case of 5.3, but
not exactly the same.

I propose replacing Jan's 6.2 proposal with the following:

Document the process of using the tool to produce WCAG-conformant content
[relative priority]

Rationale: Motivated users of the tool may be able to produce accessible
content without the support provided by mechanisms such as accessibility
checking and repair functions.

Basic functionality requiremed: Document the techniques required to meet all
WCAG checkpoints at the relevant priority level - (these may include
work-around methods where the tool does not yet have the appropriate

Optional advanced functionality: Automating the process of producing
accessible content will mean that nothing special needs to be done to meet
this checkpoint. But providing context-senstive linking to this documentation
may be an intermediary development strategy.

See also: 3.1, 3.2, 4.1, 4.2, Techniques for this checkpoint, WCAG



On Mon, 25 Jun 2001, Jan Richards wrote:

  Good morning,

  At the meeting, I said I'd send a proposal for how to rework the
  checkpoints in section 3. My proposal condenses the requirements down to
  2 checkpoints. The first is a P1 that addresses "how do I use the
  accessibility related features of this tool?". The second is a P2 that
  addresses the general "how do I make documents in this language
  accesssible?". Some of the other things have been worked in as minimum
  or advanced requirements of these.

  6.1 Document features of the tool that promote the production of
  accessible content. [Priority 1]

  Rationale: Documenting each accessibility related feature of the tool
  (dialog boxes, utility, code views, etc.) will help authors to learn how
  to use them effectively.

  Minimum functionality: Include documentation that explains the purpose
  and use of the relevant features and document the process by which these
  features of the tool can be used to create accessible content.

  Optional advanced functionality: Provide context-sensitive links to this
  documentation from the actual features, within the authoring tool user
  interface. Also provide a dedicated "Accessibility" section of the
  documentation for this material.

  See also: Techniques for checkpoint 6.1


  6.2 Document accessibility practices for all languages supported.
  [Priority 2]

  Rationale: Documenting the accessibility practices of the languages
  supported will make these practices more visible to authors.

  Minimum functionality: Provide an overview of the tags and attributes of
  the supported languages that are required to enhance accessibility. The
  documentation might explain which disability groups and user agents
  benefit from their use.

  Optional advanced functionality: All documented examples of markup
  should include any relevant accessible authoring practices.

  See also: Techniques for checkpoint 6.2

Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Tuesday, 3 July 2001 10:29:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:46 UTC