General Thoughts
================
My overall concerns with the current state of the ARIA Best Practices
document is that it contains a lot of examples and recommended solutions that
are actually not considered industry best practices for web development and
web accessibility. Consider the toolbar example that is presented in the
section titled "General Steps for Building an Accessible Widget with ARIA".
This example has the following problems:
1. Poor Use of Semantic Markup
Using the elements as the basis for
the toolbar's buttons? If it did it would better illustrate how ARIA
can be used to supplement for native language semantics. It would also
make for a toolbar that is more accessible in older browsers
(e.g. IE 6 & 7) that don't support ARIA. This is especially important
considering right now the browsers that don't support ARIA outnumber
those that do.
2. Use of inline JavaScript event handlers
This has long been considered to be a bad practice, and I was surprised to
see this technique appear so often in the ARIA Best Practices Document.
3. ARIA roles and tabIndex are applied inline rather than being managed
via JavaScript
Since ARIA-enabled widgets *require* JavaScript for keyboard support and
state management, I think that it only makes sense that ARIA roles, states,
and properties for widgets should only be applied using script. The same
goes for the tabIndex attribute. I'd like to see this mentioned in the
ARIA Best Practices document and applied to the examples.
I think that the examples in the ARIA Best Practices document should
represent us putting our best foot forward--showcasing a culmination of
best practices for accessibility made even better with the introduction of ARIA.
Instead the document leads with example that represents a bunch of really bad
practices. But I don't want to criticize and offer no solutions, so if you are
looking for developers to volunteer examples the ARIA Best Practices Document I
would be happy to volunteer.
Feedback on Specific Sections
=============================
From the section titled "General Steps for Building an Accessible Widget
with ARIA":
- Point 2: "From the role, get the list of supported states and properties":
- There's a sentence in this section that is slightly misleading. It
reads: "By setting tabindex="-1" on the toolbar, we have specified that
the toolbar will receive focus in the document order" This could be
confusing to developers since setting the "tabIndex" attribute to -1
removes an element from the browser's default tab flow.
- Point 7: "Synchronize the visual UI with accessibility states and properties
for supporting user agents"
- I like the mentioning of IE 6's lack of attribute selector support. I
don't like the time spent suggesting fixes to IE 7's broken attribute
selector support. I think that this section would be more useful if it
simply made it known that currently not all of the major browsers have
support for CSS attribute selectors, and provided an example of how to
engineer a solution for styling state that worked consistently well
across all browsers. In this case that means avoiding use of attribute
selectors for styling updates to a widget's state, and instead, applying
class names that represent, and can be used to style state.
- Point 11: "Review widget to ensure that you have not hard coded sizes"
- I like how this section tells the user to avoid "px" as the unit for
defining font sizes. I don't like the suggestion of using the "em" unit
to replace "px" as we've (Yahoo!) found "em" doesn't scale as nicely in
IE 6 and 7. We've done a lot of research on fonts at Yahoo! and believe
that using percentages scales the most consistently cross browser. Our
best thinking on this can be found here:
http://developer.yahoo.com/yui/fonts/
From Section 3.2.1 "Using Tabindex to Manage Focus among Widgets"
+ Item 1: "Use onfocus to track the current focus"
- I think that when it comes to listening to focus in the browser, the
ARIA Best Practices document should reference PPK's focus delegation
technique:
http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html
We've rolled this technique into YUI and it has been both incredibly
useful and helped us improve the performance of our widgets. Read the
following blog entry for more info:
http://yuiblog.com/blog/2008/10/07/onfocus-onblur/
+ Item 2: "Refresh an elements style using onfocus()"
- I would consider removing this item since it is mostly repeating points
that are mentioned in item 8 titled "Always draw the focus for
tabindex="-1" items and elements that receive focus programmatically"
+ Item 5: "Dynamically change focusability using the tabIndex property"
- I would go so far as to recommend always updating the "tabIndex"
property to 0 (or greater) before focusing an element. This provides
two benefits:
1) You completely avoid the problem in IE where the default browser
focus outline isn't drawn when an element is focused
programmatically. This ensures the browser's default rendering of
focus, which is beneficial considering that it is already familiar
to the user.
2) If the currently focused descendant of a UI control has a tabIndex
of 0 it allows the user to press shift+tab to move back
to where they were if they exit a control and want to go back.
+ Item 6: "Use setTimeout with element.focus() to set focus"
- Is use of "setTimeout" really necessary? If so, can you more accurately
describe the problem? The current description of the problem seems
really vague: "The timeout is necessary in both IE and Firefox 1.5, to
prevent scripts from doing strange unexpected things as the user clicks
on buttons and other controls."
- I would avoid mentioning Firefox 1.5 since it doesn't have enough
market share at this point to be of enough significance. And it makes
the advice seemed dated.
- If use of "setTimeout" fixes larger usability problems in IE, then call
those out as I think it will give this solution more credibility.
+ Item 7: "Don't use :focus or attribute selectors to style the focus"
- This is an important piece of advice, considering IE's limited support
of the :focus pseudo class and lack of attributor selector support in
IE 6. That said, the suggested example solution of styling focus via
an inline style is a bad one. I'd like to see the recommended solution
be: Style focus by using a "focus" event handler to apply a class to the
focused element. That way you can centrally manage how focus is styled.
+ For item 8: "Always draw the focus tabIndex='-1'"
- I would remove this item as it seems to suggest a solution to a
problem that, as I suggest above, can be avoided entirely if developers
simply update the tabIndex property to 0 before programatically
focusing an element.
- I would replace this item/section with a new one that focuses on the
importance of developers providing a clear, consistent rendering of
focus through:
1) Relying on the browser's default rendering of focus--something the
user is already familiar with.
2) If developers are going to customize how focus is rendered, it is
important that focus is rendered consistently across all focusable
elements within the scope of the site/application so that the user
only has to learn one focus model.
+ Item 9: "Prevent used key events from performing browser functions"
- Update example so that it doesn't use an inline event handler
- For Opera 9 and Firefox 2: calling the "preventDefault" method in
response to the "keydown" won't prevent undesired scrolling. To fix the
problem in Opera 9 and Firefox 2, you also need to call
"preventDefault" in response to the "keypress" event.
+ Item 10: "Use key event handlers to enable activation of the element"
- If you are interested in providing more detail on this point, this
technique is necessary in IE, Firefox and Webkit when you use the
"tabIndex" attribute to make an element that is not natively
focusable, focusable.
- Opera is the only browser that fires the "click" event when the user
presses enter while focused on an element that was made focusable via
the use of the "tabIndex" property.
Section 3.2.6.1. "Steps for Defining a Logical Navigational Structure"
Point 4: "Assign landmark roles to each region"
- I think that the following needs a better explanation: "Skip to main
content links impact the layout of applications and only address one
main content area." How does a skip navigation link negatively
impact the layout of a page, especially if it is hidden offscreen
using CSS?
Point 6: "For landmarks unsuited to specialized region ARIA roles"
- Why doesn't the example show use of the generic "region" role, as
mentioned in the preceding paragraph?
Section 3.2.6.2. "Structural Roles that Facilitate Navigation with
Assistive Technologies"
Point 1: "After you have divided your Web page into regions through the use
of role landmarks and custom regions, you must make a decision: Is your Web
page an application or not?"
- This seems like an unnecessary designation to force developers to make
as the web is full of examples of pages that are hybrids between
documents and applications. The Yahoo! homepage and Facebook are
two good examples of pages that don't fit perfectly into the designation
of application or document.
Point 2: "Dialogs and alert dialogs - special case application roles
WAI-ARIA provides dialog and alertdialog roles that are to be treated as
special case application roles. Like application, screen readers will leave
the main job of keyboard navigation up the application"
- I think all ARIA-enabled widgets should work like this. The screen
reader should be able to keep the virtual buffer on by default, and
should toggle it off on the fly if the user focuses into a widget.
Section 3.2.6.3.1 "Header Levels Versus Nesting Levels"
- Can we just omit or deprecate any ARIA roles (such as heading) that
directly duplicate elements already available in HTML?
Section 3.2.6.4.2 "Groups and Their Applicability"
- I love the idea of groups, and I think that the concept should be applicable
as a means of semantically organizing any of a widget's descendants. If
this were the case, it would eliminate the need for the "separator" role
and help simplify the spec.
Section 3.2.6.5.2 "Marking Descriptive Sections"
- I don't understand the use case for the example. Why wouldn't you just
use alt text?
Section 4.1.2 "Describing"
- This section contains a really horrible example:
X
Why would anyone ever code a button like this? I would be up for helping
to provide better examples of using aria-describedby.