HTML5 introduces new section elements. The new elements include header, footer, section, article, nav and aside. What is the accessibility potential of these new elements for users of assistive technology such as screen readers?
To understand the potential of these new elements to provide a better experience for screen reader users it is useful to understand how the semantics of current structural elements such as the h1, h2, h3, h4, h5, and h6 elements is exposed to users.
How HTML elements are supported by screen readers
Typical support patterns of HTML elements by screen readers:
- Identification of an element by role as the user moves through the content.
- Announcement of the text content of an element.
- Announcement of the start and end of an element.
- Change in voice as the content of an element is announced.
- Announcement of an elements accessible name and/or description
- Announcement of states and properties.
- Emission of a beep or other sound when an element with a particulat state or property receives virtual focus.
- Instructions on how to operate interactive elements such as form controls.
- Navigation of elements by keyboard and “quick access” lists of a particular elements, list items are linked to each instance of an element on the page.
Note: The combination of patterns supported varies from element to element and support for a particular element varies between screen reader software.
Examples of HTML element support by screen reader software
The following table illustrates support and interaction features for a number of structural HTML elements. The information is based on support for these elements by the JAWS screen reader.
| Element | Support behaviour | keystrokes |
|---|---|---|
| blockquote | Navigate by and list instances of blockquote element in the document. Announces when the virtual cursor enters or exits a blockquote element. If the cite attribute is present, its value is announced. |
|
h1 to h6 |
Navigate by and list instances of h1-h6 elements in the document. Heading level announced “heading level x + heading text content” when the heading receives virtual focus. |
|
p |
Navigate by and list instances of p elements in the document. When the element recieves virtual focus the content is announced. |
|
ol, ul, li |
Announces “list of x items” at the start of a list and “list end” at the end of a list. For ordered lists the counter is announced before the content of each list item. for unordered lists “bullet” is announced before the content of each item. |
|
What form will support for the new HTML5 section elements take?
Authors can already apply ARIA roles to section elements where appropriate.
One possibility is that the elements can be mapped to WAI-ARIA roles, most of which are supported by screen readers now. Browser implementors are starting to add experimental support for some of the new elements. Authors can already apply ARIA roles to section elements where appropriate:
Note: there are some issues with outdated buggy assistive technology not playing well with HTML5 elements on their own or when ARIA roles are added.
| HTML5 element | WAI-ARIA role |
|---|---|
| article
<article role=”article”> |
article |
| footer
ONLY when not a descendent of an article or section element. In other words, only the main footer for a page. <footer role=”contentinfo”> |
contentinfo |
| header
ONLY when not a descendent of an article or section element. In other words, only the main header for a page. <header role=”banner”> |
banner |
| nav
<nav role=”navigation”> |
navigation |
| aside
<aside role=”complementary”> |
complementary |
| section
<section role=”region”> |
region |
h1, h2, h3, h4, h5, and h6
These elements have been around for ages, so where they can be mapped in browsers they already are, adding a heading role is an unecessary duplication. |
NONE |
| address
<address role=”contentinfo”> |
contentinfo |
| hgroup
Both the semantics and the status of the hgroup element in HTML5 are undecided, so best leave it out for the time being. |
NONE |
body
This element has been around for ages, so where it can be mapped in browsers it already is, adding an ARIA document role is an unecessary duplication. While the ARIA application role can also be used on body it is advised to do so with caution. |
NONE |
ARIA Landmark Roles
A subset of HTML5 section elements map onto ARIA landmark roles. Landmark roles already have good support in screen reader such as JAWS, VoiceOver (on iOS), NVDA and Orca. So when implemented in browsers some of the new section elements will be included as ARIA Landmarks without the need to explicitly apply an ARIA role attribute. For the other new section elements, how and when they will be accessibility supported is less clear.
Comments
Great writeup Steve. Thanks!