RE: Comments on WAI-ARIA Best Practices

Hi Rich, thanks for the response.  Is your mouse comment in regards to my comment about the drag-drop API?  

 

As far as drawing keyboard focus, I realize that controls currently do it differently but I hoped that there could be a standard that existed.  It may be outside the scope of ARIA, maybe should be HTML 5?  My thought is that if there was a hasfocus attribute that keyed off of either aria-activedescendant or tabindex being set to the active focus element then a developer could create custom styling for the focus rectangle to be displayed.  The key is that if there was a standard attribute then assistive technologies or browsers could override the setting in their own style sheet.  That way the authors don’t always have to determine what a good focus rectangle size should be.  It also allows designers to keep their sites looking the way they want when elements become focused.  Today using specific platform APIs assistive technologies can usually receive the bounding rectangle of the element that has focus and then draw a rectangle around it.  I’m not sure if this is as easy to do from the DOM.  

 

The final point on this is that the responsibility of drawing visual focus on the element should fall on only one of the two parties.  If ATs are going to use specific techniques to draw rectangles around the focused elements then authors should not have to worry about providing a visual focus .  I don’t think we can assume the user has an AT, and the requirement for visual focus exists, so there should be a standard way for authors to expose the focus in their web application.  The ideal situation is that the hasfocus attribute or whatever it is called gets exposed through implementing keyboard support properly.  This way authors do not have to do any additional work to expose the focus rectangle if they do keyboard support correctly.

 

My two cents J

 

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Thursday, October 02, 2008 4:36 PM
To: Thomas Logan
Cc: public-pfwg-comments@w3.org; public-pfwg-comments-request@w3.org
Subject: Re: Comments on WAI-ARIA Best Practices

 


Hi Thomas, 

The editors are looking at your review. Thank you. 

Mouse interaction guidelines have not been done by the styleguide working group - Not sure we need to address those issues given WCAG says to meet accessibility compliance we need to provide keyboard support. So, I don't think we should be spending cycles on how to implement the mouse and I think mouse support does not need to be emphasized. 

I am not aware of any requirements for how to draw keyboard focus other than you must show visual focus. I think it would depend on the control. That said, I do believe we should ensure focus is clealy visible when switching to high contrast. ... but this is not limited to wai-aria. What thoughts did you have? 

Rich 


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
blog:  <http://www.ibm.com/developerworks/blogs/page/schwer> http://www.ibm.com/developerworks/blogs/page/schwer 




"Thomas Logan" <tlogan@gmail.com> 
Sent by: public-pfwg-comments-request@w3.org 

10/01/08 07:09 AM 


To

<public-pfwg-comments@w3.org> 


cc

 

Subject

Comments on WAI-ARIA Best Practices

 

  




Reviewed WAI-ARIA Best Practices August 28th 2008 Version 

 <http://www.w3.org/WAI/PF/aria-practices/> http://www.w3.org/WAI/PF/aria-practices/ 

  
1.       I believe document should start with General Steps for Building an Accessible Application followed by General Steps for Building an Accessible Widget 

  
2.       Section 2 part 2.  Under related concept should call out that the keyboard model for the control should emulate that of the related concept control assuming the related concept is fully accessible. 

  
3.       Section 2 part 2 supported states and properties.  Shouldn't the sentence read "However, in the case of a listbox, you may choose to set the property of multiselectable to true if you were to have more than one listitem in the listbox selected at a time.   This indicates to the assistive technology that the listbox manages a collection of selectable options.

4.        Section 2 part 2, I think the following text explains better that the setting of specific parameter values causes the behaviors to occur.  By setting tabindex="0" on the toolbar we have specified that the toolbar will receive focus in the document order.  By setting aria-activedescendant="button1" we have chosen to have the first button to be active when the toolbar receives focus. 
  
5.        Section 2 part2 for comparison show the toolbar being built using the tabindex properties and not using aria-activedescendant.  I have a code sample for this if needed. 
  
6.        Section 2 part 7 is confusing that the example switches from toolbar to treeitem.  Maybe the best overall sample is to do a tree because it demonstrates each of the points you want to make? 
  
7.       Section 2 part 9 setting basic accessibility properties should also include ensuring that visual focus is displayed when an element receives focus. 
  
8.       Section 2 part 10, bad sentence "There are however, situations in RIAs where all the elements in say are tree are not in the DOM at one time…" 
  
9.        Section 3, bad sentence "Provide an effective navigation experience to the user is critical for usability. " 
  
10.   Section 3.1.1 sentence says "two basic accessibility requirements" and then lists three.  I also don't think communicating associated state and property has anything to do with keyboard navigation.  Displaying the keyboard both visually and programmatically should be mentioned." 
  
