ARIA is an amazing technology, it allows developers to add meaning to meaningless HTML or override meaning on HTML that is being repurposed and sometimes misused, so that users who rely upon the meaning of HTML, as implemented in browsers, can understand and interact with HTML User Interfaces successfully.
ARIA allows developers to re-invent and extend native HTML features in meaningful ways. But like all bolt-on technologies its features are brittle compared to its built-in counterparts.
Whenever you are considering:
role=buttonconsider using a
<button>element, or the various other native HTML button types, instead.
role=link,consider using an
<a href>element instead.
role=option, consider using
role=radio, consider using
<input type="radio">elements instead.
role=textbox, consider using an
- and so on…
By using native HTML features, wherever practical, over custom HTML with bolt-on semantics and interaction behaviours, you will save yourselves and users a lot of grief and ensure that your User Interfaces work robustly across the largest number of devices, operating systems, input devices, browsers and assistive technologies.
5 Responses on the article “HTML Developers: Please Consider”
Is it also safe to stop marking up the newer structural elements with landmark roles like
(the validator would seem to indicate that this could be actively harmful now)
@Jeremy On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about) may be helpful in answering your question.
What the validator says is for example “Warning: Element header does not need a role attribute.” which is shy of indicating it’s actively harmful (though in some circumstances it may be). It warns for all HTML elements that have a default implicit ARIA role semantic (i.e. the role exposed by browsers via accessibility APIs has a corresponding ARIA role mapping). The HTML conformance rules are defined in ARIA in HTML:
If it was actively harmful in the majority of instances it would be a MUST NOT rather than SHOULD NOT requirement in the spec. and the validator would emit an error. What the rules are designed to do is reduce redundant, unneccessary (cargo cult) use of ARIA semantics, to reduce cruft and possible introduction of semantic mis-information.
I’ve had push back on removing landmark roles like what Jeremy indicated because of IE support being poor all the way up to IE11. Sadly, it’ll probably take a couple more years for the industry to move past the pains of IE to stop using landmark roles in markup by default unless the work is cutting edge and not supporting screen readers using IE.
I’ve never heard of or seen any developer consider using most ARIA roles for other elements like the ones you indicated above so I would imagine the use case for even considering them is quite small.
I understand this, which is why the conformance rules are SHOULD NOT as against MUST NOT. I discuss RFC terms in this article: Short Note on HTML conformance checking. It is also worth reading HTML5 – Check it Before you Wreck it with Mike[tm] Smith, which provides insight into HTML conformance checking.
But note that IE has never supported exposure of h1-h6 via accessibility APIs (unlike all other major browsers) and as a result Assitive Tech have hacked around such bugs by pulling information from the DOM. The newer versions of screen readers are doing the same for landmarks in IE.
I look at web application code on a daily basis, as part of my job, and find examples of recreation of native HTML features (roles, states and properties) on a regular basis. I am not saying it is common, but neither is it uncommon.
I recently had a client use html required … it was messy for assistive technology out of the box. The error message threw the user into the first field with error and read “Please fill in this field” but no AT I tested read the label when it through the user into that field…
although it is highly customizable, and could be fixed with a custom message etc… I found it easier to use aria-required … and rely on JS error message insertion into the DOM…
Join the discussion.