A Note About Using WAI-ARIA

Share on FacebookShare on LinkedInShare on Twitter

Globe with world map and circuit board in background (Digital)Some accessibility experts are of the opinion that they have a general agreement about using WAI-ARIA wherever and whenever one can.

Opinion

“Using WAI-ARIA wherever and whenever we can” goes against the basic tenets of ARIA outlined in the Introduction to ARIA. ARIA needs to be used only when needed and I have been highlighting this in my email responses on various public lists for 4+ years because many need to be reminded of this.

The Introduction to ARIA [1] scream this rule out loud:

WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature. WAI-ARIA should only be used in cases where the host language lacks the needed role, state, and property indicators. Use a host language feature that is as similar as possible to the WAI-ARIA feature, then refine the meaning by adding WAI-ARIA…

This is reinforced by the Rules for ARIA use in HTML [2] published in 07/2012 authored by (Steve Faulkner).

[hs_action id=”6666, 6657″]

7 comments

  • Sailesh Permalink

    Steve,

    Your point in’HTML5 and the myth of WAI-ARIA redundance’ is well taken.

    Indeed I routinely flag an SC 4.1.2 violation when what appears like a button visually is simply marked up as a link. This impacts discoverability and navigability for screen reader users for instance.

    My recommendation is use INPUT type=image / button or a BUTTON element. If this is not practical, at least assign role=button to the anchor element.

    Based on rules of precedence, user agents will expose the link as a button.

    And some ARIA features requires fairly involved JavaScripting and manipulation of attribute values. If not done correctly, accessibility is adversely impacted.

    So user-testing is important.

    Sailesh

  • Sailesh Permalink

    Steve,

    Indeed it is based on practical considerations and is informative in nature.

    User agents including assistive technologies have their nuances in implementing and interpreting WAI-ARIA. So this is a note to say use it when needed and ensure it works with browsers and AT in the intended environment.

    Laura: Right. Your observation also suggests one should rely on features of the host language where possible.

    Jared,

    You will be surprised …It is not my intent to name names. It is in the interest of users and accessibility that I thought it is important to highlight this issue.

    Thanks,

    Sailesh

  • steve faulkner Permalink

    Also reality is that some aspects of ARIA are not covered by native HTML semantics and are not expected to be in the foreseeable future. Refer to: HTML5 and the myth of WAI-ARIA redundance. Another reality is that even though the native features are available they are not used by developers for a number of reasons. Look under the hood of a Google app such as gmail literally 100’s of controls, but only a handful of HTML input elements… Just saying no does not work.

  • Laura Permalink

    Hi Sailesh,

    Thank you very much for this reminder. Many overlook that WAI-ARIA is a bridging technology. Bridging technologies are not intended to replace native semantic features i.e. longdesc in HTML. Detouring accessibility technical requirements into an “Accessible Rich Internet Applications” bridging specification is backward.

    The Protocols and Formats Working Group is the group that authors WAI-ARIA. Their charter states: “Note that WAI-ARIA is intended to be a bridging technology. It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA.”

    http://www.w3.org/WAI/PF/charter201006

    A significant goal of WAI-ARIA is to: “help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.”

    http://www.w3.org/TR/wai-aria/introduction#co-evolution

  • steve faulkner Permalink

    Hi Sailesh,

    Note the rules of ARIA are informative only and I wrote them based on practical concerns only. i.e. built in is better than bolt on as its less prone to error.

  • Jared Smith Permalink

    I’m curious which “accessibility experts” or “general agreement” you are referring to. I certainly have never heard this sentiment from reputable folks in the field.

    Unless you’re referring to folks suggesting ARIA landmarks, for example, on pretty much every web page (at least until HTML5 is well supported), I’m not sure what widespread problem this post is referring to.

Leave a Reply

You can use these HTML tags:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>