5 HTML5 and ARIA design patterns
With HTML5 and ARIA now in regular use across the web, several design patterns are emerging that solve common scenarios. This article takes five HTML5 and ARIA design patterns and explains why they make good design choices
1. Main element design pattern
A design pattern for basic page architecture.
- <body>
- <header role="banner">
- ...
- </header>
- <main role="main">
- <article>
- <header> ... </header>
- ...
- <footer> ... </footer>
- </article>
- </main>
- <footer role="contentinfo">
- ...
- </footer>
- </body>
The main element is one of the most recent additions to the HTML5 specification. It represents the main content area of a page. Used in combination with other HTML5 elements like header and footer, it’s an effective design pattern for basic page structure.
There must only be one main element in a page. The HTML5.1 spec is unequivocal about this:
"Authors must not include more than one main element in a document."
The main element should contain content that is unique to the page. In other words, it shouldn’t contain content that’s repeated across the website or application. In this design pattern repeated content like the logo would go inside the header element, and site information like copyright or smallprint would go inside the footer.
The role of main is natively associated with the main element in HTML5. Applying the ARIA role="main" directly in the HTML is therefore a "belt and braces" technique. It tells browsers and assistive technologies that don’t support the main element (but which do support ARIA landmark roles), that they should treat everything within the containing element as the principal content of the page.
Note: as in the example only use the banner and contentinfo roles on header and footer when they are scoped to the body element.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
One advantage of this design pattern is that it could mean skip links are no longer needed in the future. At the moment (and for the foreseeable future) it’s necessary to implement these keyboard shortcuts manually. The HTML5.1 spec encourages browsers and assistive technologies to introduce keyboard navigation that takes focus directly to the main element, so in time it may mean that skip links become a thing of the past.
2. Navigation design pattern
A design pattern for primary and secondary navigation blocks.
- <nav role="navigation">
- <ul>
- <li><a href="home.html">Home</a></li>
- <li><a href="about.html">About us</a></li>
- <li><a href="contact.html">Contact us</a></li>
- </ul>
- </nav>
The nav element represents a region of a page that contains navigational links, either as a collection or as part of other content. A frequent misconception is that the nav element should be used for every group of links on a page, but the HTML5.1 specification makes it clear this isn’t the case:
"Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks."
The nav and ul elements fulfil different purposes, so the nav element extends (rather than replaces) the traditional ul based design pattern. The nav element tells browsers and assistive technologies that this region of the page is for the purpose of navigation, and the ul element does what it always does (groups a collection of items together).
The role of navigation is natively associated with the nav element in HTML5. Applying the ARIA role="navigation" directly in the HTML is therefore the same “belt and braces” technique used in the main design pattern.
3. Section design pattern
A design pattern for regions that group thematic content.
- <section role="region" aria-labelledby="heading">
- <h1 id="heading">Weather report</h1>
- ...
- </section>
If the section element does not contain a heading the aria-label element may be used:
- <section role="region" aria-label="Weather report">
- .....
- </section>
The section element represents a generic region of a page. It’s often thought that the section element should be used for every chunk of content not already handled by one of the other HTML5 sectioning elements. The HTML5.1 spec explains otherwise:
"The section element is not a generic container element. When an element is needed only for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead."
The region role is natively associated with the section element in HTML5. By now it’ll be familiar practice to apply the role directly in the HTML, as a way to identify these HTML5 elements to browsers and assistive technologies that don’t yet support them.
The section element is versatile because it represents a generic region, but that can cause problems when it comes to good design. Browsers and assistive technologies that support the section element have no way to identify the purpose of the content within the region.
The HTML5.1 spec provides the following information:
"A section, in this context, is a thematic grouping of content, typically with a heading."
Associating the heading with its parent section element solves the problem. Using the aria-labelledby attribute on the section element and pairing it with the id on the heading, creates a programmatic relationship between the two. In this example it means that browsers and assistive technologies would identify this chunk of the page as "Weather report region" instead of just "Region".
Note: If the section element does not have a heading, or you can't think of a reasonable label for the content the section contains, you are probably misusing the section element. In these cases it’s better to use a semantically neutral div element instead.
4. Details and summary design pattern
A design pattern for disclosing content.
- <details role="group">
- <summary role="button" aria-expanded="false">Course schedule</summary>
- <table>
- <tr>
- <th>Start date</th><th>End date</th><th>Duration</th>
- </tr>
- </table>
- </details>
The details element and summary element work in tandem. Together they create a native widget that neatly lets the user access additional information. Or they will when browser support gets a bit more consistent (currently only Webkit/Blink based browsers support these HTML5 elements). For the time being a JavaScript polyfill is still needed to achieve the desired behaviour across the rest.
The ARIA group role tells browsers and assistive technologies that the details element contains a set of related objects. The role on the summary element means that browsers and assistive technologies that don’t support these HTML5 elements regard the summary element as a button. This is complimented by the aria-expanded attribute, which indicates the current state of the associated content within the details element.
This design pattern gives the widget better affordance (especially for assistive technology users). The little black arrow that some browsers use to indicate a disclosure widget only goes so far. With the added ARIA the whole thing becomes much more robust – it’s a button (and everyone knows a button can be pressed), and it’s clear that something will expand or collapse when it is.
5. Figure and figcaption design pattern
A design pattern for annotated content.
- <a href="#fig1">Figure 1</a>
- ...
- <figure id="fig1" role="group" aria-labelledby="caption">
- <figcaption id="caption">Code example</figcaption>
- <pre>
- ...
- </pre>
- </figure>
The figure element and figcaption element represent that text book classic – an annotated piece of content that can be referenced from somewhere else. For example, in this design pattern the link could be located inside a paragraph of text that references the code example in figure 1.
The figure element contains a self-contained chunk of content. The group role is applied for the same reason it was applied it in the details/summary design pattern. It indicates to browsers and assistive technologies that the figure element contains a set of related elements.
The figcaption element provides the annotation for the figure content. The aria-labelledby attribute is paired with the id on the figcaption element. It creates an association between the figure and figcaption elements for those browsers and assistive technologies that don’t yet support these HTML5 elements. At present Firefox is the only browser to support figure and figcaption semantics.
Useful links
Image by Patrick Lauke
Words: Léonie Watson and Steve Faulkner
Léonie Watson is a digital accessibility consultant, and Steve Faulkner is the senior web accessibility consultant and technical director at The Paciello Group Europe.
Thank you for reading 5 articles this month* Join now for unlimited access
Enjoy your first month for just £1 / $1 / €1
*Read 5 free articles per month without a subscription
Join now for unlimited access
Try first month for just £1 / $1 / €1
The Creative Bloq team is made up of a group of design fans, and has changed and evolved since Creative Bloq began back in 2012. The current website team consists of eight full-time members of staff: Editor Georgia Coggan, Deputy Editor Rosie Hilder, Ecommerce Editor Beren Neale, Senior News Editor Daniel Piper, Editor, Digital Art and 3D Ian Dean, Tech Reviews Editor Erlingur Einarsson and Ecommerce Writer Beth Nicholls and Staff Writer Natalie Fear, as well as a roster of freelancers from around the world. The 3D World and ImagineFX magazine teams also pitch in, ensuring that content from 3D World and ImagineFX is represented on Creative Bloq.
