Meeting Notes from AUWG F2F in Austin, TX (5-6 Dec 2005)

Meeting Notes from AUWG F2F in Austin, TX (5-6 Dec 2005)

Day 1: Monday , Dec 5, 2005

Attendees: Jutta Treviranus (Chair), Jan Richards, Barry Feigenbaum,
Tim Boland

- Guido Corona of the visited the group briefly.

1. Discussion of Public Draft comments

- Web-Based Interface note reworded somewhat:
"For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve 
to meet success criteria 1 and 2 of this checkpoint. Browser 
functionality (e.g. for "cut/copy/paste") or access keys (e.g. for "open 
new content") may be relied on to achieve success criteria 3 and 4 as 
long as the applicable user agent(s) are specified in the conformance 
profile. Also see Checkpoint A.3.1 when choosing keystrokes."


2. Checkpoint A.1.5 - Success Criteria

Success criteria agreed upon:

"For author-controlled presentation in rendered editing views (e.g. 
author has used a style class), all characteristics of the presentation 
(e.g. color, boldness, positioning, etc.) must be available 
programmatically (@@define@@).

For authoring tool - controlled presentation in editing views (e.g. 
coloring misspelled words, identifying tag text in a code view), the 
semantic description of the presentation must be available programmatically.

For the presentation of controls within the authoring tool user 
interface (e.g. dialog boxes, menus, button bars, user interface 
elements in the editing view (@@define: "chrome" or similar@@)), the 
semantic description of the presentation must be available programmatically.

Any information that is conveyed by color (e.g. red underlining for 
spelling error vs. green underlining for grammar error) is either 
visually evident when color is not available (e.g. by the shape of the 
underlining) or is provided by an alternative version that meets Part A 
(e.g. spell and grammar checking utilities). "

New definition: Available Programmatically

Capable of providing information to other software (including assistive 
technologies) by following relevant accessibility platform architectures 
(e.g. MSAA, Java Access, etc.) or, if the available accessibility 
platform architectures are insufficient, following some other published 
interoperability mechanism (custom-created by the developer, if necessary).

Edited definition: Authoring Tool User Interface

The user interface of the authoring tool is the display and control 
mechanism that the author uses to to communicate with and operate the 
authoring tool software. Authoring tool interfaces may be:
Web-Based: tools that are implemented using Web content and run within a 
user agent, or
Non-Web-Based: tools that run directly on a operating system such as 
Windows or Mac OS (tools may include both types of interfaces).
Most authoring interfaces are composed of two parts (the exception being 
high-level authoring functions which may not have a content display):
1. Content Display: The rendering of the content to the author in the 
editing view. This might be as marked up content (e.g in a code view) or 
as text, images, etc. (e.g. in a WYSIWYG view).
2. Editing Interface: All of the parts of the user interface that are 
not the content display (e.g. authoring tool menus, button bars, pop-up 
menus, floating property bars, documentation windows, cursor, etc.). 
These parts surround and in some cases are superimposed on the content 
display.


3. Def'n of Content Type (was Technology)

Edited to read: "A content type is a data format, programming or markup 
language (e.g. HTML, CSS, SVG, PDF, Flash, etc.). The usage of term is a 
subset of WCAG 2.0's current usage of the term "Technology"."

Action JR: Talk to WCAG about their use "technology" and our use of 
"Content Type" and also about benchmark documents.


4. Rework success criteria for B.1.2 (preserve unrec content)

Accepted JR's proposal with minor edits:

During all transformations and conversions supported by the authoring 
tool, the author must be notified before any unrecognized markup is 
permanently removed.

During all transformations and conversions supported by the authoring 
tool, accessibility information must always be handled according to at 
least one of the following: (a) preserve it in the target format such 
that the information can be "round-tripped" (i.e. converted or 
transformed back into its original form) by the same authoring tool,

(b) preserve it in some other way in the target format, or

(c) be removed only after the author has been notified and the content 
has been preserved in its original format.


5. Rework success criteria for B.2.4 (do not automatically create 
alternatives)

Accepted JR's proposal with minor edits:

