Why does HTML footer take role=”contentinfo”?

Evangelia Dendramis asked me “why use role=contentinfo instead of role=footer for <footer>?”

role attributes are from the Accessible Rich Internet Applications (WAI-ARIA) spec, and not part of HTML(5), although they’re allowed in pages. They’re developed by different groups, and for different reasons. ARIA is a bridging technlogy for any markup language – HTML4, SVG or HTML5 to “plugin” accessibility information that isn’t part of the host language:

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page…

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. 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.

contentinfo is defined as an ARIA landmark on a page. It’s primarily there so assistive technology can allow a user to navigate around. The ARIA spec describes contentinfo as

A large perceivable region that contains information about the parent document. Examples of information included in this region of the page are copyrights and links to privacy statements. Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.

This is a good description of a page footer, but HTML5 allows as many <footer> elements as you want:

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

The HTML5 <footer> does give “content info” but does so about its parent, which may be one of many <article>s or <section>s. Another element that gives information about the content it’s in is the <address> element, which may (but doesn’t have to) take an ARIA role of contentinfo.

So there’s not a 1-to-1 correspondence between <footer> and role="contentinfo". This is exactly the same as the correspondence as we see between <header> and role="banner". So it’s probably less confusing that the HTML5 element and the ARIA roles have different names.

It seems that the name <footer> was adopted as it was the most common class name found in a billion web pages analysed in 2005 by Ian Hickson, HTML5 editor. Arguably, contentinfo is a better “semantic” name (after all, information about content doesn’t have to be below the content it refers to, which is what “footer” implies), but “footer” is what people were already using. Anyway, the naming of the new HTML5 elements is done now. There’s no use in bikeshedding once the ship has sailed, as Captain MixedMetaphor says.

The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it. Good; that’s the way it should be.

However, until all do, you give a helping hand by explicitly adding that role on the page-wide footer.

5 Responses to “ Why does HTML footer take role=”contentinfo”? ”

Comment by steve faulkner

The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it.

It primarily means it’s an implementation requirement on browsers to map the contentinfo role to footer in accessibility APIs only when footer is not a descendant of an article or section element. same for header/banner. Its implemented correctly in some browsers, IE is lagging behind as is Chrome/Opera on Windows.

Comment by Bruce

Ta. Steve. I hadn’t realised that it’s a browser implementation requirement thingy rather than an AT requirement thingy.

Have you filed a Chromium bug?