Text - Introducing HTML5 - page 50

So, using horrible old-school HTML you could—in theory—add
ARIA to
<font size=”+5” color=”red”>I should be a heading</font>
to make
<font size=”+5” color=”red” role=”heading” aria-level=”2” >
¬ I should be a heading</font>
This tells the user agent that this text is a heading, level 2. But of
course, this would be nonsense, as HTML already has a perfectly
valid and semantic way of defining this sort of structure with
<h2>I AM a heading</h2>
A developer might forget to bolt on the necessary ARIA attri-
butes, whereas using the correct <h2> element has built-in
“heading-ness” and built-in level so it's a lot more robust. ARIA
is not a panacea or “get out of jail free” card for developers to
start abusing markup and make everything out of <div> s and
<span> s. Whenever possible, use the correct markup and use
ARIA only in situations where the correct semantics can't be oth-
erwise expressed (a slider in HTML 4 example, for instance).
The ARIA spec says, “It is expected that, over time, host lan-
guages will evolve to provide semantics for objects that pre-
viously could only be declared with WAI-ARIA. When native
semantics for a given feature become available, it is appropriate
for authors to use the native feature and stop using WAI-ARIA
for that feature.”
So something like HTML5 <nav> shouldn't need ARIA
role=navigation added to it, because it should (in an ideal
world) have that built-in. However, HTML5 is very new, whereas
ARIA already has some support in assistive technology. So it
shouldn't hurt to use the built-in element plus the ARIA informa-
tion, and it can only help users who rely on assistive technology.
The HTML5 validator therefore validates ARIA as well as HTML5
(whereas HTML 4 validators report ARIA information as an error
because HTML 4 predates ARIA).