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

AUWG action items from June 6 related to templates

From: Richards, Jan <jrichards@ocad.ca>
Date: Wed, 8 Jun 2011 13:09:48 -0400
To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <F2C77FB59A1A4840A01EF5F59B1826E20A3F3205F1@ocadmail.ocad.ca>
Hi all,

Several of the action items that I took on Monday had to do with accessible templates:
- To reword with conditional on potential for accessibility problems. [related to: B.2.5 - MS51]
- To propose conditional on inaccessible potential [related to B.2.5 - MS55]
- To clarify for accessible templates that there may be no instructions for blank document type templates. [related to: B.2.5 - MS54]

AND the following points are also relevant:
- there is no agreed standard for how to indicate the accessibility of templates in metadata, so we need to take into account plain text information in description fields. Authoring tools can't use such information to ensure prominence.
- "range" is used in ATAG 2.0 as a result of a compromise that hasn't been properly explained.

Multi-part proposal:

1) Explain ATAG 2.0's use of the term "range" with a glossary entry.

More than one item within a multi-item set. 
(Informative) Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set ", implementers are strongly encouraged to implement the success criteria more broadly.

2) Update the definition of "accessible templates (WCAG)" to be more clear about the case of templates resulting in empty documents:

accessible templates (WCAG): 
Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true:
(a) The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and
(b) No further authoring occurs.
Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.

3) B.2.4.1 - link "range" to new definition and add a note to make it clear how the next SCs build on this one.

B.2.4.1 Accessible Template Options (WCAG): If the *authoring tool* provides *templates*, then there are *accessible template (WCAG)* *options* for a *range* of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Note: The accessible options are not necessarily identified.

4) Re-word B.2.4.2 to make it conditional on the presence of inaccessible templates offerings and take into account that the distinction might be via a textual description field which the authoring tool can't process. Also moved in the requirement to label developer-supplied templates in some way (was in B.2.4.4 AAA) - otherwise what is the point? 

B.2.4.2 Identify Template Accessibility (Minimum): If the *authoring tool* includes a *template selection mechanism* and provides any non-*accessible template (WCAG)* *options*, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)
Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both. 

ED: In the implementing doc we can explain that the mechanism is not specified and might include: (a) data in dedicated metadata fields (e.g. a WCAG conformance level), (b) plain text in a description field (e.g., "5-day week calendar template. Meets WCAG Level A"), or (c) on-the-fly checkers, if the template format supports it etc.

5. Re-word B.2.4.3 to mirror B.2.4.2

B.2.4.3 Author-Created Templates: If the *authoring tool* includes a *template selection mechanism* and allows *authors* to create new *templates* that are not *accessible templates (WCAG)*, then authors have the *option* to enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)
Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.

ED: Same note on mechanism as for B.2.4.3.

6. Change the SC to handle the case of authoring tools that lack template selection mechanisms and remove unnecessary reference to a repository.

B.2.4.2 Identify Template Accessibility (Enhanced): If the *authoring tool* provides any non-*accessible template (WCAG)* *options* and does not include a *template selection mechanism*, then the non-accessible templates include accessibility warnings within the templates. (Level AAA)

ED: Alternatively at Level AAA maybe we could just require a template selection mechanism so that B.2.4.2 and B.2.4.3 would apply?

(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University
Received on Wednesday, 8 June 2011 17:10:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:00 UTC