Re: [Fwd: UAAG's review of WCAG 2.0 - Comments compiled]

Jan or Jim,

Did you submit these comments to the public-comments-wcag20 list?

Cathy Laws

IBM Research  Human Ability & Accessibility Center
11501 Burnet Road,  Bldg 902 Office 2C016, Austin, Texas 78758
Phone: (512) 838-4595  FAX: (512) 246-8502
E-mail: claws@us.ibm.com, Web: http://www.ibm.com/able



                                                                           
             Jan Richards                                                  
             <jan.richards@uto                                             
             ronto.ca>                                                  To 
             Sent by:                  WAI-UA list <w3c-wai-ua@w3.org>     
             w3c-wai-ua-reques                                          cc 
             t@w3.org                                                      
                                                                   Subject 
                                       [Fwd: UAAG's review of WCAG 2.0 -   
             06/21/2007 02:07          Comments compiled]                  
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





***=Comments we are going to send from UAWG.


PRINCIPLE 1: PERCEIVABLE

KF: Guideline 1.1 seems a bit watered down to me in the sense that it
sounds like the purpose of the providing of the alternative text here is
largely for conversion.  This ignores at minimum the population of folks
who for whatever reason do not use pictures but are not doing any kind
of conversion.  As written this just seems too vague to me.

PP: 1.1: The "symbols or simpler language" terms don't seem to fit into
the perceivable category. Shouldn't they be in understandable? The rest
are talking about modalities while these two talk about syntax changes
for semantic understanding.

PP: 1.1.1: Media, Test, Sensory, CAPTCHA: The segment reading "test or
exercise ... " of the first bullet above seems to be speaking directly
about CAPTCHAs. But then why is CAPTCHAs called out separately? Why not
"a test or exercise that must be presented in non-text format (e.g.
CAPTCHA)" in the first bullet?

PP: 1.1 Key Terms "non-text content ... leetspeak": Why is leetspeak
non-text content? It's parseable like any other language. It just
requires a different set of rules. This part of the example is misleading.

PP: 1.3.2: Meaningful Sequence: Again, isn't this understandable, not
perceivable? For this topic, I would take perceivable to mean *a*
sequence can be programmatically determined and navigated. The fact that
it is "meaningful" and "correct" should fall under understandable.

KF: 1.3.3 Size, Shape, Location: I don’t yet have language to suggest
but you have to read a lot of the supporting material to me to really
understand the point this guideline is trying to make.  It is too
abstract as written.

PP: 1.3.3: Size, Shape, Location: Again, why here? It says the word
"understanding" in the guideline. To fit in the perceivable section,
this guideline should speak to the shape, size, visual location, and
orientation enabling a user to *locate* components for further
understanding.

***KF: 1.4.4 Resize text: depends in large part on supporting technology
where the user agent is going to do the resizing.  If I’m new to W3C
that’s not completely clear until again I read more of the supporting
material and this might be confusing to some.


---


PRINCIPLE 2: OPERABLE

***ckl: 2.1.2 Keyboard (No Exception): It seems like something should be
said about respecting the operating system keyboard accessibility
settings (like StickyKeys, etc) as well - maybe under the How to meet
section. This is probably not a common problem in JavaScript and HTML
like it can be in software. Example: Using keys as shift keys that are
not normally used as shift keys by timing how long they are held down.

JR: Maybe should add to 2.1 something about finding out about keyboard
settings for a Web Page.

JR: 2.2.2 Blinking should go somewhere else (2.3 or 1.4)

ckl: 2.2.3 Pausing: Just moving content that is pure decoration? Include
blinking, scrolling, and auto-updating as well in the second sentence.

***KF: 2.2.5 Interruptions: I think this should be bumped up to level II.
There are enough techniques to do this for the majority of cases where
it can be a problem that don’t detract from presentation that I think it
is worth moving up.  Admittedly, AT has gotten better about handling
this but it seems like level II to me.

