WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA best practices and priorities

for

From: Sailesh Panchang
Date: Apr 28, 2011 7:42AM

The ARIA recommendation has always maintained, "The incorporation of
Accessible Rich Internet Applications is a way for an author to
provide proper semantics for custom widgets to make these widgets
accessible, usable, and interoperable with assistive technologies...
This document is primarily for developers creating custom widgets and
other web application components".
So I believe one should use standard HTML elements (links and form
controls) where possible and style them as needed instead of writing
JS code and CSS to make divs and span and img elements appear like
checkboxes, buttons etc.
With ARIA one can make sliders, progress bars , menus, alerts and
tooltips accessible and the labelledby, describedby attributes help to
make contextual information programmatically determinable. I echo
Jared's remarks about landmark roles.
But you do make an important point: browsers and AT yet do not
support ARIA features uniformly.
I believe one should use techniques (ARIA or not) that will make
things work with multiple browsers and assistive technology
combinations. When this is not possible, try to make it work at least
with one or two assistive technology / browser combinations and write
to AT maker / browser maker to make improvements citing how the
feature works with some other browser and AT.

Custom widgets depend on JavaScript and CSS and when one uses ARIA to
make the widgets accessible, one needs to test that the ARIA
attributes are being updated correctly to expose role / state to
assistive technology. So testing assumes greater significance to
ensure things are accessible and workable.
Another point is often I see claims that certain widgets or interfaces
are accessible because they have been made keyboard operable with
ARIA. But in reality they do not work with any screen reader.
Sailesh Panchang


On 4/27/11, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
> 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
>
>