- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 13 Mar 2006 11:59:21 -0500
- To: w3c-wai-au@w3.org
Hi, On the last call I was assigned to review B.1.1 (see message: http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0032.html). Here are my thoughts so far: ---------- Points for Discussion: IN GUIDELINES: http://www.w3.org/WAI/AU/2005/WD-ATAG20-20051216/WD-ATAG20-20051216.html#gl-enable-accessible-content 1) Checkpoint wording is ok. 2) Due to the amount of confusion surrounding new content types, this checkpoint could benefit from re-wording the rationale and adding a note. Here is some suggested text. RATIONALE: The checkpoints in Part B assume that there is nothing intrinsic about the content type of the content being authored that prevents that *content from being accessible*, which, for ATAG 2.0, means content that conforms to WCAG. NOTE 1: The content type-specific WCAG benchmark documents required in the success criteria for this checkpoint can be created for any *content type* (including non-W3C or new types) by any person or organization. For more information, see *section 2.2.3 Content Type-Specific WCAG Benchmark*. NOTE 2: A *content type-specific WCAG benchmark* document is required for at least one *content type* that is supported by the authoring tool. Any ATAG conformance claim will be specific to authoring the content type(s) for which benchmark documents are provided. 3) The two success criteria look good, though I might suggest switching the construct "Any authoring tool that..." to "If the authoring tool..." IN TECHNIQUES: http://www.w3.org/WAI/AU/2006/techs/tech2.html#check-prefer-w3c 1) Technique B.1.1-1.1 [Sufficient]: minor rewording Providing a content type-specific WCAG benchmark (in the ATAG 2.0 conformance profile) for all content types that are automatically chosen for the author by the tool (e.g. tools may automatically choose the content type when a type is the only one that is supported for a given task or because a shortcut is provided that allows new content to be created with a minimum of steps). 2) Technique B.1.1-2.1 [Sufficient]: minor rewording If the author is given the option to choose a content type, providing at least one content type, for which a *content type-specific WCAG benchmark* has been published, in a prominent way (i.e. listed ahead of other content types, listed on the first page of choices, etc.). 3) Technique B.1.1-2.2 [Advisory]: minor rewording Displaying a warning when the author chooses to create Web content with a content type that lacks a published content type-specific WCAG benchmark. 4) Technique B.1.1-0.1 [Advisory]: minor rewording Consulting *section 2.2.3 content type-specific WCAG benchmark in ATAG 2.0* for guidance on how to create a benchmark document for a content type that does not already have one. 5) Technique B.1.1-0.2 [Advisory]: minor rewording Supporting W3C Recommendations, wherever appropriate. Since these content types have already been reviewed for accessibility, the task of locating or creating *content type-specific WCAG benchmarks* for them may be simplified. References include: Technical Reports and Publications page of the W3C. W3C language specific accessibility notes: CSS [CSS-ACCESS], SMIL [SMIL-ACCESS], HTML4 [HTML4-ACCESS], SVG [SVG-ACCESS], XML languages [XML-ACCESS] 6) Technique B.1.1-0.3 [Advisory]: minor rewording For tools that dynamically generate Web content, supporting multiple content types each with a *content type-specific WCAG benchmark* document, and using content negotiation to deliver content in the end-user's preferred content type. 7) Technique B.1.1-0.X [Advisory]: NEW AFTER B.1.1-0.1 Consulting the techniques section of the WCAG-WG for techniques documents and other supporting materials that may inform or even provide the basis for a *content type-specific WCAG benchmark*. http://www.w3.org/WAI/GL/wcag20.html#techs ---------- Cheers, Jan
Received on Monday, 13 March 2006 17:00:00 UTC