W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 1999

New draft with details

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 8 Dec 1999 08:45:45 -0500 (EST)
To: WAI AU Guidelines <w3c-wai-au@w3.org>, Judy Brewer <jbrewer@w3.org>
Message-ID: <Pine.LNX.4.20.9912080827330.22545-100000@tux.w3.org>
Dear all,

thanks to Ian there is a new draft at
http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991208 for your perusal.

The following outlines the text added to (or in some cases the new vesrions
of text in) the draft which will be published shortly. This text is intended
to resolve the concerns raised in member review (except the suggestion about
having a "priority 0", for which the proposed resolution is not to do it).


From the definitions of priority:

 as part of relative priority:

  All authoring tools should support all applicable Web Content Guideline
  checkpoints, but the nature of that support may vary according to the
  nature of the authoring tool, the expected skill level of the author using
  the tool, and the requirements of each WCAG checkpoint. In some cases
  support can be provided automatically, without the need for explicit author
  participation, in other cases human judgment is required and support is
  provided by the tool in the form of prompts and documentation.

 and as a general not on priorities:

  In choosing priority levels for checkpoints, the Working Group has assumed
  that "the author" is a competent, but not necessarily expert, user of the
  authoring tool, and that the author has no prior knowledge of
  accessibility. For example, the author is not expected to have read all of
  the documentation but is expected to know how to turn to the documentation
  for assistance.

From the Conformance section (note that the piece on applicability in the 2 december draft was removed)

  Note. Some example conformance evaluations are available. It should be
  noted that conformance claims are not necessarily validated or endorsed by
  W3C.

Checkpoint 1.3 (as per the meeting yesterday):

  1.3 Ensure that when the tool automatically generates markup it conforms to
  the W3C's Web Content Accessibility Guidelines
  [WAI-WEBCONTENT].  [Relative Priority]


Checkpoint 3.1:

  3.1 Prompt the author to provide equivalent alternative information (e.g.,
  captions, auditory descriptions and collated text transcripts for
  video). [Relative Priority]
  Note. Some Checkpoints in Web Content Accessibility Guidelines
  [WAI-WEBCONTENT] may not be applicable.

Checkpoint 3.2:

  3.2 Help the author create structured content and separate information from
  its presentation. [Relative Priority]
  Note: Some Checkpoints in Web Content Accessibility Guidelines
  [WAI-WEBCONTENT] may not be applicable.

First para of guideline 4 introduction:

  Many authoring tools allow authors to create documents with little or no
  knowledge about the underlying markup. To ensure accessibility, authoring
  tools must be designed so that they can (where possible
  automatically) identify inaccessible markup, and enable its correction even
  when the markup itself is hidden from the author.

Checkpoint 4.1:

  4.1 Check for and alert the author to accessibility problems. [Relative
  Priority]
  Note: Accessibility problems should be detected automatically where
  possible. Where this is not possible, the tool may need to prompt the user
  to make decisions, or to manually check for certain types of problem.

Check for, in 4.1 is linked to the follwing definition in the definitions section:

  Check for as used in checkpoint 4.1, check for can refer to three types of
  checking:

  In some instances an authoring tool will be able to check
  automatically. For example checking for validity Refer also to checkpoint
  2.2. or testing whether an image is the only content of a link.

  In some cases the tool will be able to "suspect" or "guess"that there is a
  problem, but will need to confirm with the author. For example, in making
  sure that a sensible reading order is preserved a tool can present a
  linearided version of a page to the author.

  In some cases a tool must rely mostly on the author, and can only ask the
  author to check. For example, prompting the author to check whether
  equivalent alternatives for multimedia are appropriate. This is the minimal
  standard to be satisfied. Subtle, rather than extensive, prompting is more
  likely to be effective in encouraging the user to verify accessibility
  where it canot be done automatically.

--Charles McCathieNevile    mailto:charles@w3.org  phone: +61 409 134 136
W3C Web Accessibility Initiative                    http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)
Received on Wednesday, 8 December 1999 08:45:46 UTC

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