Will HTML5 make the use of WAI-ARIA in HTML redundant? the short answer is definitley 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 even though they have been available in HTML as native elements for 11 years, why would this suddenly change when HTML5 arrives?
Examples: a button and a link
Developers have had for 11 years 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 accessibilityAPIs:
input type="button"input type="image"buttonelementaelement
But still in 2010 companies like Google, choose to emulate a button with code (not to mention the associated scripting) such as this:
<DIV id=:rk class="J-K-I J-J5-Ji L3 J-K-I-JO" tabIndex=0
unselectable="on" closure_hashCode_l16mgm="182" act="">
<DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on"> </DIV>
<DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV>
</DIV></DIV></DIV></DIV>
and a link like this:
<SPAN id=:rg class=toxOdd role=link tabIndex=0 closure_hashCode_l16mgm="177">
Create a filter</SPAN>
Note: Examples are taken from Googles 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.
Further reading:
- Clean markup plea : Anne van kesteren ramps up the rhetoric on the issue.
- HML5 and WAI-ARIA: Alastair Campbell explores the issue further.
Aria roles and properties not available in HTML5
Below are listed the ARIA roles and properties. Those roles and properties suffixed with a “+” are features 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
5.3.2. Widget Roles
The following roles act as user interface widgets that do not provide a defined structure. All roles are linked to their definitions in the WAI-ARIA 1.0 specification.
alert +alertdialog +buttoncheckboxcomboboxdialog +gridcell +linklog +marquee +menuitemmenuitemcheckboxmenuitemradiooptionprogressbarradioradiogroupscrollbar +sliderspinbuttonstatus +tab +tabpanel +textboxtimer +tooltip +treeitem +
The following roles act as composite user interface widgets that provide a defined structure. These roles typically act as containers that manage other, contained widgets.
5.3.3. Document Structure
The following roles describe structures that organize content in a page. Document structures are not usually interactive.
articlecolumnheaderdefinition +directory +document +group +headingimglistlistitemmath +note +presentation +region +rowrowheaderseparator
5.3.4. Landmark Roles
The following roles are regions of the page intended as navigational landmarks.
ARIA States and Properties (all aria-* attributes)
Below is an alphabetical list of WAI-ARIA states and properties to be used by rich internet application authors. A detailed definition of each WAI-ARIA state and property follows this compact list.
aria-activedescendant +- Identifies the currently active descendant of a composite widget.
aria-atomic +- Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute. Also see aria-relevant.
aria-autocomplete- Indicates whether user input completion suggestions are provided.
aria-busy(state) +- Indicates whether an element, and its subtree, are currently being updated.
aria-checked(state)- Indicates the current “checked” state of checkboxes, radio buttons, and other widgets. Also see aria-pressed and aria-selected.
aria-controls +- Identifies the element (or elements) whose contents or presence are controlled by the current element. Also see aria-owns.
aria-describedby +- Identifies the element (or elements) that describes the object. Also see aria-labelledby.
aria-disabled(state)- Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. Also see aria-hidden and aria-readonly.
aria-dropeffect +- Indicates what functions can be performed when the dragged object is released on the drop target. This allows assistive technologies to convey the possible drag options available to users, including whether a pop-up menu of choices is provided by the application. Typically, drop effect functions can only be provided once an object has been grabbed for a drag operation as the drop effect functions available are dependent on the object being dragged.
aria-expanded(state) +- Indicates whether an expandable/collapsible group of elements is currently expanded or collapsed.
aria-flowto +- Identifies the next element (or elements) in the recommended reading order of content, overriding the general default to read in document source order.
aria-grabbed(state) +- Indicates an element’s “grabbed” state in a drag-and-drop operation.
aria-haspopup +- Indicates that the element has a popup context menu or sub-level menu.
aria-hidden(state)- Indicates that the element is not visible or perceivable to any user. Also see aria-disabled.
aria-invalid(state)- Indicates the entered value does not conform to the format expected by the application.
aria-label +- Defines a string value that labels the current element when included as an attribute of the current element. Also see aria-labelledby.
aria-labelledby +- Identifies the element (or elements) that labels the current element. Also see aria-label and aria-describedby.
aria-level +- Defines the hierarchical level of an element within a structure.
aria-live +- Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
aria-multiline- Indicates whether a text box accepts only a single line, or if it can accept multiline input.
aria-multiselectable- Indicates that the user may select more than one item from the current selectable descendants.
aria-orientation +- Indicates whether the element and orientation is horizontal or vertical.
aria-owns +- Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. Also see aria-controls.
aria-posinset +- Defines an element’s number or position in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. Also see aria-setsize.
aria-pressed(state) +- Indicates the current “pressed” state of toggle buttons. Also see aria-checked and aria-selected.
aria-readonly- Indicates that the element is not editable, but is otherwise operable. Also see aria-disabled.
aria-relevant +- Indicates what user agent change notifications (additions, removals, etc.) assistive technologies will monitor within a live region. Also see aria-atomic.
aria-required- Indicates that user input is required on the element before a form may be submitted.
aria-selected(state)- Indicates the current “selected” state of various widgets. Also see aria-checked and aria-pressed.
aria-setsize +- Defines the number of items in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. Also see aria-posinset.
aria-sort +- Indicates if items in a table or grid are sorted in ascending or descending order.
aria-valuemax- Defines the maximum allowed value for a range widget.
aria-valuemin- Defines the minimum allowed value for a range widget.
aria-valuenow- Defines the current value for a range widget. Also see aria-valuetext.
aria-valuetext- Defines the human readable text alternative of aria-valuenow for a range widget.
Comments
Excellent. Timely. It would also help if accessibility folks would stop using terms such as “bolt on” and “stop gap”, when talking about ARIA. We developers are getting a very confusing, very mixed, message.
Even the use of “bridge” isn’t necessary. It should be sufficient to just say: you can incorporate accessibility into your applications using existing HTML elements that have integrated accessibility, or you can incorporate WAI-ARIA into your web pages and JavaScript applications…or both!
We can’t told to use WAI-ARIA and not to use WAI-ARIA at the same time and still be expected to know what we should do.
Thanks for the review Steve. My hope is that developers continue to *add* (or bolt-on) these attributes to their meaningless , to ensure that when they get creative with form inputs, etc. (as witnessed by your button example above, which *could* have been rendered with the more ‘semantic’ and meaningful by using the
I take exception to Shelley’s comment, as it completely ignores history and the actual design intent of ARIA, which was developed (starting close to a decade ago) to retro-fit content that was inaccessible for a variety of reasons. As a retro-fit solution, it is *very* clever and well done, but as it still requires additional effort and code on the part of the author, it is less optimal than using specific native elements which require no additional effort on the author’s part to convey meaning; again we can return to
It is less than helpful to the accessibility cause to have late-comers show up and start telling those who have worked in the field for years (including some of the biggest and brightest stars, including Rich Schwerdtfeger (IBM Distinguished engineer), TV Ramen (Google, developer of Emacspeak), James Craig (Apple), and countless others) that they are wrong. Further, to go onto blogs and tell that community that quoting from the ARIA document is inappropriate does the accessibility community a real disservice. From the ARIA Draft:
Frankly Shelley, please stop spreading mis-information; you are helping no-one, and hurting many simply to drive your political agenda. If you beleive that the ARIA Working Draft is incorrect, you might still be able to add your feedback, although the deadline for submissions was February 2010. It’s really too bad your interest in ARIA doesn’t go back that far, as if your observations were valid, they could have been addressed prior to that date in the appropriate forum.
Totally agree Steve. I’ll also add that ARIA will likely expand in the future and it can provide a way to more rapidly add new roles that may be needed. ARIA defines some roles that the Flash Player already supports, so when the Flash Player and Flex add support for IA2 and ARIA we may not need to use all of the roles for our accessible components, but developers will need ARIA to support some additional control types, and the need for the liveRegion functionality is also critical.
If anyone is thinking that HTML5 will obsolete ARIA they are kidding themselves.
Many thanks, timely and the use of the word ‘myth’ in the title very pertinent. For me ARIA is accessibility value-adding, and as support increases so will the use of ARIA. BTW, when will HTML 5 arrive, we can’t sit on our hands and do nothing until it arrives – Waiting for Godot.
Steve – Awesome. I’m glad you realized the need for this blog and did it.
John – I’m glad you to see you give specific props to Rich Schwerdtfeger, he has been a tireless leader in making ARIA a real world solution.
Andrew – looking forward to IA2 support in Flash and Flex!
This is an excellent article. Keep them coming. Understanding the least-complicated path to successfully dleivering accessiblity in products with options is what IT folks need. As ar as the bolt-on and bridge language, it is simpler to say how to build-it in, but at the end of the day as long as we provide clear direction on “how” to do it we’ve done our part.