UAAG's review of WCAG 2.0 - Comments compiled

This is where we are so far on compiling UAAG comments on WCAG 2.0.

Cheers,
Jan




GENERAL COMMENTS

KF: Reading through all these guidelines I’m struck with the general 
impression that assistive technology is given a higher priority than 
user agents.  This is perhaps somewhat subtle but I guess my point, 
similar to what I now see Jim said, is that by and large the AT gets the 
majority of what it presents from the user agent and I’m not sure the 
guidelines represent this as well as they could.

DP: I'd say provide conditional content for all content.


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. 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.

Received on Tuesday, 19 June 2007 19:39:55 UTC