ckl: 2.4.3 Focus Order: I'd like to see the How to section of this
guideline contain an example of a form (like composing an email message)
in a Web page with left side and top navigation bars. If the form
controls all have tabindex values greater than zero and the navbars have
no tabindex values, will this page meet the success criteria?

***ckl: 2.4.4 Link Purpose (Context): In the definition of
"programmatically determined link context" and in the techniques for
this guideline, the term "sentence" is used, and it talks about the
screen reader providing commands to read a sentence. There is no
semantic markup for a sentence and no programmatic way for a screen
reader to determine a sentence in HTML, so don't use that term. A screen
reader should be able to handle the other techniques involving parent
element text, element attributes, and element relationships.

***ckl: 2.4.8 Also, why
is there a separate guideline for 2.4.8 Link Purpose (Link Text): The
purpose of each link can be identified from the link text. (Level AAA)
Just for different levels of compliance?

JR: Maybe "2.4.4 Link Purpose (Context)" should just apply if back
button won't work.

ckl: 2.4.5 Multiple Ways: Is content only visible content or does it
also include alternative content such as alt text, title text, etc.

ckl: 2.4.9 Section Headings: If using the title attribute of a frame and
ARIA live region properties are sufficient or advisory techniques in
addition to using the heading element, then I would reword this
guideline to use more inclusive terminology. Maybe just changing the
word "headings" to "titles" would be better.

PRINCIPLE 3: UNDERSTANDABLE

JR: Error Prevention - 3.3.3 - maybe Checking and confirming should both
be mandatory


---


PRINCIPLE 4: ROBUST

***ckl: 4.1 Maximize compatibility with current and future user agents,
including assistive technologies:
An assistive technology cannot be a user agent on its own - it requires
the browser's (or multimedia player's, etc) interpretation of the markup
and its implementation of that markup in a DOM or accessibility API. The
wording of this guideline can impact what we do in UAAG 2.0 to
distinguish the responsibilities of base user agents (browsers, players,
etc) from extensions and assistive technologies. Maybe reword this
guideline to:
Maximize compatibility with current and future base user agents as well
as extensions and assistive technologies - and work with WCAG to provide
an updated definition of user agent.

***ckl: 4.1.2 Name, Role, Value: This information is made available to the
base user agent (browser, player), which then makes the info
programmatically set and made programmatically determined (through the
DOM or accessibility APIs) for the assistive technology and user agent
extensions. I think the AT and browser extensions need to be separated
from the base user agent.

JR: The term "Robust" seems not quite right, though I can't think of a
single word that is.


---


CONFORMANCE, GLOSSARY

***JA: Accessibility Supported definition: users' assistive technology is
always listed before user agent accessibility features. I think these
should be reversed. My understanding is UA accessibility features are
enhanced by assistive technology to provide the user with a richer
experience. If the UA does not provide some functionality, AT is able to
create the functionality using information exposed by the UA in creative
ways. The AT can also create new functionality without UA support, but
this is rare. The user agent is the first layer for parsing the content.
The user agent is the mediator between the operating system,
accessibility APIs and assistive technology.

JR: For the "three levels of conformance" the rationales seem
insufficient. The key concept seems to be "impact on presentation" where
presentation is most likely visual presentation. In some cases however,
the difference actually seems to be more about technical complexity or
changes to the site a as it might otherwise have been designed. For
example:
   - Captions (Prerecorded) are level A, while Captions (Live) are level
AA, but the impact on presentation is the same.
   - Abbreviations (not impact on presentation, but definitely more work)
   - Reading Level (does not really impact the "presentation" as this
word is usually used)

***JR: Def: Mechanism: "The mechanism may be explicitly provided in the
content, or may be relied on to be provided by either the platform or by
user agents, including assistive technologies."
   - how many user agents, ATs, etc need to provide it before this is ok?
1.4.2 (Audio Turnoff) allows a "mechanism" but 1.4.4 (Resize text)
doesn't. Is this consistent enough?

JR: 9. Def: Technology:
- This is no longer linked to in the main document.
- Why is "API" in the definition? I think it interferes.