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




"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/

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