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.
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
elementa
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:
<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>
</a>
Or this
<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"> </div></div></div>
and a link like this:
<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"
pseudo="-webkit-datetime-edit-year-field">----</span>
</div></div>
</input>
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
alert
alertdialog
gridcell
log
marquee
menuitemcheckbox
menuitemradio
scrollbar
status
tab
tabpanel
timer
tooltip
treeitem
grid
menu
menubar
switch
tablist
toolbar
tree
treegrid
directory
document
group
note
presentation
region
application
search
ARIA States and Properties (aria-* attributes)
aria-activedescendant
aria-atomic
aria-busy
(state)aria-controls
aria-describedby
aria-dropeffect
aria-expanded
(state)aria-flowto
aria-grabbed
(state)aria-haspopup
aria-hidden
(state)aria-label
aria-labelledby
aria-level
aria-live
aria-orientation
aria-owns
aria-posinset
aria-pressed
(state)aria-relevant
aria-setsize
aria-sort
Further reading:
Stop adding ARIA cruft to your crappy markup. Just learn HTML. Keep it simple.
— Krijn Hoetmer (@krijnhoetmer) September 29, 2014
Stop adding JavaScript cruft to your crappy markup. Just learn HTML. Keep it simple. [context https://t.co/Z65Tghn9N2]
— Steve Faulkner (@stevefaulkner) October 1, 2014
Comments
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.
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.
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 🙂
yeah saw that in HTML5 weekly 🙂