Notes from McLean VA F2F

Meeting Notes from AUWG F2F in McLean VA, USA (Sept 21-23 2005)

Day 1: Wednesday (PM only), Sept 21, 2005

Attendees: Jan Richards (Acting Chair), Greg Pisocky, Barry Feigenbaum, 
Tim Boland

Went through JR's "Edits for Part A" email:
http://lists.w3.org/Archives/Public/w3c-wai-au/2005JulSep/0077.html

All points were eventually accepted except the first, covering the WCAG 
requirement on Web-based components. The decision was made to keep this 
checkpoint and eight, breaking up the success criteria for "A.1.4 Allow 
the display preferences for the editing view to be changed without 
affecting the document markup. [Priority 1]. "


------------------------
Day 2: Thursday, Sept 21, 2005

Attendees: Jan Richards, Greg Pisocky, Barry Feigenbaum, Tim Boland, 
Jutta Treviranus (Chair), Liddy Nevile, Bob Regan

Began at the top of Part A and went all the way down...

New success criteria for A.1.3. TB concerned about testability, but 
tying to platform does provide a benchmark.

- If the visual display (fonts, sizes, colors, spacing, positioning, 
etc.) is controlled by the authoring tool rather than by the platform, 
then the authoring tool must provide at least the same configurable 
properties with at least the same configuration ranges as the platform.
- If the audio display (volume, speech voices, etc.) is controlled by 
the authoring tool rather than by the platform, then the authoring tool 
must provide at least the same configurable properties with at least the 
same configuration ranges as the platform.

A.2.2 was built as a P3 checkpoint for UI configurability:

A.2.2 Ensure user configurable access to selectable actions. [Priority 3]
Rationale: Authors who have limited mobility require quick access to the 
actions that they use frequently.

Techniques: Implementation Techniques for Checkpoint A.2.1

Success Criteria:

- There must be an option to add and modify key-plus-modifier-key (or 
single-key) access to all selectable actions.
- There must be an option to customize the items (from the set of all 
selectable actions) and their order within at least one area of the user 
interface that is controllable by a single selection (e.g. button bar, 
pallette, panel, etc).

There was discussion about "A.2.5 Ensure that editing views enable the 
author to navigate the structure and perform structure-based edits. 
[Priority 2] " about how to handle poor hierarchies and graphs...this 
led to rephrasing of the success criteria away from hierarchies to:

- In any structured element set, the author must always be able to move 
the editing focus from any element to any other element with the 
following relationship (if they exist): the element immediately above 
(i.e. parent), the first element immediately below (i.e. child), the 
element immediately preceding at the same level (i.e. previous sibling), 
and the element immediately following at the same level (i.e. next 
sibling).
- In any structured element set, the author must always be able to 
select content and perform editing functions on any element along with 
any content, including sub-elements.

A.2.7 The Undo requirement was expanded:

- Actions that modify content must be either reversible with an undo 
function or include a warning to the author that the action is 
irreversible.
- The author must be able to perform multiple undos.
- The author must be able to undo any series of undos

The configuration settings checkpoint was reworked as a P2 the requires 
the ability to save settings and provide multiple sets of settings:

A.2.8 Provide personalized configuration. [Priority 2]

Success Criteria:

- The authoring tool must provide the ability to save and reload all 
configuration settings related to visual or auditory output and keyboard 
operability.
- The author must be able to select, within the application, from 
multiple configuration sets.

The previously hotly debated preview accessibility requirement was 
settled with a rewording of the success criteria to include a clause for 
tools with "generic" previews that do not claim to emulate any 
particular browser:

- If a preview is provided, then:
(a) The author must be able to choose an external browser to perform the 
preview
(b) or, the preview must provide the same accessibility features as a 
target browser (which must be identified in the conformance profile) 
that is being emulated and the following must be true:
Any authoring tool user interface other than the content being previewed 
must meet the other requirements of Part A of ATAG 2.0.
A means of exiting the preview must be provided that meet the other 
requirements of Part A of ATAG 2.0.
(c) or, the preview does not claim to emulate a specific browser, in 
which case it must meet the other Part A requirements of ATAG 2.0 (i.e. 
Note 1 does not apply).

Success criteria were provided for A.3.1 Observe the accessibility 
conventions of the platform. [Priority 2]

