WCAG 2.0 review - Operable and Robust

2 Operable
2.1 Make all functionality available from a keyboard

2.1.2 Keyboard (No Exception): All functionality of the content is operable
through a keyboard interface without requiring specific timings for
individual keystrokes. (Level AAA) How to meet 2.1.2.
ckl: 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.

2.2 Provide users with disabilities enough time to read and use content

2.2.3 Pausing: Moving, blinking, scrolling, or auto-updating information
can be paused by the user unless it is part of an activity where timing or
movement is essential. Moving content that is pure decoration can be
stopped by the user.
ckl: Just moving content that is pure decoration? Include blinking,
scrolling, and auto-updating as well in the second sentence.

2.3 Do not create content that is known to cause seizures
2.4 Provide ways to help users with disabilities navigate, find content and
determine where they are

2.4.3 Focus Order: If a Web page: can be navigated sequentially, focusable
components receive focus in an order that follows information and
relationships conveyed through presentation.
ckl: 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?

2.4.4 Link Purpose (Context): The purpose of each link can be determined
from the link text and its programmatically determined link context (Level
A)
. 1.  G53: Identifying the purpose of a link using link text combined with
the text of the enclosing sentence
programmatically determined link context additional information that can be
programmatically determined from relationships with a link, combined with
the link text, and presented to users in different modalities
Example 1: In HTML, information that is programmatically determinable from
a link in English includes text that is in the same sentence, paragraph,
list, or table cell as the link or in a table header cell that is
associated with the table cell that contains the link.
Example 2: A screen reader provides commands to read the current sentence
when focus is on a link in that sentence.

ckl: 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: 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?

2.4.5 Multiple Ways: More than one way is available to locate content
within a set of Web pages where content is not the result of, or a step in,
a process.
one technique: Providing a search engine to help users find content (future
link)
ckl: Is content only visible content or does it also include alternative
content such as alt text, title text, etc.

2.4.9 Section Headings: Where content is organized into sections, the
sections are indicated with headings.
ckl: 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.

4 Robust:
4.1 Maximize compatibility with current and future user agents, including
assistive technologies
ckl: 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.

4.1.2 Name, Role, Value: For all user interface components, the name and
role can be programmatically determined; states, properties, and values
that can be set by the user can be programmatically determined and
programmatically set; and notification of changes to these items is
available to user agents, including assistive technologies.
ckl: 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.

Cathy Laws

Manager - IBM Software Group (SWG) Accessibility Architecture and
Development
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

Faith is being sure of what we hope for and certain of what we do not see.