WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA best practices and priorities

for

From: Tim Harshbarger
Date: Apr 27, 2011 10:51AM

My suggestion would be to start by forgetting about ARIA and focusing on the user experience. Once you prioritize those elements of your site that create the greatest problems for the user experience, then decide how or if ARIA might be used to address those issues. If you do that, I think you will end up making the best decisions possible for your site.

And to me, it sounds like you are already talking to your users about their experience so you are probably already doing the right thing.

Tim
Tim harshbarger
Accessibility Consultant
State Farm Insurance Companies
-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of <EMAIL REMOVED>
Sent: Wednesday, April 27, 2011 11:18 AM
To: WebAIM Discussion List
Subject: [WebAIM] ARIA best practices and priorities

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