Introduction

Why Focus on Semantic Structure and Navigation?

Semantic structure is the bedrock of accessible markup. Screen readers rely on the meaning of HTML elements and attributes to convey information to blind users.

It is through the semantic markup that browsers are able to parse accessibility cues and information through the accessibility API and pass that information on to users, through assistive technologies, such as screen readers.

Summary

Screen readers and other assistive technologies rely on the underlying semantic markup to convey meaningful information about the structure and content of web pages. Main principles covered in this module:

  • Unique page title
  • Navigation
  • Real headings
  • Logical outline
  • Real lists
  • Real data tables
  • Semantic markup appropriately

Page Title

Checklist Deque

Title for Every Page

  • The page <title> MUST be present and MUST contain text.
  • The page <title> MUST be updated when the web address changes.

Meaningful Page Title

  • The page <title> MUST be accurate and informative.
  • If a page is the result of a user action or scripted change of context, the text of the <title> SHOULD describe the result or change of context to the user.
  • The <title> SHOULD be concise.
  • The page <title> SHOULD be unique, if possible.
  • Unique information SHOULD come first in the <title>.
  • The page <title> SHOULD match (or be very similar to) the top heading in the main content.

Download Summary & Checklist

Tips & Tricks

  • Page Title <title>, relative to <h1>, SHOULD contain the generic website name
  • Best text to use for a link, <a href="">, is the title of destination page, <title> or <h1>
  • Most screen readers read aloud the title on screen load

Language

Checklist Deque

Primary Language of Page

  • The primary language of the page MUST be identified accurately on the <html> element.
  • The primary language of the page MUST be identified with a valid value on the <html> element.

Language of Parts within the Page

  • Inline language changes MUST be identified with a lang attribute.

Language Codes

  • The language code MUST be valid.

Download Summary & Checklist

Tips & Tricks

  • You MUST NOT change context on select (with a language selector) as people may not find the selector again when on another language. See also: On Input - WCAG

Landmarks

Checklist Deque

Creating Landmarks (HTML 5, ARIA)

  • Landmarks SHOULD be used to designate pre-defined parts of the layout (<header>, <nav>, <main>, <footer>, etc.).

Best Practices for Landmarks

  • All text SHOULD be contained within a landmark region.
  • Multiple instances of the same type of landmark SHOULD be distinguishable by different discernible accessible names (aria-label or aria-labelledby).
  • A page SHOULD NOT contain more than one instance of each of the following landmarks: banner, main, and contentinfo.
  • The total number of landmarks SHOULD be minimized to the extent appropriate for the content.

Backward Compatibility

  • Landmarks SHOULD be made backward compatible.

Download Summary & Checklist

Tips & Tricks

  • Be aware there are two different purposes for the <header> and <footer> elements:
    • One scoped to the body element and SHOULD only be used ones.
    • One scoped to the main element, a sectioning content element, or a sectioning root element other than body and can be used multiple times.
    • 2X Header - HTML AAM
    • 2X Footer - HTML AAM
  • ARIA-label Is A Xenophobe, translation services like Google's don't translate the aria-label attribute, so it's better to label using an element's text node. We can do this with aria-labelledby.
  • Using the element AND the ARIA variant together has the best backward compatible result for older browsers.
  • Adding aria-labelledby to role="region" adds it to the landmark list in certain AT.
  • Landmark role role="search" is not the same as widget role role="searchbox"

Headings

Checklist Deque

Real Headings

  • Text that acts as a heading visually or structurally SHOULD be designated as a true heading in the markup.
  • Text that does not act as a heading visually or structurally SHOULD NOT be marked as a heading.

Meaningful Text

  • Headings MUST be accurate and informative.
  • Heading text SHOULD be concise and relatively brief.

Outline/Hierarchy of Content

  • Headings SHOULD convey a clear and accurate structural outline of the sections of content of a web page.
  • Headings SHOULD NOT skip hierarchical levels.

Heading Level 1 Best Practices

  • The beginning of the main content SHOULD start with an <h1> element.
  • Most web pages SHOULD have only one <h1> element.

Download Summary & Checklist

Tips & Tricks

  • You SHOULD create structure first, than style as you see fit.
  • Although the The HTML5 Document Outline is not technically implemented in graphical browsers, it is the primary way of people navigation pages, so be sure to implement.

Tables

Checklist Deque

Semantic Markup for Tabular Data

  • Tabular data SHOULD be represented in a <table> element.

Table caption/name

  • Data tables SHOULD have a programmatically-associated caption or name.
  • The name/caption of a data table SHOULD describe the identity or purpose of the table accurately, meaningfully, and succinctly.
  • The name/caption of each data table SHOULD be unique within the context of other tables on the same page.

Table Headers

  • Table headers MUST be designated with <th>.
  • Data table header text MUST accurately describe the category of the corresponding data cells.

Simple Header Associations

  • Table data cells MUST be associated with their corresponding header cells.

Grouped Header Associations

  • Table data group headers MUST be associated with their corresponding data cell groups.

Complex Header Associations

  • Header/data associations that cannot be designated with <th> and scope MUST be designated with headers plus id.

Nested or Split Tables

  • Data table headers and data associations MUST NOT be referenced across nested, merged, or separate tables.

Table Summary

  • A summary MAY be provided for data tables.
  • A data table summary, if provided, SHOULD make the table more understandable to screen reader users.

