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
<http://www.w3.org/WAI/PF/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 <http://www.w3.org/TR/2008/WD-wai-aria-20080204/#dragdrop>  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?