E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: deborah.kaplan
Date: Wed, Apr 27 2011 10:33AM
Subject: ARIA best practices and priorities
No previous message | Next message →

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

From: Tim Harshbarger
Date: Wed, Apr 27 2011 10:51AM
Subject: Re: ARIA best practices and priorities
← Previous message | Next message →

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

From: Jared Smith
Date: Wed, Apr 27 2011 11:18AM
Subject: Re: ARIA best practices and priorities
← Previous message | Next message →

On Wed, Apr 27, 2011 at 10:17 AM, < = EMAIL ADDRESS 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

From: deborah.kaplan
Date: Wed, Apr 27 2011 10:18PM
Subject: Re: ARIA best practices and priorities
← Previous message | Next message →

Thank you, Jared and Tim, this is helpful. Once we've written up our design goals, I'll share them with the group if I think they'll be useful. (I'm not sure yet how rich they will be.)

-Deborah

From: Sailesh Panchang
Date: Thu, Apr 28 2011 7:42AM
Subject: Re: ARIA best practices and priorities
← Previous message | No next message

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 ADDRESS REMOVED = < = EMAIL ADDRESS 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
>
>