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 role="banner">
<h1 role="heading" aria-level="1">The heading</h1>
<div role="navigation">
<a role="link" href="/home">Home Page</a>
<a role="link" href="/inbox">Inbox</a>
<div role="main">
A very interesting article goes here.
<div role="footer">
All rights reserved.
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.
Search WWH ::

Custom Search