Template for comments on WCAG 2.0 Last Call Draft and Support Documents

Commenter: Lisa seeman

Email: lisa@ubaccess.com

Affiliation: Invited expert at W3C, UB access

Date: May 17 2006

Directions

Please ensure that the comments submitted are as complete and "resolvable" as possible. Thank you.

1.
Document Abbv. (W2/UW/TD)

2.
Item Number (e.g. 1.1)

 3.
Part of Item (Heading)		 4.
Comment Type (G/T/E/Q)		 5.
Comment
(Including rationale for any proposed change)		 6.
Proposed Change (Be specific)
 W2  

2

    T  Interfaces become inoperable when one of the following brake:
  1. Each element or widget is marked with full and corrected semantics that fully describes it's behavior  Note this is more then information and  structure can be separated from presentation .This includes creating enabled  javascripted widgets that the Assistive Technology does not know what it is, what states are supported and how it maps to the operating system API. If non exists (like a tree item that can expand to a sub tree when you click on it) Then you may need to add a technology, such as xforms, XHTML 2 Roles
  2. The relationships between elements and groups are known. Again, this is more then I see supported by navigation Success criteria. What form element controls what AJAX operated section  is a good example of a relationship
  3. States, properties, and relationships are valid for each elements behavior and are accessible via the DOM. For example if clicking on a tree item makes it expand  or collapses, then it's state (such as expanded) needs to be accessible via the  Document Object module Via an attribute that can be understood by assistive technology..
  4. There is an element having the correct input focus. This is different to just being keyboard navigatable

  Add success criteria at level 1 along the lines of:

1, The supported behavior of each element and widget can be programaticaly determined

2, The relationships between elements and groups of elements can be  programaticaly determined .

3, States, properties, and relationships are valid for each elements behavior can be programaticaly determined .

4,There is consistently an  element having the correct input focus.
 W2  2.4.3  

Level 2 Success Criteria for Guideline 2.4

  T  Web units have titles, what is the advantage if the titles are not descriptive?
 change to  Web units have descriptive  titles
 W2    

Level 3 Success Criteria for Guideline 2.4

  T  surely this only helps if titles are unique  -any objection to unique should not apply at level 3
  change to  Web units have descriptive and  unique t titles
 W2  2.4    T  sections of content need titles to be able to navigate through a page.
This is particularly true of many AJAX sites that  have multiple regions. The regions of a page can change at different  rates due to either user actions or asyncrones updates. The user may need to toggle between form controls to results, and updates .

Even in simpler content  knowing that a table has a navigation function is hugely usefully even when accessibility is not completely broken.
  Add level one success criteria
Blocks of content that become updated should be uniquely titled or it's role can  be programaticaly determined

When multiple blocks of content in a web unit have the same role they should be uniquely titles

Blocks of content that perform a common task should be titles or its role can  be programaticaly determined

success criteria  2.4.1 is no longer needed
 W2  2.4.6  

Level 3 Success Criteria for Guideline 2.4

  T   2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. [How to meet 2.4.6]

this should be level 1 as it often completely brakes the user interface
  move SC 2.4.6 to level 1
 W2  2.5.1  

Level 1 Success Criteria for Guideline 2.5

  T  In the roles specification we now have a range widget, which means you can state, in a programaticaly determined way what the max and min values are.

That means that AT can give users the message any way they want - including text, if they want. Surly this is better then requiring text

we also have in the adaptable states and properties module a required  attribute,
(for situation B in the "how to understand this checkpoint)

Note this is all part of the WAI, and  screen readers are working to support it today...
  change 2.5.1 to:  If an input error is detected, the nature of the error  can be programaticaly determined or  identified and described to the user in text.


 W2  2.5.2  

Level 2 Success Criteria for Guideline 2.5

  T   2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user.

With things like role attribute you can assign a functional role to an element, and other important information such as allowable range .  That means that the assistive technology can themselves perform validation.
Makes it all a user agent thing...


   2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user or can be progmaticly determined
 W2  2.5.3  

Level 2 Success Criteria for Guideline 2.5

  T  With things like role attribute you can assign a functional role to an element, and other important information such as allowable range .  That means that the assistive technology can themselves perform validation. We should also work on identifying critical tasks.

Hence one of the list should be  (for future proofing)
the role of all information and it's critical nature can be progmaticly determined		  

  1. Actions are reversible.

  2. Actions are checked for input errors before going on to the next step in the process.

  3. The user is able to review and confirm or correct information before submitting it.

  4. The role of each control  and it's critical nature can be progmaticly determined
 W2  2.5.4  

Level 3 Success Criteria for Guideline 2.5

  T   With things like role attribute and concept mapping with RDF you can assign a functional role to an element,  That means that the assistive technology can themselves provide the correct  help that is tailored to the user.
the user experience is better because the help is tailored to their scenario
   2.5.4 Context-sensitive help is available for text input.or he role of each control  can be progmaticly determined
 W2  2.    T   Most of this (at least at the higher levels)  helps blind folks access error information. That is good. Clearly what is missing hear is a game plan for helping people with a learning disability , who have trouble filling in forms.

Forms are real nightmears for a lot of us. In fact I often do not deposit checks and perform other tasks because of the barrier that form filling presents.

Things that make it  harder include short labels that do not explain what  they are, coping numbers, Non expandable, small fonts. Too much information on one  page. Information not being well grouped such as user information, payment information. Then with the short labels I get confused what is what.   Server time outs. Asking a lot of information  to make forms simpler to process but make form filling much harder and more complex .

For example  on this form on line it is much simpler (but PF preferred this table .. oh well) .... the options could be in a combo box as filled out meaningfully text...

  Perform user testing with different groups of people with learning disabilities and cognitive limitations - including age related.

Identify what technques help

Add them