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

Notes from AUWG Teleconference 5 June 2006

From: Jan Richards <jan.richards@utoronto.ca>
Date: Mon, 05 Jun 2006 16:15:43 -0400
Message-ID: <448490EF.6030702@utoronto.ca>
To: WAI-AUWG List <w3c-wai-au@w3.org>

Regrets:
Jutta Treviranus
Greg Pisocky

Attendees:
Barry Feigenbaum
Jan Richards (acting chair)
Tim Boland

BAF: We need a definition of PLATFORM that let's Web-based tools design 
for browsers in general.

action JR: Suggest definition for platform.

TB: What is a "relevant" architecture?

action BAF: Going to think about what is a "relevant" platform architecture

All: Comments on wording in CAPS:

A.4.1 Support interoperability with assistive technologies. [Priority 1]
Rationale: Assistive technologies (e.g. screen readers, screen magnifiers,
etc.) used by many authors with disabilities rely on software applications
to provide data and control via prescribed communication protocols.

Techniques: Implementation Techniques for Checkpoint A.4.1
Success Criteria:

1.      The authoring tool should follow the relevant accessibility
platform architectures (e.g. MSAA, Java Access, etc.).
The accessibility architecture(s) used must be listed in the conformance
CLAIM. Any deviation from proper use AS DEFINED BY THE ARCHITECTURE'S 
DOCUMENTATION (i.e., lack of use, incomplete
use, inappropriate use) of the accessibility architecture must be detailed
in the conformance CLAIM.
2.      If there is any authoring tool functionality or information that
is not SUPPORTED (STATE IN CONFORMANCE CLAIM) by relevant accessibility 
platform
architectures, AT LEAST ONE OF either:
a) the authoring interface must provide an accessible equivalent (EG 
IMPLEMENTING THE ) or
b) a published interoperability mechanism must be provided (or referenced)
so that all authoring tasks can be accomplished in at least one way by an
assistive technology implementing the mechanism.
c) document the inaccessible function or information in the compliance
CLAIM


action JR: Reword (a) to use proper definitions if necessary.


A.4.2 Document how the authoring interface makes use of existing
accessibility architectures. [Priority 3]
Rationale: Allows assistive technology developers to provide enhanced
alternative user interfaces for the authoring interface.
Techniques: Implementation Techniques for Checkpoint A.4.1
Success Criteria:
1.      The authoring tool should describe how it provides accessibility
related information (such as accessible name, accessible description,
accessible role, etc. as defined by the accessibility architecture used)
for each GUI component that can receive focus. If only the default
architecture provided support (if any) is used, that should be indicated
as well.
2.      It should describe the nature and use of the information provided
(for example, is the long description the same or different from any
associated tool tip and should it be presented automatically or only on
request).

TB: Not totally clear if this refers to documentation for people or for 
AT's.

Action JR: Reword all of this and send to the group.



Cheers,
Jan
Received on Monday, 5 June 2006 20:16:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT