WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA best practices and priorities

for

From: Jared Smith
Date: Apr 27, 2011 11:18AM

On Wed, Apr 27, 2011 at 10:17 AM, < <EMAIL REMOVED> > wrote:
> Are their best practices for
> implementing WAI-ARIA design goals?

I somewhat echo Tim's response - try to do what you can without ARIA
initially, identify where accessibility remains insufficient or can be
enhanced, then use ARIA where possible to fill these gaps.

> 1. Add WAI-ARIA to any AJAX live regions to announce dynamic page
> changes.

This is usually only necessary in two cases:
1. If the updated content is critical AND if the update is not
initiated by the user and is then readily accessible.
2. If the dynamic content updates occur automatically AND can occur in
an area of the page that currently is being read or has focus.

In most cases, these can be avoided by simply allowing the user to
initiate or pause the content updates.

> 2. Identify if there are any page regions that are not currently
> keyboard accessible which need to be, and use WAI-ARIA to provide
> keyboard access to those divs/spans.

This is a somewhat rare case as most interactive elements (links and
form controls) are already keyboard accessible. In cases where
non-focusable elements need keyboard accessibility or focus (a
scripted, non-form control, for example), then often using a standard
link or form control instead works best. Otherwise (a dialog box, for
example), tabindex values of 0 or -1 (which is part of ARIA, though
has been supported in all major browsers for some time) and/or
JavaScript focus() is often sufficient.

> 4. Add WAI-ARIA to make  form constraints explicit to adaptive
> technology users.

Yes, this may be necessary in cases when a form field is required,
invalid, disabled, or has more than one piece of content that labels
or describes it. As noted above, you would use standard HTML to
provide this to the extent possible, then use ARIA to fill in the
gaps.

> 5. At a much lower priority, provide structure markup (e.g.
> navigation regions).

I'd list this as a much higher priority. It is very easy to add
landmark roles. They have no negative impact on users that don't use
ARIA-supported technologies, yet can provide significant utility for
users that are using ARIA-supported technologies and know about
navigating by landmarks. In other words, adding them can only make the
page more accessible.

Hopefully this helps a bit.

Jared