A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)


People with disabilities often navigate content without the use of a mouse. This makes navigating the content more tedious when there is repeating information, such as links and search bars that are in the tab order. When repeated interactive content is organized into logical groups and a means is provided to navigate to the different blocks, navigation as a whole becomes more efficient.

Navigation for screen reader users becomes much more efficient when WAI-ARIA landmarks are implemented. Screen reader users may navigate sequentially through landmarks using a hotkey sequence. Alternatively, a dialog containing a list of landmarks may be invoked from which users can jump directly to a selected landmark. Examples of available landmarks include (but are not limited to): banner, search, main, navigation, and region. Refer to the Web techniques section to learn more about the WAI-ARIA landmark requirements and how to implement them.


  1. Non-web documents and software should mark this checkpoint N/A. Many software user interface components have built-in mechanisms to navigate directly to / among them, which also have the effect of skipping over or bypassing blocks of content.
  2. Although not required by the checklist, being able to bypass blocks of content that are repeated within content directly addresses user needs identified in the Intent section for the WCAG Success Criterion, and is generally considered best practice.

Refer to Understanding SC 2.4.1 for more information (external link to WCAG).

Development Techniques

Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Instructions: Each item in this section represents a technique or combination of techniques deemed sufficient for meeting this checkpoint.

Note: This checkpoint is not applicable to software applications except the rarely occurring set of software programs.

Grouping repeated content in a way that can be skipped

See technology tabs for techniques that can be used for grouping content.

Creating links to skip blocks of repeated material using one of the following techniques:

Web (HTML, ARIA, CSS) techniques

Instructions: In addition to the General techniques, any item in this section represents a technique or combination of techniques deemed sufficient. Using multiple techniques is encouraged, and techniques are ordered from most to least preferred. One of the first two techniques must be used when possible.

Group repeated content in a way that can be skipped.

  1. ARIA11: Using ARIA landmarks to identify regions of a page (see ARIA11 supplement) IN COMBINATION WITH:
  2. Using HTML5 structural elements (supplemental) IN COMBINATION WITH
  3. H69: Providing heading elements at the beginning of each section of content
  4. SCR28: Using an expandable and collapsible menu to bypass block of content
  5. H70: Using frame elements to group blocks of repeated material AND H64: Using the title attribute of the frame and iframe elements
  6. Grouping sets of links, using one of the following:

Web supplements

The following techniques, examples and comments provide additional information beyond that available in the WCAG techniques. Where items supplement existing techniques, they are numbered accordingly (e.g., ARIA11).

ARIA11: Using ARIA landmarks to identify regions of a page

ARIA landmarks or HTML5 structural elements must be used where possible for all IBM applications. There are a number of requirements and recommendations to keep in mind when using landmarks:

  • All content on the screen must be designated with an ARIA landmark or region with no orphaned content.
  • Landmarks and regions can be embedded within others, such as a search bar located in a banner.
  • In a set of sibling DOM elements, only one each of the banner, main and contentinfo landmarks is permitted.
  • A contentinfo role is not permitted in a Web page without the presence of a main role.
  • Assign a WAI-ARIA banner role to content that is common throughout a Web site
  • If a search field is present, assign a WAI-ARIA search role to the field.
  • Avoid using the application landmark.

The following provide some more detailed guidance on less frequent uses of landmarks. See the Aria Authoring Practices for additional guidance, including the related topic of structural roles such as article, group and document

Assign a WAI-ARIA complementary role to content that complements the main content.

Elements that have a role="complementary" attribute contain content that complements the main content, but remains meaningful when separated from the main content. For example, a Web site designed to advertise a running event describes the race and supports online enrollment for the event. A region of the event's Web page contains the local weather forecast, so runners will know the weather conditions on the event day. The WAI-ARIA role="complementary" attribute is added to the element that encompasses the element(s) containing the weather information. An aria-labelledby attribute is added to the element to provide a visible label.

<h1 id="weather">Local weather forecast</h1>
<div role="complementary" aria-labelledby="weather">


Avoid using the application role.

With the release of ARIA 1.1, application ceased to be a landmark role, because it does not share the same navigational purpose of the other landmarks. It is now strictly used for document structure. Notwithstanding that change, the advice offered for role of application is similar. It should only apply to an entire region of the page that has a collection of UI components that form an application for which all keyboard handling is solely handled by the application.

Since assistive technologies recognize widgets and pass keyboard control to them, there is seldom a need to use role="application". However, if the application role is used, the following is required:

  • Web applications defining role="application" on any element, must handle all keyboard events for the element.
  • All instances of non-decorative, static text within an element that have a role="application" attribute must be separated by an element with a role="document" attribute.

The following example shows a role="application" attribute inside a <div> element followed by a role="document" attribute inside a <div> element that encompasses static text.

<title>Password Administration Application</title>


<div role="application">
<div role="document" aria-label="password administration">
<h1>Administer password</h1>
<p>This application may be used to administer your password.</p>




ARIA13: Using aria-labelledby to name regions and landmarks

A label drawn from the content of the page using aria-labelledby will be discoverable by more users than an non-visible use of aria-label. As well, labels formed with aria-labelledby will be readily translated when multiple languages are supported, while aria-label is more likely to be overlooked during Translation Verification Testing (TVT).

  • Elements having a role of region must always be assigned a label, either with aria-labelledby or aria-label.
  • No label is required for landmark regions where the purpose is obvious from the role (e.g., main, banner, search, or contentinfo )
  • If an ARIA landmark or region is used multiple times on a Web page, each instance must have a unique label specified using aria-labelledby or aria-label.
  • Do not include the landmark type as part of the label text (e.g., use "site", not "site navigation"), since a screen reader will automatically announce the role

ARIA20: Using the region role to identify a region of the page

When none of the standard WAI-ARIA navigational roles are appropriate, apply the region role to the area and label it using either aria-label or aria-labelledby

Two region landmark examples are presented below. An aria-label attribute labels one of the regions, and an aria-labelledby labels the other region.

<div role="region" aria-label="weather portlet">

<div role="region" aria-labelledby="t1">
<h1 id="t1">Stock Ticker Portlet</h1>


Using HTML5 structural elements

HTML5 has introduced “sectioning” elements which correspond to several WAI-ARIA roles. If using these HTML5 elements, you no longer need to add the corresponding WAI-ARIA role to the element. See supplements for ARIA 11 and ARIA 13 for applicable considerations for the corresponding ARIA role.

HTML5 element Corresponding ARIA role
<main> role="main"
<nav> role="navigation"
<header> role="banner"
<aside> role="complementary"
<footer> role="contentinfo"
<article> role="article"
<section> role="region"

Group links using lists

Group links using <ul> and <ol> elements. Using style sheets, you can modify the appearance and remove the bullets.

Group links using map elements

When maps involve clickable arias, group links inside the <map> elements. Assistive technology enables users to skip items in the map, such as navigation links, so that they can navigate quickly to the main content.

Mobile Native (iOS) techniques

Instructions: In addition to the General techniques, each item in this section represents a technique or combination of techniques deemed sufficient for meeting this checkpoint.

Use headings

Use headings to mark larger sections of the content.

Use menus

Instead of providing extensive navigation inside the content, create a separate page with a navigation menu.

Make navigation collapsible

Allow the user to collapse the navigation when it is not needed.

Container views

Use container views to separate navigation and the main content. VoiceOver users can quickly navigate from one container to the other.

Eclipse techniques

This checkpoint applies to a set of software programs. Because sets of software that meet this definition appear to be extremely rare, there are no specific Eclipse techniques for this checkpoint. Refer to the General techniques section.

Windows-based (MSAA+IA2) techniques

This checkpoint applies to a set of software programs. Because sets of software that meet this definition appear to be extremely rare, there are no specific Windows-based (MSAA+IA2) techniques for this checkpoint. Refer to the General techniques section.

Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation