Future Web Accessibility: HTML5 Semantic Elements

This is the second in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments. Last week: HTML5 <video>.

HTML5 Semantic Elements

HTML5 introduces several new semantic elements representing logical sections or components of a web app or document: <section>, <nav>, <article>, <aside>, <hgroup>, <header>, and <footer>, along with new rules for using the old <h1>–<h6> and <address> elements. None of the new elements actually “do” anything by themselves, but they provide a much nicer way for web authors to define the various parts of a document, and open the door for user agents and assistive technologies to use this information to enable alternate ways of viewing and navigating a page.

Browser Support

Because HTML was designed from the beginning to be forward-compatible, web browsers are supposed to ignore tags they don’t recognize, yet still render the content inside those tags normally. Since none of the new semantic tags require any special formatting or behavior, they should work fine in all future and current web browsers, even those who don’t officially “support” or know anything about HTML5. The big, sad exception to this is Internet Explorer, which refuses to apply styles to the new tags or allow them to be used as part of CSS selectors. Luckily there’s a script-based hack that successfully convinces IE to change its mind, allowing pages using HTML5 semantic tags to work correctly everywhere.

Accessibility

In general, this all has the potential to improve accessibility in a big way, especially if screen readers and other assistive technologies start passing the associated information along to users. (No major AT vendors have yet committed to do this, but if HTML5 gains wide usage we expect that they will. Eventually).

There are also a few cases where a specific tag or usage-pattern could create a unique opportunity or possible problem for accessibility (or quite often, both at once) which are worth mentioning separately.

Exclusive use of <h1> in <section>s and <article>s

In current versions of HTML, the only way to define sections and outline-hierarchy of a document is use of the <h1>–<h6> in an otherwise flat structure. This is very beneficial to accessibility, but can be a bit awkward for web authors, especially when moving sections around in ways that change the heading depth. HTML5 introduces two new elements, <section> and <article>, that define logical sections and syndicatable articles present in a page; content hierarchy and heading levels are defined by nesting these tags inside each other. Because of this, HTML5 no longer requires that one actually use the correct heading level for a particular heading, but allows web authors to use <h1> everywhere, with the idea that assistive technologies and other systems can determine the heading level by the nesting of the <section> and <article> tags.

This is actually a perfectly fine way of doing things, but has the potential to create some sizable accessibility problems during the transition phase, that is, during the time where not everyone is using AT (of which there currently is none) that knows how to handle this. Since it will be several years before all the AT vendors update their products to support HTML5, and several more years before all users of those products upgrade to the newer versions, accessibility will require that we continue to use heading tags of the correct level, even when they’re inside nested <section>s and <article>s, at least for now.

The <nav> Element

The HTML5 <nav> element provides a way to explicitly specify where the navigation for your page lives, and may eventually allow web authors to stop providing “skip navigation” functionality on pages where currently needed. The spec says,

“User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.”

As before, this will be really neat, once assistive technologies (or even better, standard web browsers) give users the ability to directly take advantage of it. In the mean time, web authors can start marking up navigation sections accordingly but should not yet remove appropriate skip links from their documents.

ARIA Roles

There is significant overlap between the semantic meaning of many of the new HTML5 semantic elements and some of the document structure and landmark roles from WAI-ARIA. The HTML5 spec contains a section on ARIA dealing with how the different roles can be applied to HTML5 elements.

In some cases, HTML5 requires user agents to automatically use specific ARIA roles on certain elements, without the author having to specifically include them, and in fact even if the author explicitly says to use some other role. For example, the HTML5 <nav> element must always have the ARIA navigation role, with no exceptions. So <nav> (with no ARIA role specified), <nav role=”navigation”> and <nav role=”main”> will be all handled by web browsers and assistive technology as if they were each <nav role=”navigation”>.

In other cases, HTML5 requires that user agents provide reasonable default roles to certain elements, but allows these to be overridden by the content author, at least within certain limits. For example, the HTML5 <article> element defaults to the ARIA article role (i.e., it will act like it has role=”article” if it doesn’t have a role attribute) but may also be manually set to the document, application, or main roles if one of those is more appropriate to the specific page; however, in no cases can an <article> have a role of button, separator, or other things that make no sense under any circumstances.

Since the WAI-ARIA spec doesn’t specifically deal with what HTML elements are allowed to have what roles, this is a welcome addition, and should clarify a few things about implementing ARIA in HTML5. Additionally, the native and default roles applied to certain elements by the HTML5 spec means that content authors won’t have to manually specify ARIA attributes on those elements (or even know what ARIA is) in order for users to benefit from ARIA support in assistive technologies. However, the standard disclaimer still applies: user agents (and assistive technologies) with existing ARIA support might not be updated to include full HTML5 support for some time, so it’s probably a good idea to continue manually specifying ARIA roles on appropriate elements, even when using the new HTML5 tags.

Lastly, it’s worth noting that the new semantic elements don’t come close to expressing the full detail and specifics available in the complete ARIA spec, so ARIA itself isn’t going away any time soon, even after HTML5 support is ubiquitous.

The Bottom Line

New semantic elements coming in HTML5. Provide ability to markup document components and sections. Backwards compatible with existing web browsers (with a script-based hack required for IE). Great potential for accessibility, but could be dangerous if existing accessibility solutions are removed before users update to browsers and assistive technologies with HTML5 support.

Further Reading

• Sections – HTML5 [whatwg.org]
• New Semantic Elements in HTML5 – Dive Into HTML5 [diveintohtml5.org]
• HTML5 articles and sections: what’s the difference? – Bruce Lawson [brucelawson.co.uk]
• HTML5 and the myth of WAI-ARIA redundance [paciellogroup.com]
• Annotations for assistive technology products (ARIA) [whatwg.org]