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

Re: WAI AU Meeting minutes 5/16/99

From: <pjenkins@us.ibm.com>
Date: Wed, 19 May 1999 18:06:09 -0500
To: Charles McCathieNevile <charles@w3.org>, w3c-wai-au@w3.org
cc: chisholm@trace.wisc.edu
Message-ID: <85256776.007F4E4C.00@d54mta08.raleigh.ibm.com>


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
Received on Wednesday, 19 May 1999 19:11:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC