The new semantic elements in HTML5 hold accessibility promise. Here are some of the the new elements.
- header: header can be used for a page element, a section, and article, or an aside element
- footer: footer can be used for a page element, a section, and article, or an aside element
- article: an article is a part of a page that is complete in itself with a heading, content, footer, and possibly sections
- section: a section is a a section of a page; related content can be contained in a section but it should have a heading and may contain articles with their own headings
- aside: the aside is tangentially related material on a page or as part of an article
- nav: navigation
ARIA roles work now in many browsers and screen readers. When they don’t, they are harmless. If you build a page as accessibly as you can and then add ARIA roles into it where possible, you increase the potential accessibility of the page. This is currently the recommended best practice with HTML5 semantic elements.
An ARIA role is added as an attribute to the relevant element. The landmark ARIA roles are helpful with the new HTML5 semantic elements:
There are also a number of roles that describe structure on a page.
Here are a few examples of how to add the landmark role information to various elements:
Some roles can only be used once per page.
contentinfo must be unique on a page. In other words, while you can have many
header elements on a page, only one header can fill the
[Note: This post was updated on June 12, 2014.]
See also: ARIA Roles 101 and ARIA States 101.
6 thoughts on “How to make HTML5 semantic elements more accessible”
Nice post, interested in the use of role=heading on the hgroup. My reading of the role=heading in the spec would require a aria-level to be specified. I would have also thought the benefits of using H1 – H6 for AT users would also require the setting of aria-level to at least provide an equivalent level of information?
Also given the patchy support by browsers/AT that this is really a viable option right now, specifically role=header?
Those are good questions. I don’t think there is a solid answer right now, because the way assistive devices interpret the header/hgroup elements within the DOM or document outline isn’t settled yet, AFAIK. I’ve wondered myself how a page peppered with h1 elements in headers or hgroups would work for AT. Use of aria-level might be a way to help resolve that.
Just a heads-up: all the links to the roles on the W3C site need %23 replaced with #.
John, thanks for the heads up. WYSIWYG input: yuk.