- From: Jeanne Spellman <jeanne@w3.org>
- Date: Mon, 14 Jul 2008 15:10:04 -0400
- To: AUWG <w3c-wai-au@w3.org>
Still going through Michael's and Reed's comments, but I wanted to at
least get my first pass of comments on Part A out to the group.
There are a lot so I put them on a web page, Comments on Editors Draft
of 9 Jul 2008 <http://www.w3.org/WAI/AU/2008/IssuesED20080714>. If it
makes sense to others, I could take Reeds and Michael's comments and add
them there, too. Jan, if there is a listing that you would like to see
them in, let me know and I'll move it all there.
The text follows for those who prefer to read them that way.
It took much longer than I expected, so I don't have comments for Part B
yet.
jeanne
Comments on ATAG Editors Draft of 9 Jul 2008
7/14/08
Introduction:
Organization
Definition of Authoring tool is normative, but it doesn't say where the
normative section ends. If the organization part is normative, them we
need to make sure the “must” and “should” in the Organization section
conforms to the RFC of Keywords.
Success Criteria
1.
Use of “[Sufficient]” and “[Advisory]”: Why both “” AND [] ? If
there is something significant about it, it isn't clear what it
means.
2.
Success Criteria Level General: I don't like defining the level of
support for Accessibility by talking about the restrictions on the
tool. I don't think it is correct (Universal Design) and could
easily become a detriment to marketing a product rather than an
asset. (Most accessible=most limited.) I recommend that we stick
with the WCAG Level guidelines and define it in terms of the
barriers to use.
3.
A Part A. “Thus people with the widest range of disabilities using
a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are
able to access tools in different ways” It would seem to me that
the “widest range” would apply to AAA, not A.
4.
Success Criteria Level AA – Part A. Isn't clear. I couldn't figure
out what made something AA instead of A or AAA.
Relationship to WCAG
Last sentence in first paragraph is missing words, or doesn't make
sense. “...to mean for the particular Web content technologies
<http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-Web-Content-Technology>
that an authoring tool produces and is implemented using (if applicable).“
Part A
Guideline A.1 – Facilitate access by AT
1.
I think it would be more clear if A.1 were moved to the end of
Part A, as the last Guideline instead of the first. Then all the
other things would already be covered, and this is sweeping up the
last of the functionality by saying that all functionality is
implemented in the Accessibility API. It duplicates much of A.2.3
which adds to the confusion.
2.
“User Interface “Chrome””. Same problem as UAAG. We need to pick
terms and be consistent with them. If we use chrome, don't put it
in quotes. Define it and make it a term. User Interface Chrome is
redundant.
3.
If we are going to put “*(user interface "chrome"
<http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Chrome>,
content display
<http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Content-Display>)*“
with each SC, then let's clarify it, e.g. “Applies to user
interface” or “Applies to content display” or “Applies to both
user interface and to content display.”
4.
Guideline A.1.2 should be the parallel of A.1.1: Ensure that
non-web based functionality is implemented using the accessibility
architecture appropriate to the platform.
5.
All titles in A.1.2 need editorial work.
6.
All the SC for A.1.2 need to be focused on the Accessibility
Architecture. The word “platform” should be reserved for the “OS”.
7.
A.1.2.1 Don't understand: “or leverage existing implementations of
the architecture.” Recommend we reserve “architecture” for
“accessibility architecture”. Or find a better word for
Accessibility APIs (which I know is Windows-centric).
8.
I think A.1.2.2 is level AA and A.1.2.3 is level A, but it would
help if they were explained more clearly.
9.
A.1.3: Why should they cite conventions? How does that improve
accessibility?
10.
A.1.3.2: What is Keyboard Configuration? Is that Keyboards
shortcuts, or is that a standard keyboard, vs. Enhanced vs. Dvorak?
Guideline A.2 – Perceivable
1.
Switch order of SC A.2.1.1 and A.2.1.2.
2.
SC A.2.1.1 (existing #) should focus on the view mode rather than
on the content. For example “An Editing view that renders non-text
objects also has a view or option where the text-equivalent of the
object is displayed and is available to accessibility
architecture. (or whatever word we standardize on)”
3.
SC A.2.1.2 (a) should reference A.2.3.1 or we should merge the two.
4.
SC A.2.1.2 (b) Can we help Time-Based Media with an in-line
explanation as well as a link to the definition? It's the first
time the term is used, and it isn't explained. I suggest “
Time-Based Media (Audio-Video)”. I like the referral to A.2.2.
5.
A.2.2 Success Criteria needs numbering.
6.
A.2.2.5(?) Time-based content renderings doesn't seem to belong here.
7.
We need to clarify when an audio description is needed and when
captioning is needed. This whole section seems unclear.
8.
SC A.2.3.1 seems to be more applicable to A.1.
9.
Need consistent use of “platform”. Recommend that “platform” be
used when we are discussing the OS/Hardware and a different term
when referring to the A11y APIs.
10.
SC A.2.3.3 needs a better title. Suggest: Alternate Presentation
of Modified Content.
11.
SC A.2.3.4 needs a better title. Access to Text Styling Properties
12.
*SC A.2.3.5 needs clarification: Suggest: Meaningful Sequence:*
When the sequence in which user interface components
<http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Component>
are presented affect their meaning, the semantic equivalent of
that sequence is available via the accessibility architecture.
13.
SC A.2.3.7 has a typo “edtiable”
14.
SC A.2.3.7 belongs in Part B or in A.1 – I don't see why it is here.
Guideline A.3 – Operable
1.
SC A.3.1.1 Keyboard. Add the line from UAAG, “this does not forbid
and should not discourage providing mouse input or other input
methods in addition to keyboard operation.”
2.
SC A.3.1.6 should be Level A.
3.
G A.3.1 Remove Note #2 as it is now part of A.3.1.1. Are Notes
normative?
4.
SC A.3.2.1 Suggest: Data Saved. If the authoring tool ends an
authoring session due to a time limit, then the user is given an
interrupting warning and given an option to save the data. If the
user doesn't act on the warning within several minutes, then the
data can be expired.
5.
SC A.3.6.1 overlaps with A.2. Needs some work to separate and
discriminate between them.
6.
Recommend adding a new AC for Level AAA. “Customized sets of
keyboard shortcuts [or whatever word we decide to use] can be
imported and exported.”
Guideline A.4 – Understandable
1.
Merge A.4.1 and A.4.4. Take the SC for Guideline A.4.4 and make
them the Level A SC for Guideline A.4.1. Broaden the rationale to
include Documentation.
2.
A.4.2.1 also belongs in Operable Keyboard (A.3.1)
3.
A.4.3.3 Error is passed in text and available to accessibility
architecture.
4.
Guideline A.4.3 broaden beyond text. Suggest: Note 2. It is
acceptable to group like actions (e.g typed words, a series of
backspaces, a series of right-arrow for positioning) ....
Received on Monday, 14 July 2008 19:10:53 UTC