11.   Section 3.1.3 Typo spelled descendant (desendant)(desdendant) 
  
12.   Section 3.1.3 Information is redundant to what is displayed in Section 3.1.3.  Suggest removing information on tabindex and activedescendant from 3.1.3 
  
13.   Section 3.1.3 suggest changing 5th bullet to read "Set tabindex="0" on the element which is the composite widget"   
  
14.   Section 3.1.4 should say "assuming none of the radio buttons are checked" 
  
15.   Section 3.1.6 doesn't seem like it belongs in section dealing with keyboard navigation. 
  
16.   Section 3.2.2 last sentence should read "Today, this technique will work in most user agents 
  
17.   Section 3.2 Providing Keyboard Focus.  Suggest reordering content.  Start with using tabindex vs. activedescendant to explain the pros and cons.  Then create specific sections for the two techniques.  

18.   Section 3.2.2.1.  First paragraph last sentence change word "position" to "positioning".   Second paragraph first sentence remove words "position the" 
  
19.   Section 3.2.2.1 rather than call out how DOJO dijit library does it why not provide the information as the best practice for all vendors to implement.  ScrollIntoView methodology should be the standardized wherever possible. 
  
20.   Section 3.3 The first paragraph says that the tooltip is required to be displayed when the element receives keyboard focus yet this does not occur when using the title attribute on images for instance.  Is this something that the browsers plan to fix? 
  
21.   Section 3.4 second paragraph remove comma from "Users, dependent on…"  Sentence also changes tense suggest "Users dependent on a keyboard navigation, have been forced to tab everywhere in the document as the only elements that can be accessed from the keyboard are form and anchor elements." 
  
22.   Section 3.4 remove "a" from "This has forced developers to make everything a link to make it a keyboard accessible" 
  
23.   Section 3.4.1 Remove first paragraph.  Its content is duplicated from the previous section. 
  
24.   Section 3.4.1 List Item 1 Change heading  to "Identify the logical structure of your page" 
  
25.   Section 3.4.1 List Item 2 Change sentence "Implementing the block structure in markup often involves wrapping elements contained with a "region" such as a <div> or <iframe> with visible borders so that each perceivable region or block area is perceivable to the user." 
  
26.   Section 3.4.1 List item 4 may want to put a link to the definitions for the roles rather than repeat them there in case any information changes in a future update. 
  
27.   Section 3.4.1 List item 4 "Assistive technologies must treat and article like a"  region "." character removed.   Also the last 3 sentences should  be removed from article description.  They are duplicates of the banner description. 
  
28.   Section 3.4.1 List item 5 first sentence remove use "If you would like to use create …"  Also this sentence should say use region for generic.  Log and status seem like they should be describing in the previous list item.  The second paragraph should say It is not essential to label these specialized regions with a header …"   Last sentence should say "Assistive technologies will should treat this role…" 
  
29.   Section 3.4.1 List Item 6 I would move earlier in the list of events.  Developer should set the application role first before doing other parts of the work.  This could be addressed by removing it from this list and covering it in a comprehensive set of steps to build an accessible application. 
  
30.   Section 3.4.2 List item 2 I think the distinction between dialog and alertdialog is dangerous because it assumes the way an assistive technology will work.  I don't know previous discussions around this issue but I would advocate for a best practice that works the same for both of them. 
  
31.   Section 3.4.4.1 says that regions require headings but log and status were two examples given that do not necessarily require a heading. 
  
32.   Section 3.4.4.2 I think it is better to describe regions vs. groups before going into the actual descriptions of each. 
  
33.   Section 3.4.4.3.1 description of ARIA role presentation should point out that elements will still be in DOM tree and that they are being removed from accessibility API tree. 
  
34.   Section 4.1.1 Last sentence should be ". For all visual objects, including (X)HTML form elements, you should may use the WAI-ARIA  <http://www.w3.org/WAI/PF/aria/#labelledby> labelledby property for labelling . "  Would be good to call out here too that some elements receive their label for embedded text content, but that is the exception.   
  
35.   Section 4.2.1 the owns relationship seems to make the most sense in this section.  References to owns attribute in Section 3 should point to this part of document. 
  
36.   Section 4.3 the aria-flowsto attribute seems confusing with respect to the tab index property.   It seems this introduces a larger chance for tabindex to be set incorrectly.  Web accessibility requirements already require that keyboard navigation be logical.  Logical is an overloaded term, but I don't think it is always interpreted as top down left right navigation (in the US at least).  Especially with diagrams that have a defined singular flow, my understanding was always that the flow should be organized in keyboard order.  I think clarification for this particular type of flow should be articulated in the document.  The multiple flow paths example is more relevant for the use cases of this attribute. 
  
