Improving Accessibility Through ARIA

Accessibility is a pretty hairy issue in web development. When attempting to determine if your site is accessible, there are so many standards and recommendations to follow. 508, WCAG, WCAG 2.0, WAI Priority 1, 2 & 3.

Well, now there is a new standard from the W3C called WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)

The simplest definition of ARIA is adding UI semantics via HTML element attributes. Simply, you add things like ‘<div role="navigation">‘ or ‘<form role="search">‘ to specific HTML elements to give screen readers a better understanding of your content.

The ARIA spec is huge (160 pages), so I won’t go over every part of it in detail. The four areas I will focus on are landmarks, required, invalid and live regions.

ARIA Landmarks

Today, when a blind user encounters a website, navigation between elements of the page can be difficult because there is no established method of marking areas of the page as navigation, content, footer, etc. Luckily with ARIA, we can.

Here’s some example markup of a typical webpage:

<div id="header">
    <h1>My Awesome Website</h1>
    <form> </form>
<div id="content">
    <ul id="nav"></ul>
    My website rocks!
<div id="footer"></div>

And here’s what it looks like with ARIA Landmarks:

<div id="header" role="banner">
    <h1>My Awesome Website</h1>
    <form role="search"> </form>
<div id="content" role="main">
    <ul id="nav" role="navigation"></ul>
    My website rocks!
<div id="footer"></div>

What I’ve done is add ARIA roles to certain parts of the page (header, nav, search form, primary content). Because the roles are a defined spec, screen readers can parse the page for roles and allow a user to jump to each part without having to navigate through all the content.

ARIA Required & Invalid

Another part of the ARIA spec is the attribute ‘aria-required’ and ‘aria-invalid’. These attributes are for communicating to screen readers that a particular form field is required and/or invalid without requiring the user to look for asterisks or other text near the field. The screen reader would alert the user to this information. Here’s an example:

<form id="searchform" role="search">
      <p class="error">You did not enter a search term</p>
      <input name="query" value="" aria-required="true" aria-invalid="true" />

The above code has the ‘aria-required’ and ‘aria-invalid’ attributes set to true. When a screen reader encounters this code, it will read aloud ‘required’ and ‘invalid’. This is a lot simpler for a user than attempting to find error messages and/or asterisks in the page.


A particularly difficult area of accessibility is dealing with AJAX. How can you communicate to a screen reader that content is loading or has changed? Thankfully, with ARAI Live Regions, it is quite simple. Here’s an example:

    <div id="sidecontent" aria-live="polite"> AJAX content goes here... <div>

Adding the ‘aria-live’ attribute to an element alerts a screen reader that content will change in this region and to read it aloud when it does. The aria-live attribute has ‘politeness’ levels, which allow you to specify how polite the updates should be. The four levels are

  • off – updates are not communicated
  • polite – notify of changes only when the user is not doing anything
  • assertive – announce as soon as possible, but not interrupting the user
  • rude – which will be read aloud immediately – removed per Nick’s comment

The various levels of politeness allow for different situations where users would need to be notified immediately of important information or for content that is not as important.


This is just a quick overview of ARIA and its uses, but I’m really excited about the possibilities it creates. We can communicate the intent of our content much more explicitly. There’s also a lot of other aspects to ARIA including widgets (slider, checkbox), application structure (alerts, log, progressbar) and document structure (article, grid, definition) that are exciting.

Further Reading

11 responses

  1. Jeff Balogh wrote on :

    Why not skip ahead to HTML5 and use <nav> and <input type=”search”>? What browsers do those who could take advantage of ARIA use? Can I expect them to use the latest hotness? How can I get my pages to validate while using ARIA? That green favicon makes me so happy!

  2. Aaron Leventhal wrote on :

    Hi Jeff, HTML 5 does not solve all the accessibility problems that ARIA solves. For example, there is no live region markup, and you also need ARIA whenever you develop custom widgets. The closest thing HTML 5 has to any of the ARIA features is the landmarks. But, even that doesn’t work with screen readers yet.

    In summary ARIA not only solves a lot more a11y problems that HTML 5, it already works in shipping browsers and assistive technologies today.

    Great article — quick correction to it: the into mentions role=”nav”, but it should say role=”navigation” (the example later on has the correct version).

    People may be interested in It’s not a well-known site, We were hoping that more ARIA resources would point toward it. A number of us have worked hard on putting together a lot of test cases and resources. More contributions welcome 🙂

  3. Aaron Leventhal wrote on :

    Jeff, I forgot to answer which browsers support ARIA. Firefox has supported it since version 2. IE 8 also supports it, and Safari 4 has added some support. Opera is working on it.

    ARIA doesn’t affect your web content’s rendering for mainstream users. You can use ARIA without worrying that it will change how older browsers render your content.

  4. Ruben Rojas wrote on :

    Are these attributes supported by all the browsers? it is this HTML or (X)HTML?

  5. rdoherty wrote on :


    So far a few screen readers support much of ARIA, making it much more accessible than HTML5.

    IE8 and Firefox >= 3 support ARIA.

    If you *really* need that green favicon, there is a HTML validator with ARIA support here:

  6. rdoherty wrote on :


    Thanks for noticing my role=”nav” typo, I’ve fixed it 🙂

    And I guess my research of browsers that support ARIA is old 🙁

  7. nemo wrote on :

    Required/invalid looks neat, but I’m a little dubious as to its usefulness. It seems there’s already a way to associate text with an input. Why not add your error text to the ? If you’re doing an accessible site you’ll have those anyway, and often times functions of fields can be inferred from initial label text – several JS validators use the label text to determine required/phone/name etc.

    That way, if the screen reader is reading out the form after submission, surely they’ll get almost the same correlation as a sighted person?

  8. nemo wrote on :

    I see this site strips tags instead of escaping them. Annoying. 🙂
    “Why not add your error text to the ? ”
    Should read
    “Why not add your error text to the [label]?”

  9. Nick Fitzsimons wrote on :

    Good article. One quick point: the value rude for the <aria-live attribute has been removed from the current version of the WAI-ARIA Working Draft.

  10. rdoherty wrote on :

    @Nick: Thanks! I’ve edited the post.

  11. Charles wrote on :

    Thanks for sharing on web, really good.
    php experts