- From: Michael A Squillace <masquill@us.ibm.com>
- Date: Sun, 13 Jul 2008 09:19:28 -0500
- To: "AUWG " <w3c-wai-au@w3.org>
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
technologies
- "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
explicitly.</MAS>
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
describes..."
<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
video-only"
- 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
criterion.</MAS>
- 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
criterion?</MAS>
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
content
- "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
W:512.823.7423
M:512.970.0066
masquill@us.ibm.com
www.ibm.com/able
Jan Richards
<jan.richards@uto
ronto.ca> To
Sent by: "w3c-wai-au@w3.org"
w3c-wai-au-reques <w3c-wai-au@w3.org>
t@w3.org cc
Subject
07/09/2008 03:44 ATAG 2.0 Editors Draft
PM
Hi all,
I have put up a new Editor's draft of the ATAG 2.0 guidelines at:
http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html
In the draft I have:
1. added (and highlighted) what I feel are editorial changes from Reed's
comments
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
tracking:
- 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.
Cheers,
Jan
Received on Sunday, 13 July 2008 14:24:08 UTC