- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 11 Jan 2010 12:49:30 -0500
- To: w3c-wai-au@w3.org
Hi all, I had 4 action items from the last meeting.... ---------------------------------------------------- ACTION: JR to Add "Remember" sections in context as proposed text - also reword the "manual" check/repair clarifications to more positively portray automated and semi-autoameted without removing the possibility of the manual option - I'm having second thoughts about adding new language ("Remember") outside the normative success criteria, since this is even further from the SC's that seem to be confusing people. Instead let's revise the SC notes. - How about this for less negative text for the note: Note: While automated checking or more advanced implementations of semi-automated checking are possible for many types of web content accessibility problems, manual checking is the minimum requirement to meet success criteria B.2.2.1, B.2.2.4 and B.2.2.10. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves without further automated assistance. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation. ---------------------------------------------------- ACTION: JR to Take A.3.6 back to drawing board - add points about when to pass OS and when perhaps not - How about? +A.3.6.1 Save Settings: Authoring tool *display settings* and *control settings* are saved between sessions. (Level AA) + Define "control settings" as: Settings that relate to how the author controls the authoring tool, for example using the keyboard or mouse. + A.3.6.2 Multiple Sets: The author(s) can save and reload multiple sets of any authoring tool *display settings* and *control settings*.(Level AAA) + A.3.6.X Respect Platform Settings: The authoring tool respects platform *display settings* and *control settings*. (Level AA) Note: As per Guideline A.2.3, the author's display settings must still be independent of the web content being edited. A.3.6.3 Options Assistance: The authoring tool includes a mechanism to help the author(s) configure ANY options related to Part A. (Level AAA) - BTW: I wouldn't be heartbroken to see A.3.6 disappear. I don't think it is especially authoring tool-specific. ---------------------------------------------------- ACTION: JR to reword proposal with applicability instead of responsibility. [applies to Part B: Responsibility After Authoring Sessions] New suggestion: Applicability after the *End of an Authoring Sessions*: For *author-generated content*, the requirements of *Part B* apply only during *authoring sessions*. For example, if the *author* includes a third-party feed in their *web content*, the *authoring tool* is not required to provide *checking* for *web content accessibility problems* in that feed after the *end of the authoring session*. In contrast, for *automatically-generated content*, Part B continues to apply after the *end of an authoring session*. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for *automatically generated content*. ---------------------------------------------------- [NEW] ACTION: JR to Write some intent text for B.1.1.1 to explain that instead of accessibility supported uses we took the decision support approach in B.2.1 - This is always such a can of worms... - I think that because we mention "conformance to WCAG 2.0" all over the place, this is a larger issues that should address head-on in "Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0 " - Here is my attempt at renewing how we talk about WCAG: (1) In general, we might consider saying something like "meets the WCAG 2.0 success criteria" instead of "conforms to WCAG 2.0" to lessen the confusion. (2) And I think a rewording of the "Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0" is in order: In order to make recommendations regarding (1) the accessibility of web-based authoring tool user interfaces (in Part A) and (2) how authors should be enabled, supported, and guided towards producing accessible web content (Part B), ATAG 2.0 relies on the concept of *accessible web content*. Since, as of publishing, WCAG 2.0 is the most recent W3C Recommendation regarding web content accessibility, ATAG 2.0 references WCAG 2.0 in its definition of accessible web content. *Note on Specific Technologies:* It is important to note that the normative success criteria in WCAG 2.0 are not technology-specific. Specific informative (non-normative) guidance for satisfying the success criteria for particular web content technologies are provided for WCAG 2.0 in separate documents (e.g., How to Meet WCAG 2.0). When ATAG 2.0 requires "information on how the web content technology might be used to create accessible web content" for *Included Technologies* in the *Required Components of an ATAG 2.0 Conformance Claim*, this is intended to document the authoring tool's actual implementation, not imply that the web content techniques that an authoring tool supports are normative. *Note on "Accessibility-Supported Ways of Using Technologies":* WCAG 2.0 includes a conformance requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported." In broad terms, a technology is considered accessibility supported when (1) the way that the Web content technology is used is supported by users' assistive technology and (2) the Web content technology has accessibility-supported user agents that are available to users. WCAG 2.0 notes that "accessibility support of Web technologies varies by environment...[and] by language (and dialect)". For more detailed information, see WCAG 2.0. Extending this concept to authoring tools is problematic because (1) authoring tools are marketed and used across organizational, political and linguistic borders and (2) the context of use of an authoring tool is usually set by each person who installs the software and acts as an author. Therefore: *When any ATAG 2.0 success criterion requires web content to meet the requirements of WCAG 2.0, specifying "accessibility-supported ways of using technologies" is not required.* Of course, once an authoring tool has been installed and put into use, it would be appropriate for the web content it produces to be assessed for WCAG 2.0 conformance, including whether "only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria". Talk to everyone at 3pm. Cheers, Jan -- Jan Richards, M.Sc. User Interface Design Lead Adaptive Technology Resource Centre (ATRC) Faculty of Information University of Toronto Email: jan.richards@utoronto.ca Web: http://jan.atrc.utoronto.ca Phone: 416-946-7060 Fax: 416-971-2896
Received on Monday, 11 January 2010 17:50:03 UTC