- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 1 Jun 1999 14:26:51 -0400 (EDT)
- To: pjenkins@us.ibm.com
- cc: w3c-wai-au@w3.org, chisholm@trace.wisc.edu
The minutes have been updated with these changes charles On Wed, 19 May 1999 pjenkins@us.ibm.com wrote: Also, the minutes [http://www.w3.org/WAI/AU/f2f-may99] need to change regarding three items: 1. What was: Action PJ, BR: Look through IBM guidelines, compare with TRACE tool, note differences to group should change "with TRACE tool" to with "TRACE updated guidelines" so it reads: Action PJ, BR: Look through IBM guidelines, compare with TRACE updated guidelines, note differences to group 2. What was: Scribe's note: I thought I recalled an action item being assigned to Wendy Chisholm and I to look through TRACE guidelines as well, but find no record. change to: Wendy Chisholm did take a work item to "update" - or at least review the TRACE software guidelines and send the "latest" to Bruce and I so we could compare with the IBM software guidelines and note differences [submit a proposal] to the working group. 3. What was: PJ Imagine Phill says we must address accessibility of the tool. e.g.... should change to [from my meeting notes]: PJ Pretend for a moment I agree that we should cover the accessibility of the authoring tool: The current document leaves out many important software accessibility guidelines, even though it points to "platform guidelines" and "User Agent guidelines". The important guidelines that it leaves out are applicable to creating/editing content that is accessible per the WCAG. Five examples: 1. Sound only may be used [inaccessibly] to warn the author that they forgot to do 2.3.2 Prompt the author for all missing structural information. 2. Color only may be used [inaccessibly] to warn the author that they are NOT using 2.1.1 "W3C tags". 3. Documentation may be missing or documentation that is provided may be inaccessible even if it covers the accessibility features, for example: How the authoring tool 2.3.1 prompts the author to provide alternative content. 4. The authoring tool needs to document accessibility features that it provides, for example what are the keyboard shortcuts 5. Testing with assistive technology vendors, users with disabilities, and or assistive technology testing tool. So why do we have some of the software guidelines in here and not others. If some of these are repeated, we might as well repeat all of them. I would prefer to not repeat any of them and *not* cover the software accessibility of the tool in these authoring tool guidelines. Regards, Phill Jenkins --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://www.w3.org/People/Charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Tuesday, 1 June 1999 14:26:55 UTC