RE: Checkpoints for Guideline 6

I agree with Charles' suggestions below, Jan's suggestions for 6.2
scares me -- every authoring tool would have to do their own
interpretation of the WCAG guidelines, and then supply information about
which browsers support which tags.  I would much rather see authoring
tools document how they support WCAG or just point users to WCAG.

Heather Swayne

P.S. this e-mail was written using voice dictation technology so please
excuse any "voice mistakes"


-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org] 
Sent: Tuesday, July 03, 2001 7:29 AM
To: Jan Richards
Cc: WAI AU Guidelines
Subject: Re: Checkpoints for Guideline 6

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
functionality).

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
techniques.

cheers

Chaals

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 Sunday, 15 July 2001 21:30:39 UTC