37.   Section 4.3 bullet 3 change sentence to read "Use tabindex to set allow objects ..." 
  
38.   Section 5.1 bullet 1, shouldn’t this give guidance to remove the element from the DOM tree and then add the new element to the with tree with a new role set. 
  
39.   Section 5.1 last sentence needs to be fleshed out.  Also the entire Section could be renamed Managing Dynamic Changes 
  
40.   Section 5.2 3rd paragraph "The section on Live Region Properties and how to use them enumerates the details of how to apply live region properties. " 
  
41.   Section 5.2 bullet 1, should specify that it pertains to regions that are updated through client side scripting. 
  
42.   Section 5.2 bullet 3 I don't see developers making a distinction between assertive and rude.  It would be good to give a concrete example.   Instead of using bulleted list should link to 5.2.1 for more full description of the properties.  General concern that the more attribute values you put into V1 the less chance you will have on standardizing what the values mean. 
  
43.   Section 5.2 bullet 5 Need scenarios/examples of when users need to have node additions and deletions reported.  These are given in 5.2.1 but a link should be provided first time the idea is encountered.   I also think this one should include usability testing with screen reader users. 
  
44.   Section 5.2 bullet 6 I believe is very far-fetched to imagine a developer implementing correctly.  This type of tight integration seems possible in an IT/AT consulting scenario but seems like it would definitely have to have user testing.  What ATs are currently supporting this?  How can guarantee be made AT will speak notify channel messages before main channel messages? 
  
45.   Section 5.2.1 the description of the busy attribute defines what the AT should do but not the implementer.  When busy=true then the browser should still be sending each live region update but the AT should not announce them until they see busy=false?  Can you guarantee the events will be ordered correctly? 
  
46.   Section 5.2.1  the descriptions of atomic attribute should include that the value should not be set without performing user testing.  Assuming this web application will be something a user uses consistently I imagine them wanting to configure their AT to make this determination rather than the web developer. 
  
47.   Section 5.2.1 under "relevant" attribute typo "bluddylist" 
  
48.   Section 5.3 header is incorrect as it does not list timer and marquee regions 
  
49.   Section 5.3 the log description misses the case where all of the chat log is stored.  The current definition says that new information is added and old information is removed.  Log definition should indicate that new information is added all old information is maintained within the container.  I don't understand with the available attributes how an AT knows to read only the new text.   
  
50.   Section 6 should show a code example.  Also best practices should be explained for immediate form validation and validation that occurs after form submit.   
  
51.   Section 7 2nd paragraph remove word "ARIA introduces two new  <http://www.w3.org/TR/2008/WD-wai-aria-20080204/#dragdrop> Drag and Drop properties that enable web application authors to facilitate with the drag and drop process …" 
  
52.   Section 7 list item 1 should call out which roles typically support drag drop operations such as listitem, treeitem.  Also using a tri-state value for grab that includes the values true and false is a bad idea.  This would encourage developers to think of this as a Boolean property which it is not.   
  
53.   Section 7 list item 2 it is not clear from the bulleted list how the three drag operation types are expressed in ARIA markup.  Need to introduce dropeffect in this section. 
  
54.   Section 7 list item 4 needs more guidance.  Why can the AT not emulate the mouse movement commands themselves?  Having the developer code this behavior opens up the possibility for more bugs. 
  
55.   Section 7 list item 5 needs more guidance with specific key sequence commands expressed. 
  
56.   I am skeptical about the usefulness of portions the drag drop API.  If you think of the typical user using drag drop they often do not know where an item can be placed.  Usually after more experience with an application users learn how to move items around the user interface.  If familiarity with the application is assumed, specifying drag sources and drop targets could be an unnecessary burden for developers.  How does a user know that an item can be drag dropped to reorder it in a list?  Copy, move, and reference do not necessarily encompass all the actions that could occur as the result of a drag drop operation.  Instead of having these attributes why not require the list of commands to be keyboard navigable and exposed as visible text in the UI.    This feature would definitely benefit from detailed visual example to illustrate the concept.  I will incorporate  drag drop functionality into my accessible application sample I am building to help work through the end-to-end scenario. 

  

Questions: 
1.       Is W3C planning to provide keyboard/mouse interaction guidelines for all ARIA roles?   
2.       The information in 3.2.1 is generally very good.  That level of detail will definitely benefit developers.  I wonder if there is some type of standardized information that can be given about drawing keyboard focus for components.  Currently the guidance seems pretty open to interpretation. 
3.       May need more clarification added about when to use controls property versus live region updates.  If you use controls property is there a definite set of attributes you should put on the live region?