W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2008

Re: ATAG 2.0 Editors Draft

From: Michael A Squillace <masquill@us.ibm.com>
Date: Sun, 13 Jul 2008 09:19:28 -0500
To: "AUWG " <w3c-wai-au@w3.org>
Message-ID: <OF4F7164D4.48A0C8D1-ON85257485.004E990B-86257485.004EBA99@us.ibm.com>

Summary of comments for ATAG 2.0 as of editor's draft of Jul 9, 2008
[] = addition
{} = deletion
<MAS>...</MAS>  = more substantive than editorial comment

1. Introduction:
- "In order to achieve accessibility[,]"
- "ATAG 2.0 is divided into two parts, {each} reflecting {a key aspect of
accessible} [the] authoring tool{s} [itself and the content authors create
using the tool]."
- "The guidelines and success criteria in Part A are organized around the
following four principles, adapted from the four principles in WCAG 2.0:"
<MAS>Do we want to make our list parallel the order of WCAG 2.0 -
perceivable, operable, understandable, robust?</MAS>

PRINCIPLE A.1: Authoring tools must facilitate access by assistive
- "Guideline A.1.1 [For the authoring tool user interface] Ensure that
Web-based functionality is accessible."
<MAS>It's only after reading the other guidelines in A.1 that I understand
why this is a distinct guideline rather than assumed to be covered by the
others under this principle. Can we clarify the rational for why guidelines
are divided into web-based v. non-web-based ?</MAS>
- "Guideline A.1.3 [For the authoring tool user interface] Follow the
accessibility conventions of the platform."
<MAS> would like to hear more about Reed's concerns about this guideline's
rationale as it makes sense to me</MAS>
- "A.1.3.1-2 Follow and Cite Conventions"
<MAS>Is it really necessary to *site* conventions at any level? If it's a
convention, it seems to me it doesn't need to be spelled out

PRINCIPLE A.2: Authoring tool user interface must be perceivable
- under success criterion A.2.1.2 exceptions: "(a) Controls-Input: If a
non-text object is a control or accepts user input, then it has a name that
<MAS>Do we mean 'role' here rather than 'name' or do we want both?</MAS>
- under "Level A Success Criteria for Guideline A.2.2" -- "Pre[re]corded
- under success criterion A2.3.2, "...{is} [are] available via the platform
or are available in text."
- "A.2.3.7 Access to All Ed{ti}[it]able Text Presentation Being Edited
(content displays):"
<MAS>Share Reed's concerns here but not sure I even understand the
- A2.4.5 Audio Display
<MAS>Odd phrase. Do we mean 'audio output'?</MAS>

PRINCIPLE A.3: Authoring tool user interface must be operable
- A.3.1.5 "Chrome" Navigation - " Authors can use the keyboard to traverse
forwards/backwards all of the components, including those in floating
toolbars, panels, etc. using conventions of the platform (e.g., via "tab",
"shift-tab", "ctrl-tab", "ctrl-shift-tab")."
<MAS>As in A.3.1.2, do we want to include the use of non-conventional keys
if documented? This would definitely be a practice of the Eclipse platform
(eg CTRL-F7 to cycle through views). How is this criterion related to
A.3.1.8, inter-group navigation?</MAS>
- A.3.5.1 Text Search
<MAS>Given that most screen-readers have their own text search function and
that most IDEs today provide this, can we make it a level A

PRINCIPLE A.4: Authoring tool user interface must be understandable
- under success criterion A.4.2.2 On Input -- "...unless authors {has}
[have] been advised of the behavior..."
- under success criterion A.4.4.2 Document Accessibility Features --
"#part-tool-accesible"; malformed anchor?

PRINCIPLE B.1: Production of accessible content must be enabled
- "B.1.2.2 Notification Prior to Deletion"
<MAS>Is exception (a) really feasible?</MAS>

PRINCIPLE B.2: Authors must be supported in the production of accessible
- "Guideline B.2.2 Assist authors in checking for accessibility problems."
<MAS>Are we talking along the lines of compliance validation built into the
tool for manually authored or generated content (eg ACTF Web Validation
Componentry)? Also, don't understand the seemingly contradictory note at
the end of this guideline, "Note: While automated checking or more advanced
implementations of semi-automated checking may improve the authoring
experience, these are not required to meet the success criteria for this
guideline." Similar contradiction for Guideline B.2.3.</MAS>

--> Mike Squillace
IBM Human Ability and Accessibility Center
Austin, TX



             Jan Richards                                                  
             ronto.ca>                                                  To 
             Sent by:                  "w3c-wai-au@w3.org"                 
             w3c-wai-au-reques         <w3c-wai-au@w3.org>                 
             t@w3.org                                                   cc 
             07/09/2008 03:44          ATAG 2.0 Editors Draft              

Hi all,

I have put up a new Editor's draft of the ATAG 2.0 guidelines at:

In the draft I have:
1. added (and highlighted) what I feel are editorial changes from Reed's
2. added (and highlighted) changes related to harmonizing with
WCAG...the most extensive changes occurring in A.2.1 and A.2.2.
3. Noted other places where Reed had concerns that my comments back to
him might not have addressed with the label: "@@RS concerns@@"

For screen reader users...as before, the draft uses styles for change
- class="change-text"
- class="new-text"
- class="delete-text"
to denote changes. If there are other mechanisms you would like used
(e.g., more use of "@@"), please let me know.

As Jeanne had some concerns about the replacement I'm proposing for
"chrome" vs "Content Display" I did not make those changes in the draft.

Remember: Please send your issues to the list and we will note them in
the draft also.

This is likely the first of several Editor's Drafts that will be put out
prior to the F2F.

Received on Sunday, 13 July 2008 14:24:08 UTC

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