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

Hi Cathy,

This is the wording of the comments that I submitted to WCAG-GL's 
on-line comment form.

I hope that I represented everyone's views accurately.

Cheers,
Jan

--------------------

SUMMARY:
Respecting OS keyboard accessibility features

COMMENT:
Under 2.1.2 it might make sense to reference respecting the operating 
system keyboard accessibility
settings (like StickyKeys, etc).

CHANGE:
Consider referencing operating system keyboard accessibility
settings (like StickyKeys, etc)


--------------------

SUMMARY:
"Interruptions" may warrant a higher priority

COMMENT:
In 2.2.5, the Intrerruptions Success Criteria is a level AAA.

CHANGE:
Suggest Level AA.

--------------------

SUMMARY:
Defintion of "programmatically determined link context" refers to 
"sentence".

COMMENT:
There is no semantic markup for a sentence and no programmatic way for a 
screen reader to determine a sentence in HTML, so its better not to use 
that term. A screen reader should be able to handle the other techniques 
involving parent element text, element attributes, and element 
relationships.

CHANGE:
Drop requirements involving sentence parsing.

--------------------

SUMMARY:
Referencing User Agents and Assistive Technologies

COMMENT:
In "Accessibility Supported", etc. assistive technologies are often 
listed before browser accessibility features. Browser accessibility 
features are enhanced or supplemented by assistive technologies and user 
agents transfer information to the assistive technology via APIs etc.

CHANGE:
In "Accessibility Supported" and throughout suggest where they are 
mentionned specifically, list browsers ahead of assistive technologies 
and clarify that browsers pass information on to assistive technologies 
(i.e. while an assistive technology can be part of a combination of 
softwares that make up a user agent, it cannot be a user agent on its 
own, while a browser can).
We also suggest WCAG-WG and UAWG work together on these issues.

--------------------

SUMMARY:
Definition of "Mechanism" needs clarification

COMMENT:
The definition of "Mechanism" mentions user agents but without a link.

CHANGE:
Links to "user agent" and perhaps a connection with "Accessibility 
Supported".

--------------------






Catherine Laws wrote:
> 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
> Inactive hide details for Jan Richards <jan.richards@utoronto.ca>Jan 
> Richards <jan.richards@utoronto.ca>
> 
> 
>                         *Jan Richards <jan.richards@utoronto.ca>*
>                         Sent by: w3c-wai-ua-request@w3.org
> 
>                         06/21/2007 02:07 PM
> 
>  
> 
> To
>  
> WAI-UA list <w3c-wai-ua@w3.org>
> 
> cc
>  
> 
> Subject
>  
> [Fwd: UAAG's review of WCAG 2.0 - Comments compiled]
> 
>  
> 
> 
> 
> ***=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.
> 
> 
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Friday, 29 June 2007 19:49:08 UTC