WCAG 2.0 Comment Submission

Name: lisa seeman
Email: lisa@ubaccess.com
Affiliation: UB access
Document: W2
Item Number: (none selected)
Part of Item: 
Comment Type: general comment
Comment (Including rationale for any proposed change):
These are the steps or tasks that have been identified to make script based interfaces operable.  This is taken from http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html and was well researched. Without any one of these tasks many interfaces will not be accessible.



My I suggest that we review WCAG to test if these steps are suffiently included and WACG  does  require  each task as described hear. For 

 for example 

3.1.3 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. 





Does that include all the group identification as necciasy



Anyway, hope this is useful





steps or tasks are as follows......

3.1 How To Build Applications Using Roles

This section is informative.



3.1.1 Step 1: Use your native mark up as well as you can

Use the semantic elements that are defined in the native markup language. For example, if you are using [XHTML] it is better to use the [XHTML] checkbox than to use a div element with role checkbox. Because properly used [XHTML] content is already repurposible, roles are best used when the mark up language does not support all the semantics that you need. When a role is used the semantics and behavior of the element are overridden by the role behavior.



3.1.2 Step 2: Find the right roles

Set roles to make sure elements behave predictably and that correctly describes the behavior of each element within your application (unless elements behaviors are fully described by the native markup language). Roles for interactive elements should support all the states that the element could use.



3.1.3 Step 3: Look for groups

Look for groups within a page, and mark them using the most appropriate role that best describes their usage.



For example: a region of the page that is contains a group of elements that are likely to change through an AJAX application could be tagged as a \"liveregion\".



3.1.4 Step 4: Build relationships

Look for relationships between groups and mark the using the most appropriate property or attribute.



Sometimes the relationships can be made clear via the native mark up language, such as the label tag in [<a href=\"#ref_HTML\">HTML</a>].



Sometimes this can be implied via the DOM. For example, when a well marked up list contains list items it is known that they belong to the containing list. In such cases you do not need to set additional properties to make that explicit.



In other cases use the states and adaptable properties module to state relationships. For example: if a container A contains search results, and container B contains the search controls, the mark each container as a region and set the aaa:controledby property in region B to region A.



3.1.5 Step 5: Set properties

Set properties until the behavior of the element is defined. 

Control the behavior of the element using device independent events, states, and properties. 

Extra states and properties have been provided by the States and Adaptable Properties Module. For example: If the user is required to fill in a form element set the aaa:required property to true.



An important addition in the States and Adaptable Properties Module is new extensions of TABINDEX. Now, with the TABINDEX change, the author is allowed to give any element keyboard focus (and not just form elements or anchors). In this paradigm shift, the user experience should be to use tabbing or keyboard mnemonics to move focus to widgets on the web page and then use the arrow keys to navigate the object.



Example: building a tree view in XHTML 1.0

This section is informative. 







A basic tree view allows the user to select different list items and expand and collapse embedded lists. Arrow keys are used to navigate through a tree, including left/right to collapse/expand sub trees. Double clicking with mouse also toggles expansion.



Step one: Look at your native mark up language

There is no a tree element in [XHTML] 1.0 that supports our behavior including expansion, so we will need to use roles. Therefore, our first step is setting roles.



Step two: Finding the right roles

Our tree will need roles that support embedded list behavior and expandable/collapsible embedded lists. The roles that support tree behavior for a tree are:



Tree: the main container element for our treeA form of a Select (or, generally, of a list having groups inside groups) - where sub trees can be collapsed and expanded.



Treegroup: This is a group of sibling tee items that have a common parent. Intended use is for creating groups of treeitems within a tree container.



Treeitem: An option item of a tree. This is an element within a tree which may be expanded or collapsed.



Step three and four: Look for groups and build relationships

Tree relationships can be made simply via the Dom and logical structure of your page.



A tree element will be the main container containing all other elements in the tree.



Each selectable item in the tree will be a treeitem



When a tree item contains a embedded list of tree items they will be all embedded in a treegroup. A treegroup should be contained inside the tree item that is the parent item.



Tree relationships are like list relationships in [XHTML]. A treegroup and tree elements act like list containers (OL and UL). A tree item acts like a list item (li) in [XHTML].



Because treeitems and treegroups are commonly both use div elements it is recommended to ad a comment next to closing treeitems that contain embedded tree groups



<div x2:role=\"wairole:tree\" >

 <div x2:role=\"wairole:treeitem\" >Veggies

  <div x2:role=\"wairole:treegroup\">

   <div x2:role=\"wairole:treeitem\">Green

     <div x2:role=\"wairole:treegroup\">

     <div x2:role=\"wairole:treeitem\">Asparagus</div>

     <div x2:role=\"wairole:treeitem\">Kale</div>

     <div x2:role=\"wairole:treeitem\" >Leafy

      <div x2:role=\"wairole:treegroup\">

       <div x2:role=\"wairole:treeitem\">Lettuce</div>

       <div x2:role=\"wairole:treeitem\">Kale</div>

       <div x2:role=\"wairole:treeitem\">Spinach</div>

       <div x2:role=\"wairole:treeitem\">Chard</div>

      </div>

     </div> ---close leafy

     <div x2:role=\"wairole:treeitem\">Green beans</div>

    </div>

   </div> ---close green

  <div x2:role=\"wairole:treeitem\">Legumes</div>

  <div x2:role=\"wairole:treeitem\" >Yellow

   <div x2:role=\"wairole:treegroup\">

    <div x2:role=\"wairole:treeitem\">Bell peppers</div>

    <div x2:role=\"wairole:treeitem\">Squash</div>

   </div>

  </div> ---close yellow

 </div>

</div> ---close veggies

 

</div> ---close tree

Sometimes a tree structure is not explicit via the Dom and logical structure of a page. In such cases the relationships must still be made explicit using the properties module.



Example:



<div x2:role=\"wairole:treeitem\" aaa:haschild=yellowtreegroup”>Yellow<div>

..

<div id=\"yellowtreegroup\" x2:role=\"wairole:treegroup\">

<div x2:role=\"wairole:treeitem\">Bell peppers</div>

<div x2:role=\"wairole:treeitem\">Squash</div>

</div>

Although this is allowed it may affect performance



Step 5: Use properties

Control the behavior of the element using Events and states,



For example, use the aaa name space with supporting scripts to control what tree elements are expanded



<div tabindex=\"-1\" x2:role=\"wairole:treeitem\" aaa:expanded=\"true\">Yellow</div>

And use events to device independent events with supporting javascripts to handle user interaction.



<div x2:role=\"wairole:tree\" tabindex=\"-1\"

onfocus=\"return treeItemFocus(event);\"

onclick=\"return treeItemEvent(event);\"

ondblclick=\"return treeItemEvent(event);\"

onkeydown=\"return treeItemEvent(event);\"

onkeypress=\"return treeItemEvent(event);\">

Then create javascript support to control the event driven behavior or the application.





Proposed Change:

Received on Wednesday, 21 June 2006 15:53:06 UTC