ARIA in HTML – there goes the neighborhood

Will HTML5 make the use of WAI-ARIA in HTML redundant? the short answer is definitely not. There are many ARIA roles and properties that are not provided by native elements and attributes in HTML5. Also developers still have the desire to roll their own interactive controls or web components even though they have been available in HTML as native elements for 15 years, why would this suddenly change with HTML5?

First rule of ARIA use (never forget):

If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Using ARIA in HTML

Examples from real world web apps : a button and a link

Developers have had for 15 years a number of native elements they can use for buttons and the a element for links, provided in HTML 4, all of which provide built in mouse and keyboard interaction and convey role, state and name properties to accessibility APIs:

  • input type="button"
  • input type="image"
  • button element
  • a element

But still in 2014 companies like Twitter and Google, choose to emulate a button with code (not to mention the associated scripting) such as this:

write a tweet button

<a data-placement="bottom" class="js-tooltip global-dm-nav" href="#" role="button"
 data-original-title="Direct messages">
 <span class="Icon Icon--dm Icon--large"></span>
 <span class="dm-new"><span class="count-inner"></span></span>
 <span class="visuallyhidden">Direct messages</span>

Or this

Gmail refresh button

<div tabindex="0" role="button" act="20" class="T-I J-J5-Ji nu T-I-ax7 L3" 
style="-moz-user-select: none;" data-tooltip="Refresh" aria-label="Refresh">
<div class="asa">
<div class="asf T-I-J3 J-J5-Ji">

and a link like this:

quick links link in Gmail

<div role="link" tabindex="0" idlink="" class="py pr" id=":i">
<h2 id=":k" class="pw">Quick Links</h2>
<div class="qn"></div></div>

Note: First example from twitter, others are from Google’s Gmail application.

The reason is probably because they cannot apply the styles they want to native interactive elements, but who knows? What is important for accessibility is if developers choose to code in this way, they now have a method to provide the needed accessibility information. It would be preferable that they used the available native HTML elements, but if they do not, then ARIA provides what HTML alone cannot.

ARIA used in native HTML implementations (there goes the neighborhood):

Chrome uses ARIA to map roles and properties from the HTML DOM to accessibility APIs in its native HTML implementation of input type=”week”

<input type="week">
#shadow root (user agent)
<div pseudo="-webkit-datetime-edit" id="date-time-edit" datetimeformat="'Week 'ww, yyyy">
<div pseudo="-webkit-datetime-edit-fields-wrapper">
<div pseudo="-webkit-datetime-edit-text">Week </div>
<span role="spinbutton" aria-valuetext="blank" aria-valuemin="1" 
aria-valuemax="53" pseudo="-webkit-datetime-edit-week-field">--</span>
<div pseudo="-webkit-datetime-edit-text">, </div>
<span role="spinbutton" aria-valuetext="blank" aria-valuemin="1" aria-valuemax="275760" 

Aria roles and properties not available in HTML5

Below are listed the ARIA roles and properties. not considered to be available natively in HTML5. It is clear that many roles and properties provided by ARIA which can be used to convey information to users are not available in HTML5.

ARIA Roles

  1. alert
  2. alertdialog
  3. gridcell
  4. log
  5. marquee
  6. menuitemcheckbox
  7. menuitemradio
  8. scrollbar
  9. status
  10. tab
  11. tabpanel
  12. timer
  13. tooltip
  14. treeitem
  15. grid
  16. menu
  17. menubar
  18. switch
  19. tablist
  20. toolbar
  21. tree
  22. treegrid
  23. directory
  24. document
  25. group
  26. note
  27. presentation
  28. region
  29. application
  30. search

ARIA States and Properties (aria-* attributes)

  1. aria-activedescendant
  2. aria-atomic
  3. aria-busy (state)
  4. aria-controls
  5. aria-describedby
  6. aria-dropeffect
  7. aria-expanded (state)
  8. aria-flowto
  9. aria-grabbed (state)
  10. aria-haspopup
  11. aria-hidden (state)
  12. aria-label
  13. aria-labelledby
  14. aria-level
  15. aria-live
  16. aria-orientation
  17. aria-owns
  18. aria-posinset
  19. aria-pressed (state)
  20. aria-relevant
  21. aria-setsize
  22. aria-sort

Further reading:

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.


Jason Boyer says:

Thanks for the article. The vs thing has always bugged me. Glad to see I’m not the only one!

I wrote up my thoughts on using the element rather than the element just the other day – Stop using anchors as buttons.

The only minor issue with using a button rather than an anchor is the 1px pixel shift that happens in IE. Other than that, you can make it visually appear however you need to.

Evan says:

Many private-sector businesses don’t want to absorb the development costs of accessibility.

The dissatisfaction with standard browser user interface elements is that it is not aesthetically consistent when marketing a website or web application. This hurts private-sector brand competition and limits creativity.

Native platform applications allow for accessibility and software design customization. There’s no reason the web can’t do that as well.

Geoffroy says:

Very useful, Yesterday I just thought to ask in stackoverflow about this topic and… surprise! This morning I have the answers in this post
Thanks to HTML5Weekly 🙂

Steve Faulkner says:

yeah saw that in HTML5 weekly 🙂