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

Re: Edits to 3.1 and 4.3

From: Jan Richards <jan.richards@utoronto.ca>
Date: Sat, 30 Oct 2004 15:39:15 -0400
Message-ID: <1099165155.4183ede39013d@webmail.utoronto.ca>
To: Jutta Treviranus <jutta.treviranus@utoronto.ca>
Cc: "List (WAI-AUWG)" <w3c-wai-au@w3.org>

Hi Jutta,

I think it's looking better. Here are some comments

Quoting Jutta Treviranus <jutta.treviranus@utoronto.ca>:

> 3.1 Prompt and assist the author to create content that conforms to 
> WCAG.  [Web Content Checkpoints Relative to WCAG]
> Rationale: Appropriate assistance should increase the likelihood that 
> typical authors will create content that conforms to WCAG. This 
> assistance should help to prevent the author from making decisions or 
> omissions that cause accessibility problems. If accessibility 
> problems are prevented, less effort is required to create content 
> that conforms to WCAG.    Different tool developers will accomplish 
> this goal in ways that are appropriate to their products, processes, 
> and authors.
> Techniques:  Implementation Techniques for Checkpoint 3.1
> Success Criteria:
> 	1. When content is added that requires information from 
> the author in order to conform to WCAG, then the authoring tool must 
> inform the author that this additional information is required (e.g. 
> via input dialogs, interactive feedback, etc.). (determine level)

1.When content is added that requires *accessibility information* from 
the *author* in order to *conform to WCAG*, then the authoring tool MUST 
inform the author (e.g. via input dialogs, interactive feedback, etc.) that 
this additional information is required.

[JR: very minor changes]

> 2. If the authoring tool provides guidance then that guidance should 
> direct the author to use authoring practices that are most likely to 
> lead to Web content that conforms to WCAG.

2.If the authoring tool provides any authoring practice guidance to the 
author, then that guidance MUST direct the author to use accessible authoring 
practices (i.e. most likely to lead to Web content that conforms to WCAG).

[JR: very minor changes, we might also state this the other way: i.e. don't 
guide authors towards the wriong things.]

> 3. When the author is presented with a list of choices, that includes 
> choices of formats or authoring practices that do not support content 
> that conforms to WCAG, these should be marked to indicate that the 
> choice may produce content that is inaccessible.

3.The authoring tool must provide an option to mark less accessible choices 
(e.g. formats for which there is no published WCAG techniques document, 
inaccessible authoring practices).

[JR comment: this whole success criteria may go too far for a Rel Priority 
checkpoint. We already have some less strict (more implicit) requirements on 
this in 2.1 and 4.1]


> 4.3. Ensure that the author is encouraged to consider accessibility 
> throughout the authoring process in any feature that assists the 
> author in sequencing actions. [Priority 2]

4.3. Ensure that sequential authoring processes integrate accessibility 
features. [Priority 2]

> Rationale: Accessible design as an afterthought or separate process 
> is much more onerous and therefore costly than when accessibility is 
> considered from the start. If the authoring tool supports the author 
> in considering accessibility before and/or during the authoring 
> process it is more likely that accessible authoring practices will 
> become a common practice. This is analogous to internationalization, 
> which is much easier when it is considered from the beginning rather 
> than handled last.
> Techniques: Implementation Techniques for Checkpoint 4.3
> Success Criteria:
> 	1. 	Any feature that helps to sequence author actions 
> (eg., templates, wizards, tutorials, instruction text) must integrate 
> accessibility prompting. These prompts should occur before or at the 
> time that the author is required to make the authoring decision 
> related to the prompt.

1.Any authoring tool process that imposes a sequence on author actions 
(eg., object insertion dialogs, wizards, design guides, templates, etc.) MUST 
integrate accessibility prompting prior to the earliest *completion point of 
the process*.

[JR comment: the new formulation covers wizards just as well as image 
insertion dialogs, the def'n of *completion point of the process* would rule 
out situations in which the author cancels a process.]
Received on Saturday, 30 October 2004 19:39:38 UTC

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