HTML5 Accessibility Chops: section elements

Posted on Wednesday, 9 March 2011 by Steve Faulkner

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.
  • next blockquote Q
  • previous blockquote SHIFT+Q
  • blockquote list CTRL+INSERT+Q
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.
  • List Headings INSERT+F6
  • Next Heading H
  • Prior Heading SHIFT+H
  • First Heading ALT+INSERT+HOME
  • Last Heading ALT+INSERT+END
  • Next Heading at Level 1 through 6
  • Prior Heading at Level SHIFT+1 through 6
  • First Heading at Level ALT+CTRL+INSERT+1 through 6
  • Last Heading at Level ALT+CTRL+INSERT+SHIFT+1 through 6
  • Announce heading of the section of the page you are in INSERT+T
p Navigate by and list instances of p elements in the document. When the element recieves virtual focus the content is announced.
  • Next Paragraph P
  • Previous Paragraph SHIFT+P
  • List Paragraphs CTRL+INSERT+P
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.
  • Move to Next List L
  • Move to Prior List SHIFT+L
  • Select List F8
  • List All Ordered, Unordered, and Definition Lists CTRL+INSERT+L
  • Move to Next Item in a List I
  • Move to Prior Item in a List SHIFT+I

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.

Recommended ARIA role mappings for HTML5 section elements
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.


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

I'm happy to be a technical reference if someone would like reassurance of the depth and breadth of your organization's knowledge and experience. It is unparalleled.

Dominic Mazzoni, Software Engineer – Accessibility, Google