WebAIM - Web Accessibility In Mind

E-mail List Archives

ARIA best practices and priorities

for

From: deborah.kaplan@suberic.net
Date: Apr 27, 2011 10:33AM

We've talked a lot on this list about WAI-ARIA and various places
to get started. I've now been tasked with the big picture item of
implementing WAI-ARIA on a large site, and I am finding myself
drowned by all of the possibilities of markup WAI-ARIA
theoretically provides. I'm trying to come up with a priority
list for what would be best served by WAI-ARIA markup, and it's
difficult, because user agent and adaptive tech WAI-ARIA support
are changing everyday, so it's not clear what use cases are going
to be served.

Certainly I can see the practical everyday value of the current
effects of WAI-ARIA on NVDA and Firefox mouseless browsing, but I
still need to prioritize. Are their best practices for
implementing WAI-ARIA design goals?

My thought has been to prioritize as:

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

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.

3. Add WAI-ARIA to any otherwise inaccessible widgets (in our
case, switching most of those widgets to already WAI-ARIA-enabled
jQuery widgets might solve the problem).

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

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

What do folks think of this? Partly this comes from feedback from
our users, who are still unused to structure markup, and find
that having their screenreaders suddenly announce a lot more
information is an annoyance. Partly it comes from being
overwhelmed at reading documents like
<http://www.w3.org/TR/wai-aria-practices/>;. We just need to
narrow down our real use cases.

Thanks,

-deborah