Layout Tables

  • Tables SHOULD NOT be used for the purpose of purely visual (non-data) layout.
  • Layout tables MUST NOT contain data table markup.

Download Summary & Checklist

Tips & Tricks

Table in general

  • Mandatory role="presentation" on layout tables (better to never use layout tables!)
  • Accessible Names for cells by attributes like title="" !!!
  • Multiple tbody allowed
  • Closing elements not needed

Table Caption

  • The <caption> element
  • The <figcaption> element and aria-labelledby attribute
  • The aria-label attribute

Row and Column Headers

  • The <th> element
  • The scope="col" and scope="row" attributes

Column Groups & Row Groups

  • The colspan="" and rowspan="" attributes
  • The scope="colgroup" and scope="rowgroup" attributes

Headers + ID for Complex Data Tables

  • The id="" and headers="x y z" attributes
  • Do not nest tables

Lists

Checklist Deque

Semantic Markup for Lists

  • Lists MUST be constructed using the appropriate semantic markup.

Download Summary & Checklist

Tips & Tricks

  • Mark up a list as a real list
  • Add relation / accessible name
  • Example accessible name calculation for input type="text", input type="password”, etc.
    1. Use aria-labelledby
    2. Otherwise use aria-label
    3. Otherwise use the associated label element
    4. Otherwise use the placeholder attribute
    5. Otherwise use the title attribute
    6. If none of the above yield a usable text string there is no accessible name
  • Accessible Name and Description calculation
  • Accessible Name and Description: Computation

Jump to:

Guidelines

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Iframes

Checklist Deque

Frame titles

  • Frames MUST have a <title> element with text.
  • The iframe title MUST be accurate and descriptive.
  • Frames MUST have a unique title (in the context of the page).

Page Title Within an Iframe

  • The source page of an <iframe> MUST have a valid, meaningful <title>.

Semantic structure across <iframe> elements

  • Screen readers allow cross-frame navigation of semantic elements.
  • The heading hierarchy of an <iframe> SHOULD be designed to fit within the heading hierarchy of the parent document, if possible.

Hiding iframes that don't contain meaningful content

  • Hidden frames or frames that do not convey content to users SHOULD be hidden from assistive technologies using aria-hidden="true".

Download Summary & Checklist

Tips & Tricks

Frame Titles

  • Always provide a title using the title attribute
  • Enclosed Document Also Has a Meaningful <title> Tag

Elements & Structure Across Frames

  • Is treated (almost) as if it is part of the same document that contains it
  • Pay Attention to Heading Hierarchy

Hiding Iframes

  • aria-hidden="true"
  • display:none

Jump to:

Advanced

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Other Semantic Elements

Checklist Deque

<strong> and <em>

  • Critical emphasis in the text SHOULD be conveyed through visual styling.
  • Critical emphasis in the text SHOULD be conveyed in a text-based format.

<blockquote> and <q>

  • The <blockquote> element SHOULD be used to designate long (block level) quotations.
  • The <blockquote> element SHOULD NOT be used for visual styling alone.
  • The <q> element (for inline quotations) SHOULD NOT be used as the only way to designate quotations.

<code>, <pre>, etc.

  • Code SHOULD be marked with the <code> element.
  • Blocks of code SHOULD be marked with the <pre> element.

Strikethrough/Delete and Insert

  • Strikethrough text SHOULD be marked with the <del> element.
  • Critical strikethrough text MUST be supplemented with a text-based method to convey the meaning of the strikethrough.
  • Text designated for insertion SHOULD be marked with the <ins> element.
  • Critical text designated for insertion MUST be supplemented with a text-based method to convey the meaning of the insertion.

Highlighting (<mark>)

  • Highlighted text SHOULD be marked with the <mark> element.
  • Critical highlighted text SHOULD be supplemented with a text-based method to convey the meaning of the highlighting.

Download Summary & Checklist

Tips & Tricks

Blockquote

Abbreviations

  • Reasonable support
  • write out the full abbreviation the first time that it appears
  • <acronym> is phased out, use <abbr>

Elements NOT announced by Screen readers (but still important!)

  • Reasonable support
  • <strong> - strong emphasis
  • <em> - emphasis
  • <q> - inline quotation
  • <pre> - preformatted text
  • <code> - computer code (such as HTML, JavaScript, PHP, etc.)
  • <address> - contact information for the creators of a document
  • <time> - date and/or time
  • LVTF 3.5 Identifying Elements

Emphasizing Content

  • Good practice
    • Increase font size
    • Make the font bold using <em> and <strong> or CSS
    • Change the color of the font (* watch contrast and not only means of conveying important information)
    • Put an outline around the content
    • Put a background color behind the content
    • Put an image next to the content
    • Put extra "white space" around the content with CSS padding or margin
  • Bad practice
    • Make the font italic using <i> or <em> or CSS
    • USE ALL CAPITAL LETTERS
    • *Put asterisks around words or phrases*
  • Non-Visual Methods
    • Write the word "Important" (or similar)
    • Put the word "Important" in the alt text
    • Hide the word "Important" from visual users by using CSS if whished for
    • Put the content in a heading

Jump to:

Guidelines

Advanced

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Parsing and Validity

Checklist Deque

Conflicts and duplicates

  • IDs MUST be unique within a web page.
  • Names of elements SHOULD be unique within a web page.

Parent-child relationships

  • Markup SHOULD adhere to required parent-child relationships of elements and attributes.

Deprecated Markup

  • Deprecated markup SHOULD NOT be used.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented