- From: Richards, Jan <jrichards@ocad.ca>
- Date: Wed, 9 Feb 2011 17:16:43 -0500
- To: AUWG <w3c-wai-au@w3.org>
On the call I took an action to look at this... http://www.w3.org/2002/09/wbs/35520/20110204/results#xq3 The original spirit of the SC was: "does the tool let accessibility-savvy users meet wcag by SOME means (e.g. a text view)" As pointed out, this is a low bar. The proposed rewording tried to tighten this up to basically say: "if the user can use the tool to break WCAG conformance then they can use the tool to fix it" But in the interests of avoiding repetition, I think this is covered already, especially by: - B.2.2.2 Setting Accessibility Properties (WCAG) - there needs to be mechanisms to set accessibility properties - B.3.1.1 Checking Assistance (WCAG) - authoring tool will help find issues (even if the help is manual). And the wording is similar enough to B.2.1.1: "If the authoring tool provides authors with the ability to add or modify web content so that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g. an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions)." - B.3.2.1 Repair Assistance (WCAG) - authoring tool will help repair issues (even if the help is manual) So, I suggest we drop B.2.1.1 altogether. Cheers, Jan -- (Mr) Jan Richards, M.Sc. jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844 Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/ Faculty of Design | OCAD University
Received on Wednesday, 9 February 2011 22:17:31 UTC