The tool must never use automatically generated equivalent alternatives 
for a non-text object (e.g. a short text label generated from the file 
name of the object).

When a previously authored equivalent alternative is available (i.e. 
created by the author, pre-authored content developer, etc.), the tool 
must prompt the author to confirm insertion of the equivalent unless the 
function of the non-text object is known with certainty (e.g. "home 
button" on a navigation bar, etc.).


6. Split to success criteria for B.3.3 into:

Interactive features that sequence author actions (e.g. object insertion 
dialogs, templates, wizards) must provide any accessibility prompts 
relevant to the content being authored at or before the first 
opportunity to complete the interactive feature (without canceling).

For read-only instruction text (e.g. tutorials, reference manuals, 
design guides, etc.) that includes a sequence of steps for the author to 
follow, the relevant accessibility authoring practices must appear in 
the step sequence before the first opportunity to complete the sequence.


7. In A.4.1:

TB: "Conform" is difficult to quantify.

Group decided to reword success criteria 1, to:

"The authoring tool must follow accessibility platform architectures 
(e.g. MSAA, Java Access, etc.)."


8. Fine tuning of the Conformance Scheme.

BAF reminded group of ideas on partial conformance, TB wanted to make 
sure that non-conforming tools were not confused with conforming ones. A 
compromise solution is the addition of a section called: "Progress 
Towards Conformance Statement" that tools could use to record progress 
even if no conformance level is claimed.


------------------------
Day 2: Tuesday, Dec 6, 2005

Attendees: Jutta Treviranus (Chair), Jan Richards, Barry Feigenbaum,
Tim Boland

- Guido Corona of the visited the group briefly again.

- JT was held up at another function and did not join the meeting until 
after lunch.

1. Last Call Comment Table

Completely reviewed and where necessary edited last call comments.

Action JR: Post these on the AU site.

2. Techniques

TB: Also techniques should be as specific and detailed as possible 
(exactly how does an offerer meet the referenced SC for their particular 
circumstances?) If an offerer doesn't know where to start in order to 
meet the SC, here are some specific ways that the WG has deemed 
"sufficient" for meeting the SC (however, there may be other 
"sufficient" ways (that the WG doesn't yet know about) besides those 
given in this techniques document)

For ATAG techniques rework,  group decided to keep "sufficient" 
designations for applicable individual
techniques but maybe add more "contextual sufficiency" information in 
"introduction" section of techniques?

Discussed A.4.1 - which was expanded.

Technique A.4.1-1: Implementing the relevant accessibility platform 
architecture(s) [Sufficient]:

Gnome Accessibility: 
<http://developer.gnome.org/doc/API/2.0/atk/AtkObject.html>
Eclipse Accessibility: 
<http://download.eclipse.org/eclipse/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/reference/api/overview-summary.html>
Java Swing: 
<http://java.sun.com/j2se/1.5.0/docs/api/javax/accessibility/package-summary.html> 

MacOS X Accessibility: "Accessibility Documentation" [APPLE-ACCESS] 
Apple Computer Inc.
Carbon 
<http://developer.apple.com/documentation/Carbon/Conceptual/MakingAppsAccessible/index.html>
Cocoa 
<http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/index.html> 

Microsoft Windows Active Accessibility:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/accessibility.asp> 


Technique A.4.1-2: Extend an existing API, if the API is extensible or 
the source is available. [Sufficient]

Technique A.4.1-3: Create a new API. [Sufficient]

Technique A.4.1-4: Expose the internal application data model of the 
content being authored through an API.

<http://www.research.ibm.com/journal/sj/443/brunet.html>


3. Test Suite

Discussion of TB's updated test suite. 
(http://lists.w3.org/Archives/Public/w3c-wai-au/2005OctDec/0047.html) 
Members thought it was a good start; now try to automate smaller 
portions of test suite incrementally for more detailed feedback by group 
members.  NIST might have testing tools, also Sakai framework has some 
testing tools to investigate..

-----------------------------------------

A new Editor's draft should be put out before the holiday break.

Received on Monday, 12 December 2005 19:35:04 UTC