Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

The WAI Forward

It’s one thing to create a web application and quite another to keep it accessible — independent of the device that the user is using and its capabilities. That’s why Heydon Pickering1, now the accessibility editor on Smashing Magazine, wrote an eBook Apps For All: Coding Accessible Web Applications422, outlining the roadmap for well-designed, accessible applications.

This article is an excerpt of a chapter in the eBook that introduces many of the ideas and techniques presented. Reviewed by Steve Faulkner3, it’s an eBook you definitely shouldn’t miss if you’re a developer who cares about well-structured content and inclusive interface design. – Ed.

Further Reading on SmashingMag:

Because the W3C’s mission from the outset has been to make the web accessible, accessibility features are built into its specifications. As responsible designers, we have the job of creating compelling web experiences without disrupting the inclusive features of a simpler design.

As Scott Jehl said8:

“Accessibility is not something we add to a website, but something we start with and risk losing with each enhancement. It is to be retained.”

Unfortunately, not all websites are destined to be as simple as the provocative manifesto that is “This Is a Mother****ing Website9” and, as web interfaces evolve, complying with the Web Content Accessibility Guidelines10 (WCAG 2.0) has become increasingly difficult. As we together embrace the advancements of the web and our newfound power to construct hitherto impossible web-based software, we need to tackle the accessibility of new idioms. We need to find a way to adopt new tools and techniques to keep the playing field level.

It’s time to embrace change.

Further Reading on SmashingMag: Link11

ARIA: A Passion For Parity Link

The Web Accessibility Initiative’s (WAI) specification for Accessible Rich Internet Applications16 (WAI-ARIA) is an accessibility resource like WCAG 2.0, with certain notable differences. If it helps, you could think of the two resources as siblings: Both have been brought up in the same environment and have been instilled with the same basic values, but they differ in personality. WCAG 2.0 is the cautious homebody who keeps the home fires burning, while the more gregarious WAI-ARIA has ambitions to take accessibility to new territories.

Unlike WCAG 2.0, ARIA is not only a set of recommendations but a suite of attributes to be included in your HTML. Its tools enable you to alter and increase the amount of information shared about your HTML with users of assistive technologies. This is extremely useful when you’re making web apps because the roles, properties, states and relationships of elements in a web app are liable to be a lot more complex and dynamic. One way of looking at it is that ARIA gives you the tools to meet the WCAG’s requirements in web apps.


The Two Purposes Of ARIA Link

ARIA gives you the ability to reclassify and otherwise augment the perceived meaning (or semantics) of your HTML. That’s pretty powerful, but what is the purpose of it? ARIA has two main applications.

Remedy Link

ARIA can be used as a remedy to improve the information provided to assistive technology by poorly coded, unsemantic markup.


For example, a developer might use a <div> and some JavaScript to emulate a type="checkbox". They shouldn’t, but they might. To make this <div> actually understandable as a checkbox, the ARIA role of checkbox19 can be added as an attribute, making screen readers think it is, in fact, a standard checkbox. In addition, our developer must use the aria-checked attribute to indicate whether the checkbox is indeed checked.

<div class="toggle-thingy" role="checkbox" aria-checked="false" tabindex="0">Yes?</div>

Using the proper input element, type attribute and checked attribute to communicate this information would be better — they are better supported than ARIA (which is relatively modern), and the input element would be automatically focusable, like a semantic <button> (so, no need for the tabindex). Nonetheless, we can employ ARIA in this way to make quick fixes to markup, often without disturbing the design of the application.

Enhancement Link

As we’ve established, web applications are more complex than simple web documents, and our use of HTML elements tends to exceed the basic semantics gifted to them. ARIA’s killer feature is its ability to help authors like you and me communicate many of these more ambitious uses in an accessible way.

Take ARIA’s aria-haspopup attribute20. It represents a property of certain elements that have a hidden submenu. The owner of this property is likely to be an <a> or <button> element and, without this special attribute, that’s all it would be to the user of a screen reader: No clue would be given that the submenu exists.

  <a href="#submenu" aria-haspopup="true" aria-controls="submenu1">Main link</a>
  <ul id="submenu">
    <li><a href="/somewhere/">Submenu link</a></li>
    <li><a href="/somewhere/else/">Another link</a></li>