- Focus and selection conventions for the current platform (specified in 
the conformance profile) must be followed.
- Keyboard accessibility configuration conventions (e.g. default 
accelerator key bindings) for the current platform (specified in the 
conformance profile) must be followed.@@

Success criteria were provided for A.3.2 Maintain consistency within the 
authoring tool user interface. [Priority 2]
- User interface controls with the same text label or icon must perform 
the same function.
- Any text label or icon must not have more than one function.
- When the same function (e.g. saving, running a checker or canceling an 
action) is available in multiple areas of an authoring tool user 
interface, at least one method of controlling the function must be 
implemented for each area using identical user interface elements.

Success criteria were reworked for A.3.3 Document the authoring 
interface including all interface accessibility features. [Priority 1]
- At least one version of the documentation must conform to WCAG 
(whether delivered on the Web, CD-ROM, etc.).
- All features that benefit the accessibility of the authoring interface 
must be documented in the help system (e.g., keyboard shortcuts).
- The current configuration of selectable actions must be displayed in 
either a centralized fashion (e.g., a list of keyboard shortcuts) or a 
distributed fashion (e.g., by listing keyboard shortcuts in the user 
interface menus).

------------------------
Day 3: Friday, Sept 21, 2005

Attendees: Jan Richards, Barry Feigenbaum, Tim Boland, Jutta 
Treviranus(Chair), Liddy Nevile, Bob Regan (AM only)

Began by going top to bottom through Part B but discussion centered on 
the checkpoints B.2.2 and B.2.3 regarding checking and repair.

CHECKING:

The group decided to extend checking beyond simply telling users how to 
check a full document (old def of manual checking) to specifying that 
checking down to the level of element (when problems are related to 
single elements) and that potential problem instances need to be 
identified individually to the user (e.g. by moving focus or providing 
line numbers etc.)

Adopted success criteria:

- An individual check must be associated with each requirement in the 
content type benchmark document (i.e. not blanket statments such as 
"does the content meet all the requirements").
- For checks that are associated with a type of element (e.g. img), each 
element instance must be individually identified as potential 
accessibility problems. For checks that are relevant across multiple 
elements (e.g. consistent navigation, etc.) or apply to most or all 
elements (e.g. background color contrast, reading level, etc.), the 
entire span of elements must be identified as potential accessibility 
problems, up to the entire content if applicable.
- If the authoring tool relies on author judgement to determine if a 
potential accessibility problem is correctly identified, then the 
message to the author must be tailored to that potential accessibility 
problem (i.e. to that requirement in the context of that element or span 
of elements).
- The authoring tool must present checking as an option to the author at 
or before the completion of authoring.


REPAIR:

BR: authoring tools should not be forced into the ER market by the 
guidelines.

JR: a very basic repair functionality can be at the level of instructions.

Adopted success criteria allow instructions as a minimum but don't 
require them if an automated repair is provided:
- For each potential accessibility problem identified by the checking 
function (required in Checkpoint B.2.2) provide, to the author, repair 
instructions that are specific to the accessibility problem, or
- For each potential accessibility problem identified by the checking 
function (required in Checkpoint B.2.2) provide an automated or 
semi-automated repair mechanism.

We continued with a review of Part B...

Success criteria were reworked for B.3.4 Ensure that accessibility 
prompting, checking, repair functions and documentation are 
configurable. [Priority 3]
The configurability of all functions related to accessibility prompting, 
checking, repair, and documentation must at least match the 
configurability of other prompting, checking, repair, and documentation 
functions of the tool (respectively), in terms of both of the following:
(a) the range of options controllable by the author, and
(b) the degree to which each option can be controlled


The group intends to put out a public draft ASAP.

F2F meeting possibilities were discussed for early December and early 
January. A possible meeting at the W3C plenary in France in march was 
also discussed, though several people likely would ave difficulty making 
this meeting.

The draft at the end of the day looked like this:
http://lists.w3.org/Archives/Public/w3c-wai-au/2005JulSep/att-0079/guidelines_end_of_sept_23_.html


Draft priorities were set on all unprioritized checkpoints within Part A 
with unanimous agreement.

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

If there are any errors or omissions please let me know.

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

Cheers,
Jan

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Friday, 30 September 2005 20:25:49 UTC