Use semantic elements for regions and content

Semantic markup for page content provides structure when pages are accessed using assistive technologies or when the pages’ styling is changed for readability purposes. Screen readers can also use structural markup as navigation features, such as by allowing for heading-based, list or table navigation or by allowing users to navigate between content areas such as main page content, navigation menus, or page footer.

When semantic markup is not used and the page’s semantic structure is implied by only visually, such as by making text larger and bolder to look like a heading, the page’s semantic meaning is lost.

  • Identify section headings and heading hierarchy using markup. Use HTML heading elements (h1 through to h6) to identify headings. Make sure that the heading hierarchy is logical. Section headings should succinctly describe the content that follows them, and heading elements should never be empty.
  • Identify page sections and landmarks. Use ARIA landmark roles to identify the start of page content areas such as the top banner area, main content, navigation bars, footer, and search areas. For now, because of limited accessibility support, include ARIA landmark roles even when you’re making use of HTML5 section elements.
  • Identify lists using markup. Use unordered list markup (ul and li) for lists where there is no logical order implied, including navigation lists and menus. Use CSS to customize or suppress bullet points. Use ordered lists (ol and li) for numbered lists. Use definition lists for lists that are key/value pairs.
  • Mark up data tables using table markup. Use the table element along with tr elements for its table rows and td elements for its data cells. Use the th element to identify row and column headers. For more complex tables, where headers span more than one cell, programmatically associate the table’s data cells with their corresponding headers, such as by using the scope attribute.

Testing

  • For each heading, is the heading identified in markup? If so, is the heading given a suitable heading level?
  • For each content area on a page, is the start of the content area identified with a suitable ARIA landmark role?
  • For each data table on a page, are the rows and columns contained in table markup? Are row and column headers identified using th elements? If a caption is provided, is it associated with the table using a caption element?
  • For each list of items on a page, including any navigation lists, is the list coded using HTML list elements? Are the list’s bullet points styled using CSS rather than images of bullets in markup?

Resources

✎ Technique: The main landmark

Landmarks help assistive-technology users navigate to and between areas of a page, and they improve the efficiency of in-page navigation.

Landmarks are to sections what continents are to countries—they help break the interface up into a few large, semantically distinct areas such as headers, footers and navigation blocks. The main landmark defines the unique content of the page: the most likely reason a user visited the page in the first place.

Examples

Using the WAI-ARIA landmark role

WAI-ARIA provides a set of landmark roles that can be used to identify different semantically meaningful sections of a page, like the header and footer. The attribute role="main" should be used to identify the start of the page's unique content, and it should be used on a block level element, like a div.


<div role="main">
  <!-- the main, unique content of the page -->
</div>

Using the main element

It's quicker to just use the main element. In this case, the ARIA role and the equivalent HTML5 element provide exactly the same semantics to screen-reader users. Modern screen readers provide landmark navigation shortcuts; for example, a JAWS user can navigate to main landmarks using the 'q' key, which allows them to skip preamble such as the site logo and navigation.


<main>
  <!-- the main, unique content of the page -->
</main>

Video: Landmark navigation using JAWS

✎ Technique: Heading structure

The heading levels (1-6) are often considered a way of describing and determining the “importance” of a heading, with h1 being the most important. This might be reflected in the visual appearance of headings—higher-level headings typically appear as bigger and bolder text than lower-level headings.

But you can't just put an “important” heading anywhere. Its heading level relates to how much content it refers to, and that has to do with structure.

Reflecting structure accurately allows screen-reader users to use their screen reader's heading-navigation feature to navigate by heading level, building up an idea of document structure. It also ensures that, for people who use custom stylesheets, heading structure is preserved even when the appearance of headings is changed.

Examples

Good example

Heading levels determine the structure of a page, and this structure depends on sections belonging to subsections. Using heading levels to describe this relationship is quite simple: An h2 would head a section that may contain subsections. To show that these are subsections, you would code their headings with an h3.


<h2>Section Heading</h2>
<!-- section content here -->
  <h3>Subsection heading</h3>
  <!-- subsection content here -->
  <h3>Another subsection heading</h3>
  <!-- subsection content here -->

In a table of contents, this structure might be illustrated using indentation, like so:

  • Section Heading
    • Subsection heading
    • Another subsection heading

Bad example

To create a coherent structure, you should not skip heading levels. That is, a section headed with an h3 should not contain immediate child subsections headed with h5 or h6.


<h3>Section heading</h3>
<!-- section content here -->
  <h5>Subsection heading</h5>
  <!-- does this content belong directly to the h3 section or not? -->
  <h6>Another subsection heading</h6>
  <!-- this will be considered a subsection of the h5 section headed above -->