Some of these ARIA attributes are expected to be replaced by simple HTML elements and attributes. As I write, the <dialog> element is being slowly adopted21 as the successor to the dialog and alertdialog ARIA role attributes, for example.

Where possible, superseding ARIA with plain HTML(5) is good because it simplifies the markup and centralizes the W3C’s advice. However, many attributes that communicate specific contextual information, such as the aria-haspopup and aria-controls22 properties in the code above, are unlikely to find as much mainstream support for inclusion as perhaps haspopup and controls will have.

As Steve Faulkner points out in “HTML5 and the Myth of WAI-ARIA Redundance23”, much of ARIA will continue to exist unbested. The unique power of ARIA is to bridge the gap between the experiences of sighted and unsighted web users.

Role-Playing Link

A lot of my friends and colleagues are keen on tabletop role-playing games, which, in case you’re not familiar with them, are games in which participants play fictional characters who embark on quests and fight battles in fantastical worlds. Although I’m not a big exponent of these games myself, I’ve noticed similarities between the way characters are role-played in games and the way HTML elements act within web applications. Accordingly, I’ll use this role-playing metaphor to explain ARIA’s roles, properties and states in greater detail.

Don’t worry, you won’t have to be a big role-playing geek to follow along. I’m not!

Roles Link

Each player in a role-playing game normally maintains a “character sheet” that lists the important characteristics of the character they are playing. In HTML, the name of the character might be the id of an element. Each must be unique.

Characters have a lot more information than that in the sheet, though. For example, characters dwelling in these fantasy worlds usually belong to one “race” or another. Common standbys are elves, dwarves and trolls. These are like HTML element types: broad groupings of participants with common characteristics.

In ARIA, the role attribute overrides the element type, much like a player in a game overrides their workaday existence as a 21st-century human to become a mighty dwarf. In the example from the last section, an insipid <div> assumed the role of a checkbox by being given role="checkbox".


Roles in ARIA25, like races in a role-playing game, are a part of a character’s identity that we might be interested in. We might expect dwarves to be strong and good at constructing machines, just like we expect a <button> to have the characteristics and behaviors already discussed. By putting role="button" on an element that isn’t actually a <button>, we are asking assistive technologies to identify it as a button, evoking those characteristics.

Properties Link

Character sheets with just names and races would be a bit limited. We’d probably be a bit uncomfortable with so much emphasis on race, too. The whole point of ARIA is that it recognizes elements not just for their generic, reductive classification. Much better to identify characters and elements by their individual assets and talents.

A typical sheet would list a set of characteristics for a character that, in one way or another, the game identifies as having a certain currency and importance. For instance, you might be an elf but one who is special for the ability to cast certain magic spells. In much the same way, we looked at an <a> element that is made special for having the property of a submenu. This would be identified to the accessibility layer, just like the basic role, via the aria-haspopup="true" property attribute.


A huge number of properties27 have been specified and documented. Some are global, meaning that any element may have them, while others are reserved for particular contexts and elements. Dwarves are usually precluded from having good longbow accuracy, whereas the skill is common to elves. The aria-label that we would use to label a button is global, whereas aria-required, which denotes a required user entry, would normally be used in form fields or elements with form-field roles, such as listbox and textbox.

States Link

Perhaps the most important distinction between a static web document and an application is that the elements in an application tend to change — sometimes dramatically — according to user interaction and timed events. Depending on what’s happening in an application at any one time, the elements therein could be said to be in certain, often temporary, states.

In role-playing games, you have to keep tabs on the state of your character: How healthy are you? What items have you collected? Who have you befriended? This is all scribbled down, erased and scribbled down some more on the character sheet. Keeping track of the state of interactive elements is important for accessibility, too.

In your application, the state of an element is usually represented visually. In role-playing games and in screen-reader buffers, this is not the case: It has to be imagined. If your dwarf character has donned their magic cloak of invisibility, you’d probably want to write this down on the character sheet so that you remember. Similarly, writing the aria-hidden attribute28 on an element ensures that the accessible state of invisibility is recorded properly.


States such as aria-expanded30 are announced according to a value of true or false. An item with aria-expanded="false" is announced by JAWS and NVDA Windows screen readers as “collapsed.” If — or, rather, when — it is set to aria-expanded="true", then the item will be announced as “expanded.”

Our First ARIA Widget Link

It’s about time we put everything we’ve learned about roles, properties and states into practice and build our first ARIA widget.

The term “widget” is often used in JavaScript development to denote a singular pocket of script-enabled interactive functionality. Mercifully, the ARIA definition corresponds, and ARIA widgets can be thought of as JavaScript widgets that have been made accessible with appropriate ARIA attributes.

Let’s make a simple toolbar — a group of button controls that enable us to organize some content. In this case, we’ll set up controls to sort content alphabetically and reverse alphabetically. Fortunately, we have access to the W3C’s guide on authoring ARIA widgets, “General Steps for Building an Accessible Widget With WAI-ARIA31,” which covers a similar example for a toolbar.

The Toolbar Role Link

There’s no such thing as a <toolbar> element in HTML, unless you create one as a web component32. In any case, because there’s no standard element for toolbars, we need to include the toolbar role in our toolbar’s parent element. This marks the scope of the widget:

<div role="toolbar">
  /* toolbar functionality goes here */

(Note: A <menu> element takes a type of toolbar, but it has not been adopted by browser vendors33 so is unable to provide the information we need.)

The toolbar’s purpose in our design should be obvious from its visual relationship to the content it affects. This won’t communicate anything aurally, however, so we should provide an accessible name for our toolbar via the now familiar aria-label property. That’s one role and one property so far.

<div role="toolbar" aria-label="sorting options">
  /* toolbar functionality goes here */

Now let’s add the buttons that will be our controls.

<div role="toolbar" aria-label="sorting options">
  <button>A to Z</button>
  <button>Z to A</button>

Even without the additional widget properties and states, we’ve already improved the user’s recognition of the toolbar: Using the NVDA screen reader or the JAWS screen reader with Firefox, when a user focuses the first button, they are informed that they’re inside a toolbar and — thanks to the aria-label — told what it is for.


The Relationship Link

So far, we haven’t actually connected our toolbar to the content it controls. We need a relationship attribute, which is a special kind of property attribute that communicates a relationship between elements. Our widget is used to control the content, to manipulate and reorganize it, so we’ll go with aria-controls. We’ll join the dots using an id value, just as we did in the earlier example of the popup menu.

<div role="toolbar" aria-label="sorting options" aria-controls="sortable">
  <button>A to Z</button>
  <button>Z to A</button>

<ul id="sortable">
  <li>Fiddler crab</li>
  <li>Hermit crab</li>
  <li>Red crab</li>
  <li>Robber crab</li>
  <li>Sponge crab</li>
  <li>Yeti crab</li>

Note that we’ve added aria-controls to the toolbar itself, not to each individual button. Both would be acceptable, but using it just the once is more succinct, and the buttons should each be considered individual components that belong to the controlling toolbar. If we want to check which properties and states are supported for widget roles like toolbar, the specification provides a list of “inherited states and properties35” in each case. Consult this when you build a widget. As you will see36, aria-controls is an inherited property of toolbar.

Some screen readers do very little explicitly with this relationship of information, while others are quite outspoken. JAWS actually announces a keyboard command to enable the user to move focus to the controlled element: “Use JAWS key + Alt + M to move to controlled element.” Once you’ve affected it, you might want to go and inspect it, and JAWS is helping you to do just that here.


Pressed and Unpressed Link

Depending on which sorting option is our current preference, we could say that the button that commands that option is in a “selected,” or “pressed,” state. This is where the aria-pressed state attribute comes in, taking a value of true for pressed or false for unpressed. States are dynamic and should be toggled with JavaScript. On the page being loaded, just the first button will be set to true.

