W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2006

Re: ATAG 2.0 In-group checkpoint review: B.2.7 (+B.2.8, B.3.2, B.3.4)

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 18 Apr 2006 11:00:45 -0400
Message-ID: <4444FF1D.3060201@utoronto.ca>
To: w3c-wai-au@w3.org

Yesterday I took an action item to show how the checkpoints affected by 
my proposed changes 
(http://lists.w3.org/Archives/Public/w3c-wai-au/2006AprJun/0003.html) 
will look.

Note:
- I have left out the text of checkpoints that will not change.
- I bounded the ones that do change with "-----")
- I made a few additional editorial changes

Here they are:


GUIDELINE B.2: Support the author in the production of accessible content

B.2.1: Prompt and assist the author to create content that conforms to 
WCAG. [RP]

B.2.2: Check for and inform the author of accessibility problems. [RP]

B.2.3: Assist authors in repairing accessibility problems. [RP]

B.2.4: SOON TO BE PROPOSED TEXT: Assist authors to ensure that 
equivalent alternatives for non-text objects are accurate and fit the 
context. [P1]

B.2.5: Provide functionality for managing, editing, and reusing 
alternative equivalents. [P3]

B.2.6: Provide the author with a summary of accessibility status. [P3]

B.2.7: Provide a tutorial on the process of accessible authoring. [P3]


GUIDELINE B.3: Promote and integrate accessibility solutions

B.3.1 Ensure that the most accessible option for an authoring task is 
given priority. [P2]

B.3.2 (was B.3.3) Ensure that sequential authoring processes integrate 
accessible authoring practices. [P2]

-----
B.3.3 (was B.3.2) Ensure that features of the tool that support the 
production of accessible content are always clearly available to the 
author. [P2]

Rationale:
If the  features of the tool that support the production of
accessible content (e.g. prompts for alternatives, code validators, 
accessibility checkers, etc.) are difficult to find and activate, they 
are less likely to be used.

Success Criteria:
1. All *accessible content support features* must match or exceed the
prominence of any corresponding features related to other classes of Web
content problems (e.g. markup validity, program code syntax, spelling
and grammar).
-----

-----
B.3.4 Ensure that features of the tool that support the production of
accessible content are configurable. [P3]

Rationale:
A *configurable* tool is more likely to be adaptable to the work habits 
of more authors. Ideally, features of the tool that support the 
production of accessible content (e.g. prompts for alternatives, code 
validators, accessibility checkers, etc.) should be turned on by default.

1. All *accessible content support features* must be turned on by default.

2. If the author does turn off an *accessible content support feature*, 
then the authoring tool must inform the author that this may increase 
the risk of content accessibility problems.

3. If the author does turn off an *accessible content support feature*, 
then the author must always have the option to turn the feature back on 
again.

-----

-----
B.3.5 (was B.2.7): Document features of the tool that support the 
production of accessible content. [P2]

Rationale:
Without documentation of the  features of the tool that support the 
production of accessible content (e.g. prompts for alternatives, code 
validators, accessibility checkers, etc.) authors may not find or use them.

Success Criteria:
1. All *accessible content support features* must be documented in
the help system.
-----

-----
B.3.6 (was B.2.8): Ensure that any authoring practices demonstrated in 
repair instructions and *documentation* are accessible. [P3]

Rationale:
If accessible authoring is integrated into the repair instructions and 
*documentation* offered by the tool, authors will be presented with 
accessible authoring as a common practice. This can also facilitate a 
better understanding of the reasoning and consequences related to 
authoring *accessible Web content*.

Success Criteria:
1. All examples of markup and screenshots of the authoring tool user 
interface that appear in the repair instructions and *documentation* 
must demonstrate *accessible authoring practices*.
-----


GLOSSARY CHANGE:

Accessible content support feature:
All features of the tool that play a role in satisfying the success 
criteria for any of the checkpoints in Guideline B.2 (i.e. B.2.1, B.2.2, 
B.2.3, B.2.4, B.2.5, B.2.6 and B.2.7).
Received on Tuesday, 18 April 2006 15:01:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT