Providing structure in Web pages and documents

Overview

In order to understand a document, everyone depends on understanding its structure. For example, consider the current web page. It includes a banner, multiple navigation menus, and the main content which you are reading currently. The main content is organized into sections marked by headings and subheadings, and the content within those sections is comprised mostly of paragraphs and lists. Sighted users understand all these relationships at a glance, based largely on visual characters such as the size and position of content relative to other surrounding content.

Screen reader users need to understand this structure just like everyone else. Therefore, they are dependent on content authors clearly identifying the headings, paragraphs, lists, tables, banners, menus, and other features as exactly what they are. In the world of web design this is called semantics, building a page using web elements that define the role of the object. For example, when adding a top-level heading to a web page, use the built-in Heading 1 feature that your authoring software provides. If you just make the text big and bold, it may look like a heading but it isn’t really a heading.

The remainder of this page describes a few important steps for ensuring your documents have good structure that is accessible to assistive technology users.

Techniques

Headings

Headings provide a way for site visitors to quickly see how a page is organized, but did you know they can also provide the same benefit to non-sighted users? A properly implemented heading structure serves two purposes for these users:

  1. They provide an outline of the page. This allows users to understand how the page is structured and how the sections relate to one another.
  2. They provide targets so users can jump from heading to heading with a single keystroke (e.g., the letter “H” in some screen readers).

According to current web standards, as suggested by the World Wide Web Consortium, web pages should follow a hierarchical heading structure, without skipping levels. That is, each heading should not be presented without its parent heading. So you shouldn’t have an h3 heading without an h2 heading or an h2 heading without an h1 heading. This allows assistive technology users to skim the page by tabbing through headings in a logical manner to get to the information they are looking for without having to wade through the page’s entire text from top to bottom. When headings do not appear in order it can be disorienting to users who cannot see your page.

When headings appear out of order, it can be disorienting for the person who cannot see your page. It’s like finding the appendices in the middle of a document and then discovering the table of contents has been placed after the glossary.

It is never a good idea to use headings for formatting purposes. It is always better to use headings for their semantic, intended purpose and use CSS for formatting text instead.

How to Add Headings Using HTML

The following are best practices for using HTML headings:

  • Use <h1> for the main heading of the page. For most pages, there will be only one <h1>.
  • Use <h2> for subheadings beneath the main heading.
  • Use additional levels of headings (<h3> through <h6>) as needed if there are additional levels of sub-headings within your web page content.
  • Ensure headings form an outline of your page content; avoid skipping heading levels.

How to Add Headings in WordPress or Drupal

WordPress, Drupal, and other content management systems all have a rich text editor for authoring content. The editor includes a toolbar with a format selector. Use this format selector to select the appropriate heading level for your content.

How to Add Headings in Microsoft Word

In Microsoft Word, add headings using the built-in heading styles (Heading 1, Heading 2, etc.) available in the Ribbon. To change the appearance of any of these heading styles, simplify right click on the style button and select “Modify”.

Screen shot showing heading styles in Microsoft Word

Lists

When creating content, it is important to recognize when your content is a list of items. For example, AHA web pages often include lists of links, events, research, programs, and much more. If lists are created as lists, screen readers can inform their users that they have landed on a list and can provide additional information such as the number of items in the list. This is extremely helpful information for users when they’re deciding whether to read on.

All document authoring environments include features that enable you to add bulleted lists or numbered lists, typically from a toolbar.

Screen shot of rich text editor in Canvas, with bulleted and numbered list buttons highlighted

Tables

Tables should be used only for presenting rows and columns of data, not for organizing the layout of the page. When creating a data table, understand that sighted users can easily scan and understand the table by looking at a given data cell along with its row and column headers, and comparing that with other data cells. People who are unable to see the table do not have access to all the visual cues that make this possible. Therefore, they depend on the table author to have provided markup that explicitly defines the roles and relationships of all the parts of the table. For example, all column headers must be identified as column headers and row headers must be identified as row headers.

See the WebAIM article Creating Accessible Tables for specific HTML techniques.

Accessible Rich Internet Applications (ARIA) Landmark Roles

ARIA is a W3C specification that provides a means by which web developers can define the roles, states, and properties of user interface components so this information is exposed to assistive technologies.

One of the easiest ARIA features to implement, and one that provides significant immediate benefits to screen reader users, is landmark roles. Each of the eight roles represents a block of content that occurs commonly on web pages. They are used by simply adding a relevant role attribute to an appropriate container within the HTML mark-up. Once added, screen reader users can quickly jump to that section of the page. The eight roles are:

  • role=”banner”
  • role=”navigation” (e.g., a menu)
  • role=”main” (the main content of the page)
  • role=”complementary” (e.g., a sidebar)
  • role=”contentinfo” (meta data about the page, usually the footer)
  • role=”search”
  • role=”form”
  • role=”application” (a web application with its own keyboard interface)

If a role is used more than once on a page, the aria-label attribute should also be used in order to distinguish between the two regions. For example, a web page might have two navigation regions, one with aria-label="Main Menu" and the other with aria-label="Audience Menu".

Caution: Be Careful Using role=”application”

When role="application" is used, there is an expectation that the application has its own model for navigating and operating all controls by keyboard, and help text is easily available so users can learn the keystrokes. When assistive technologies encounter content that’s marked up with role=”application”, they stop listening for users’ keystrokes and hand off all functionality to the application. This can be problematic as it defies users’ expectations. Keys that normally perform certain functions when using their assistive technology suddenly stop providing that functionality.

Therefore you should use role="application" only when an application has been carefully developed with accessibility in mind, and steps have been taken to inform users of what to expect.

Forms

Most forms include form fields accompanied by labels or prompts. In order to figure out which labels accompany which fields, sighted users rely on visual cues such as relative position and proximity. For users who are unable to see the form, the relationships between labels and fields must be explicitly made within the code. For details about how to do this, see our page dedicated to Accessible Forms.

References