HTML and CSS Reference
In-Depth Information
say “this element is a header,” “this element is navigation,” “this ele-
ment is a toolbar,” and so on. Let's look at an example:
<body role="document">
<div role="note" aria-live="polite"
aria-relevant="additions removals">
An update added by JavaScript
</div>
<div role="banner">
<h1 role="heading" aria-level="1">The heading</h1>
</div>
<div role="navigation">
<a role="link" href="/home">Home Page</a>
<a role="link" href="/inbox">Inbox</a>
</div>
<div role="main">
A very interesting article goes here.
</div>
<div role="footer">
All rights reserved.
</div>
</body>
This should all sound a little familiar to you. What
HTML5
aims to
accomplish through additions such as the
<header>
and
<nav>
elements is
similar to what
ARIA
tries to accomplish in providing better semantics
to assistive technology. But it's still worth bothering with
ARIA
because it has a wider and more far-reaching vocabulary than
HTML5
for describing the components of web applications. Plus it already has
wide support among vendors of browsers, operating systems, and
assistive technology.
The
HTML5
spec has a long list of elements to which user agents
should automatically assign particular
ARIA
roles. These elements are
said to have
strong native semantics
, so if you use
HTML5
correctly you'll
get a certain amount of accessibility for free compared to what
HTML4
offered once the browsers and assistive technologies implement sup-
port. The
HTML5
spec also explicitly lists the allowed
ARIA
roles for
those elements where there's a risk the
ARIA
role will be in conflict
with the
HTML5
semantics—these are
implied native semantics
. Valida-
tion tools can then flag inappropriate combinations.
