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

Comments

  1. steve faulkner

    To clarify your section on ARIA Roles in particular, what is currently in the HTML5 specification (http://dev.w3.org/html5/spec/embedded-content-0.html#annotations-for-assistive-technology-products-aria) in regards to ARIA/HTML5 mapping is ONLY a draft for consideration, written by the editor of the spec, it has not been agreed upon by anybody. Work is currently under way by the W3C HTML accessibility taskforce (http://www.w3.org/WAI/PF/HTML/wiki/Category:HTML5) to provide recommendations for changes to this section among others, that could have a significant impact upon the conformance and other requirements currently in the spec.

  2. John Faulds

    I was looking forward to the sort of freedom from content hierarchy that HTML5 was going to offer for headings, but reading that ATs may not be able to understand documents that use h1s throughout rather than the usual structure has somewhat deflated my enthusiasm.

  3. Suzanne Klaus

    Good information – I just have one comment. Given the fact that IE does not and has never conformed to Web standards, I have been encouraging my users to switch to another browser. I think if its popularity continued to decrease, the programmers would be forced to conform.

  4. Christophe Strobbe

    Has anyone thought about mapping these new semantic elements to existing accessibility APIs? As far as I know, the roles or elements “article”, “main” and “nav”/”navigation” have no counterparts in any of the accessibility APIs that I have checked (GNOME/ATK, Java Accessibility API, IAccessible2, UIAutomation, Carbon, Cocoa). The “note” role has a counterpart only in IAccessble2 (IA2_ROLE_NOTE). “Section” has counterparts in GNOME/ATK and IAccessible2 but not in UIAutomation, the Java Accessibility API or the Mac a11y APIs.

  5. Jens

    There is still one big issue with HTML5 accessibility that you don’t address. And that is that the new semantic elements of HTML5 is JavaScript dependant in Internet Explorer. Not only will styles sieze to function, but you will also end up with an totally messed up DOM tree due to that IE won’t understand the end tag of all new semantic elements (you can se this in action with IE Developer Toolbar). This results in unclosed tags all over the markup potentially rendering content inaccessible for sighted users without JS-support. There is no fix for this problem except to not use the new semantic elements (which no fun at all!).