<div role="toolbar" aria-label="sorting options" aria-controls="sortable">
  <button aria-pressed="true">A to Z</button>
  <button aria-pressed="false">Z to A</button>
<ul id="sortable">
  <li>Fiddler crab</li>
  <li>Hermit crab</li>
  <li>Red crab</li>
  <li>Robber crab</li>
  <li>Sponge crab</li>
  <li>Yeti crab</li>

Pairing the styles for active (:active) buttons with the styles for aria-pressed buttons is a good practice. Both are buttons that have been “pushed down,” whether momentarily or semi-permanently.

button:active, button[aria-pressed="true"] {
  position: relative;
  top: 3px; /* 3px drop */
  box-shadow: 0 1px 0 #222; /* less by 3px */

When the user focuses a button with aria-pressed present using either NVDA or JAWS with Firefox, the button is identified as a “toggle button.” Using the latest version of JAWS and focusing a button with aria-pressed="true" will append the word “pressed” to the announcement accordingly. In the ChromeVox39 screen reader for the Chrome browser, an aria-pressed="true" button is announced as “button pressed” and aria-pressed="false" as “button not pressed.” To a greater or lesser extent, most modern browsers and screen readers articulate helpful information about the state or potential state of these buttons.

Keyboard Controls Link

Not quite there yet. For toolbars — as with many ARIA widgets — the W3C recommends certain keyboard navigation features40, often to emulate the equivalent in desktop software. Pressing the left and right arrow keys should switch focus between the buttons, and pressing “Tab” should move focus out of the toolbar. We’ll add tabindex="-1" to the list and focus it using JavaScript whenever the user presses “Tab.” We do this to allow users to move directly to the list once they’ve chosen a sorting option. In a toolbar with several buttons, this could potentially save them from having to tab through a number of adjacent buttons to get to the list.

<div role="toolbar" aria-label="sorting options" aria-controls="sortable">
    <button aria-pressed="true">A to Z</button>
    <button aria-pressed="false">Z to A</button>
  <ul id="sortable" tabindex="-1">
    <li>Fiddler crab</li>
    <li>Hermit crab</li>
    <li>Red crab</li>
    <li>Robber crab</li>
    <li>Sponge crab</li>
    <li>Yeti crab</li>

All Done Link

That concludes our ARIA widget. A live demo41 is ready for you to play with and test. Remember that it’s not really about sorting, per se — that’s all done with JavaScript. The aim is to make explicit the relationships and states of our application, so that whatever we are doing to our content — sorting it, editing it, searching it, creating it, recreating it — our users on keyboards and screen readers are kept in the loop.

The next chapter of the Apps For All: Coding Accessible Web Applications422 eBook puts the application functionality to one side and addresses how to actually find that application functionality in the first place. Mobility is a big part of accessibility online and off, so it’s important to look at different ways to help our users get around.

(al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42

↑ Back to top Tweet itShare on Facebook

Heydon is a designer, writer and public speaker. He works with The Paciello Group as a UX and accessibility consultant. His book, Inclusive Design Patterns, is available in hardcover and as an ebook from Smashing Magazine.

  1. 1

    Ethan Hackett

    July 9, 2014 5:57 pm

    Awesome. I think the web community really needs to change how we think of accessibility. Rather than approaching it as a limitation or laborious task if we shift gears and approach it like we do responsive design. There are some limitations inherent to responsive design and accessibility however it challenges us to think of designs and engagements that treat each user as a first class citizen regardless of whether they’re using a screen reader, phone etc.

    Thanks for encouraging us to be better designers and developers and providing resources.

    • 2

      Thank you, Ethan.

      Responsive Design really renewed my passion for web design when (the other) Ethan first started talking about it. The ‘unknown’ of different device sizes and capabilities really made me appreciate that design isn’t just making something look a certain way.

      Working with screen readers and for those who use them puts even more pressure on this concept of design as a static, visual artifact: Designing something to communicate information in a way that works without being seen at all is a challenge that I relish.

  2. 3

    Miles Johnson

    July 9, 2014 8:03 pm

    ARIA has always been tough for me to implement. A lot of times I would run into scenarios where I’m not sure if I am implementing it correctly. There’s also no way to validate your ARIA implementation is correct (that I have found). I’m hoping ARIA picks up in the near future as it is greatly needed.

    On a side note, the Titon Toolkit library comes bundled with built in ARIA support.

    • 4

      Vincent Young

      July 10, 2014 12:04 am

      @Miles Johnson

      Understand your frustration, but there are some really good resources to help you such as:

    • 6

      I appreciate that ARIA can be confounding, which is why I wrote the book!

      One important thing the book covers is ‘focus management’. Using the correct ARIA attributes is one thing, but making sure users’ workflow is assisted is quite another.

      Take the Titon Toolkit’s modals, for example. These are incomplete and inaccessible.


      Because when you invoke a a Titon modal it does not move focus to the modal in order for the keyboard user to manipulate it. It’s difficult to tell this in the Titon demos because (whoops!) they have not supported :focus on any of the buttons. This means keyboard users can’t tell what buttons they are pressing at all.

      The only way to reliably test to see if an ARIA widget works is to:

      1. Use it with a keyboard and see if you can actually get the task done
      2. Use it with a screen reader and keyboard and see if you can still actually get the task done

      Can you actually open the dialog, read it and take actions that if offers? That’s right: You have to think in User Experience (UX) terms.

      I cover modal dialogs in the book and I made a modal demo that tackles these issues available as well, should you like to take a look.

    • 7

      There is one way to validate. Use a screen reader for yourself to test. You only need to watch a few youtube videos on what the standard key for things are. Like button VS link keyboard keys.

      Free screen reader and ARIA compatible

      Tip: crtl – s to mute and unmute audio.

      A button or listbox is triggered with a spacebar. A link is triggered with enter. So for below. You could fix markup like below with a few attributes. Below is a real portions of markup I’ve been having to patch vs redesign. Vendors are awesome.



      • 8

        Guess markup isn’t allowed in comments. Too bad.

        Also, a typo mute is insert – s.

  3. 9

    Chris Poteet

    July 13, 2014 12:46 am

    ARIA is exciting, but as I understand it, not only is browser support poor; but no major vendor has taken part in the specification. Is this untrue?

    • 10

      This is completely untrue. All major browsers support WAI-ARIA, though Firefox has the most comprehensive support.

      Different browsers and screen reader combinations have different interpretations of ARIA features in places but consensus is surprisingly high. Often differences in announced information are arbitrary like “press” versus “push”.

    • 11

      Léonie Watson

      July 14, 2014 7:54 pm


      One of the editors of the ARIA 1.0 spec is from Apple, and people from Google, Mozilla and Microsoft are also among the spec contributers [2].


    • 12

      steve faulkner

      July 15, 2014 10:39 am

      “not only is browser support poor; but no major vendor has taken part in the specification. Is this untrue?”

      Yes, the opposite is true. ARIA is implemented in all major browsers, support in Webkit and Firefox is particularly robust. Before ARIA 1.0 became a recommendation March 2014 all normative implementation requirements had to be tested and shown to be interoperably implemented in at least 2 browsers on 2 OS’s. Detail can be found in the ARIA 1.0 Implementation Report []

      As far as vendor participation is concerned: Accessibility engineers from Mozilla, Google, Apple and Microsoft were and are active participants in the ongoing development of the ARIA specification (James Craig from Apple is currently editor of ARIA 1.1) and related specs.

  4. 13

    I think only a handful of apps and websites should have accessbillity, not worth the extra work for the 0.003% of the market, if we dont do it for ie6 users why do it now?

    • 14

      Xandor Schiefer

      July 14, 2014 1:47 pm

      I think you have your statistics wrong… Please read the following:

      Also consider that once you hit 40 years of age, there’s a 50% chance that you’ll have some kind of accessibility issue yourself. That chance goes up every day you age.

      What kind of web are you building now?
      What kind of web are you leaving behind that new developers will be learning from? What kind of web are you encouraging your co-workers to build?
      One you’ll be able to use later? For all our sakes, I hope so.

    • 15

      Because this isn’t just about supporting old browsers, it’s about ensuring that everybody has access to the same content and the same experience regardless of disabilities and/or other physical/technical limitations.

      It is most definitely worth the extra work.

    • 16

      I find it weird that you think some websites should be accessible.

      This begs the question “which ones?”

      If you mean “ones which blind people use” or “ones which keyboard users use” then that’s all the ones someone has been professional enough to make accessible.

      Once you know what you are doing, it’s really not much more work anyway. It’s just a matter of caring enough in the first place to make it part of your process.

    • 17

      Léonie Watson

      July 14, 2014 1:59 pm


      Can you point to the source of your 0.003% statistic? The UN has it at around 15% [1].

      It makes no sense to draw comparisons between disability figures and browser usage stats, since people with disabilities use Chrome, Firefox, Safari and IE.


    • 18


      In the United States alone, Census 2000 counted 49.7 million people with some type of long lasting condition or disability. They represented 19.3 percent of the 257.2 million people who were aged 5 and older in the civilian non-institutionalized population — or nearly one person in five.

    • 19

      Martin Baillie

      July 16, 2014 8:33 pm

      Because it’s a legal requirement – in the UK at least. To not make your websites accessible breaches the Equality Act 2010.

    • 20

      It’s going to be required in the USA eventually. Might as well make it a habit now. Also, there’s a difference between someone not upgrading software like IE6 and someone being physically unable to do something. One can be remedy easily by the end user.

  5. 21

    Paul Ferguson

    July 16, 2014 9:51 pm

    Can’t remember the exact detail but in Sweaden there are now laws of equal opportunities which now cover access on the web. You can now be liable if you don’t provide a good expiriance for all users.
    Ida Aalen covered it in her talk at A Responsive Day Out (2014 –
    sadly doesn’t seem to be much follow up from the Conf, I’m sure they were filming it).

  6. 22

    Ian McBurnie

    July 17, 2014 6:55 pm

    Thank you for an excellent article!

    The only thing I wonder about is the need for the list to be in the tabindex. It seems that being able to tab to this list serves no purpose for keyboard users without a screenreader, as the list element itself is not interactive once it has keyboard focus.

    It seems this tab stop is added as a convenience for screenreader users, but to the slight (and okay, it is very slight) detriment of keyboard users – even though, as mentioned in your article, JAWS has it’s very own way of moving to and reading the list (JAWS key + Alt + M). And of course other screen readers such as VoiceOver also have their own way of getting to the list without using the TAB key.

    I often see the same pattern (dare I call it an anti-pattern?) with other custom controls, such as tab panels and overlays, where the container element receives keyboard focus, but is not interactive in any way. It seems to be used as a brute-force mechanism to get the screenreader to move to and read the contents of an element. Although to be fair, I do believe this pattern is sometimes being used out of necessity due to a lack of a better, more-widely supported alternative at that time.

    I’d be interested to know what yourself and others think about this!

    Anyway, again, thanks for a great article – and I think you know more about roleplaying games than you are letting on ;-)

    • 23

      This is a tricky area and I appreciate your thoughts on it.

      I don’t think it is an anti-pattern but there is certainly an argument not to bother with the programmatic focus to the list.

      The reason I did include this, as explained, is because a toolbar with multiple controls should allow you to forego the controls and go straight to the list, should you use a screen reader.

      Since left and right arrow navigation is provided for (all) keyboard users anyway, this should not be too obstructive.

      I’d like to hear others’ thoughts on this too. I’m ambivalent.

  7. 24

    Frank Waive

    July 18, 2014 8:37 am

    Still in the equal access rights argument, emerging markets are mostly never given equal access rights, from language, to payment systems, their needs have always been ignored…

  8. 25

    From my personal experience it’s the role of developers to help designers get accustomed to the way accessibility works on the web.

    Great article, thanks.

  9. 26

    Graphic designers are artists.


↑ Back to top