Skip to main content IDRC Resources

Understanding Web Accessibility

Principle 2: Operable

Principle 2: Operable - User interface components and navigation must be operable.

If you follow Principle 1 guidelines, visitors will be able to perceive the content of your Web site. Principle 2 takes things to the next level: Once visitors can perceive the content, they must be able to act on it: in other words, the content must be operable.

There are four "operable" guidelines:

  1. Make it possible to perform all tasks with a keyboard instead of a mouse.
  2. Give users enough time to perform tasks.
  3. Avoid information that flashes or flickers, as it may trigger seizures.
  4. Make it possible for users to navigate, find content, and figure out where they are.

Reasons understand why it is important to prevent operability barriers

Guideline 2.1 Keyboard Accessible

Why must Web pages be accessible without a mouse?

Some people cannot use, or have difficulties using a mouse. For example:

  1. The mouse is designed to be guided by eye. Users who are totally blind cannot see the mouse pointer.
  2. Mouse pointers tend to be small. Individuals with low-vision may have trouble spotting the mouse pointer on the screen.
  3. Someone with a learning disability may find the movements of the mouse pointer distracting, or may lack the hand-eye coordination needed to reliably use a mouse.
  4. Some people have trouble remembering when to left click, double click, and right click.
  5. A person who has hand tremors may be unable to hold the mouse steadily enough to click small screen objects. Some seniors who do not have hand tremors report difficulties holding the mouse steady enough to double click.

Furthermore, the mouse is not usually the most efficient way to perform tasks. Pressing a few keys on the keyboard is often faster, easier, and more accurate than pointing and clicking. Many "average" computer users know a few keyboard shortcuts, and some "power users" rarely touch the mouse at all. (More and more browsers have features that make it quick and easy to surf the Web using only the keyboard.)

Guideline 2.2 Enough Time

Why do some people need extra time on the Web?

People who have disabilities may need longer to complete tasks than people who do not have disabilities. They need extra time to react physically, think, remember, read, or zero in on pertinent information.

Individuals who rely on assistive technologies often need time to find what they are looking for on a Web page. For example, sighted users can understand a page at a glance, but screen reader users often need to explore a page before they understand how the page is organized.

As people age, they need more time to process information. In addition to helping seniors, flexible time limits benefit individuals who are not technically-savvy, are new to electronic information systems, or are not native speakers of the language on the site.

Guideline 2.3 Seizures

What do I need to know so that content does not cause seizures?

People who have epilepsy can have seizures when exposed to flashing or flickering lights. There are three causes of flickering lights on computer screens:

  1. Flashes can be caused by the display.
  2. Flashes can be caused by the computer and how it renders images and other content.
  3. Flashes can be caused by the content itself.

Although Web authors have no control over the first two, they can ensure that flicker is not caused by the content, such as a movie of strobe flashes, or an animation of rapid-fire explosions.

To conform at Level AA, WCAG 2.0 describes how to determine safe values for flashing content. To conform at Level AAA, a page must avoid all flashing content.

Guideline 2.4 Navigable

Why is it important to help visitors navigate?

Navigation on Web pages serves two purposes:

  1. To tell users where they are.
  2. To let users know how to go somewhere else.

These tasks are often more difficult for people with disabilities. This section describes how to help visitors find content and keep track of their location. The same rules that simplify navigation for people with disabilities also improves navigation for users who do not have disabilities.

Guidelines

Guideline 2.1 Keyboard Access

Make all functionality available from a keyboard.

2.1 Level A

  • 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

    The computer mouse is ubiquitous today, but before 1984, most computer users did not use one. The mouse only began to become pervasive during the mid-1990s. In recent years, other mouse-like devices have been introduced, including trackballs, touchpads, and trackpoints. Now, a mouse (or a similar pointing device) comes with every computer, and most people would be lost without one.

    Yet some people cannot use — or have difficulties using — a mouse. For example:

    • An individual with low-vision may have trouble locating the mouse pointer on a screen.
    • A person who is totally blind cannot see the mouse pointer at all.
    • Someone with a learning disability may find the movements of the mouse pointer distracting.
    • A person who has hand tremors may be unable to hold the mouse steadily enough to click on small screen objects.

    In addition, there are individuals who find that pressing a few keys on the keyboard is faster, easier, and more accurate than pointing and clicking. Many "average" computer users know a few keyboard shortcuts, and some "power users" rarely touch the mouse at all.

    Many tasks that are typically done with a mouse can be (or should be) easily keyboard accessible, including "clicking" hypertext links, drawing straight lines and regular geometric shapes, and re-sizing windows. There are even keyboard equivalents for dragging and dropping. But when a task cannot be performed without a mouse, some people will be prevented from taking full advantage of a site.

    WCAG 2.0 acknowledges that some tasks cannot reasonably be done with a keyboard, such as real-time flight simulations. Tasks that depend on continuous, time-sensitive movements that do not have start and end points are excluded. But the highest conformance level that such a Web site can attain for Guideline 2.1 is Level A. To achieve Level AAA, all content must be keyboard accessible. See 2.1.3.

    Many of the assistive technologies that people with disabilities rely upon emulate the functionality of a keyboard. Content that is accessible by keyboard can also be accessed by devices that emulate keyboards. For this reason, the ability to interact with Web content using only a keyboard is core to Web accessibility.

  • 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

    A "keyboard trap" is an area of a Web page where a person gets stuck when navigating without a mouse. You can navigate to a spot by pressing a sequence of keystrokes, but you cannot leave — unless you use a mouse.

    Keyboard traps usually occur when applications are embedded in Web pages. The main culprits are text editors, spreadsheets, and media players. For example, on some on-line forums, it is possible to navigate to a built-in text editor by repeatedly pressing the Tab key, but impossible to exit it without a mouse.

    If there is a non-intuitive keystroke (or series of keystrokes) to escape a keyboard trap, let users know about it. One option would be to provide instructions within the embedded application: "To exit this spreadsheet, press Ctrl + W (Windows) or Command + W (Macintosh)."

2.1 Level AAA

  • 2.1.3. Keyboard (No Exception): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

    This is a more stringent version of 2.1.1 that states that everything, without exception, must be keyboard accessible.

    A Web page that has, for example, an embedded helicopter simulator that cannot be piloted without a mouse may conform at Level A. However, if the developers of the simulation devise a way to pilot the helicopter using the arrow keys, the spacebar, the Enter key, and the Shift key, then the site may conform at Level AAA.

Additional Resources

For additional information see:

Guideline 2.2 Enough Time

Provide users enough time to read and use content.

2.2 Level A

  • 2.2.1 Timing Adjustable:For each time limit that is set by the content, at least one of the following is true:
    • Turn off: The user is allowed to turn off the time limit before encountering it; or
    • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
    • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
    • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
    • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
    • 20 Hour Exception: The time limit is longer than 20 hours.

    People who have disabilities sometimes need more time to complete tasks than people who do not have disabilities. They may need longer to think, remember, read, react physically, or zero in on pertinent information. Or they may rely on assistive technologies that increase the time they need to write or read.

    Many people, as they age, tend to need more time to process information. In addition to helping seniors, flexible time limits benefit individuals who are not technically-savvy and/or who are new to electronic information systems.

    2.2.1 lists three ways to ensure that people are not prevented from completing tasks due to lack of time:

    • Allow users to turn off time limits.
    • Allow users to increase the default time limit.
    • Give users ample warning when their time is about to expire.

    Exceptions are allowed. For example, it may not be possible to change time limits for time-sensitive events such as on-line auctions or tests that measure the speed of reaction.

    In situations that are not time sensitive, 20 hours is given as an upper time limit.

  • 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:
    • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
    • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

    This section applies when content conveys a sense of motion, or updates itself automatically. Content that moves or changes may distract some users.

    Examples of content that conveys a sense of motion:

    • Animations
    • Movies
    • Games
    • Scrolling stock tickers

    Automatically updating content is often confined to one area of a Web page. Familiar examples include:

    • Stock market updates
    • Weather updates
    • News updates
    • Slide shows that automatically advance from one slide to the next

    Requirement when content conveys a sense of motion:

    If the moving content starts automatically, lasts longer than five seconds, and is presented in parallel with other content, include a mechanism that allows users to pause, stop, or hide the content.

    Requirement when content automatically updates itself:

    If it automatically updated content begins the update cycle automatically, and is presented in parallel with other content, include a mechanism that allows users to pause, stop, hide the content, or control the update frequency.

    Examples of how to meet this requirement

    1. A Web site has an animation that demonstrates how to use a fire extinguisher. The animation has "pause" and "restart" buttons.
    2. A Web site has an advertisement. To draw attention, the advertisement starts to blink when a page loads. But the blinking stops after five seconds.
    3. A blog features a slide show of the author's bicycle trip through the Alps. Next to the slide show is a control that lets visitors adjust the update speed, from zero second to 30 seconds per slide.

2.2 Level AAA

  • 2.2.3 No Timing: Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events.

    Many people need extra time to perform tasks. Some individuals take longer to think, remember, process information, react physically, or deal with the quirks of assistive technologies. If completing a task within a time limit is not essential, then give people all the time they need.

    This requirement does not apply to events that occur in real-time, such as fast-paced auctions, multi-player gambling sites, and similar competitive events.

    Examples of how this requirement can be met

    1. An on-line test: Students can take as much time as they need to complete the questions.
    2. A game: A game is designed to allow players to compete against the clock, or to take turns. When they take turns, there are no time limits.
    3. An online auction: Each bidder is allowed to submit one bid. Bids are accepted over 24 hours. Once the bidding is closed, the highest bid wins.
  • 2.2.4 Interruptions: Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency.

    Some Web sites feature late-breaking news, weather reports, stock quotes, and so on. There are people, however, who are distracted by frequent updates, or do not want them.

    Let users postpone automatic updates by giving them the option to disable automatic content updates, and/or to specify the frequency of automatic content updates.

    For example, the home page of a news service displays headline updates every 15 minutes. To meet this requirement, the Web authors added a drop-down list so that visitors can choose how often to refresh headlines. It has four options: Every 15, 30, or 60 minutes; or never.

    It is OK to update the content in the event of an emergency, including threats to life, health, safety, or property.

  • 2.2.5 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.

    Completing forms, entering credit card information, and using Web-based email programs are everyday activities on the Internet. For security reasons, Web sites usually limit the period of inactivity before a session expires. These time limits cause problems for people who need extra time to input information, especially when they are forced to begin "from scratch" every time.

    Make it possible for visitors to continue a transaction after a session expires without losing the information they already entered. Doing this will allow more people to complete authenticated transactions.

    Samantha Smith, who has limited use of her hands, logs into a shopping site. She chooses groceries and proceeds to the check-out. It takes her so long to type her credit card number that the session expires. After logging in again, her grocery order is intact, and the check-out screen contains all of the information that she had entered up to the point that the session expired. No data was lost because the server stored her submission even though the session had timed out.

Additional Resources

For additional information see:

Guideline 2.3 Flashing and Seizures

Do not design content in a way that is known to cause seizures.

2.3 Level A

  • 2.3.1 Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

    People with a form of epilepsy called "photosensitive seizure disorder" have seizures when exposed to flashing or flickering lights. Many colours can cause these seizures, but flashing red lights are known to trigger seizures more readily than other colours.

    There are three causes of flickering lights on computer screens:

    1. Flashes can be caused by the display.
    2. Flashes can be caused by the computer and how it renders images and other content.
    3. Flashes can be caused by the content itself.

    Web authors have no control over the first two (which can be addressed by choosing appropriate display and computer hardware.) To meet this requirement, Web authors must ensure that flicker is not caused by the content itself, such as a movie of strobe flashes, or an animation of rapid-fire explosions.

    2.3.1 allows content to flash if it is dim enough and confined to a small area. W3C publishes formulas for determining safe values for "general flash and red flash thresholds." But even these "safe" values can trigger seizures. The next section, 2.3.2 is more stringent.

2.3 Level AAA

  • 2.3.2 Three Flashes: Web pages do not contain anything that flashes more than three times in any one second period.

    Some people are so sensitive that it is not possible to completely prevent them from having seizures. However, by eliminating all three-per-second flashing everywhere on the screen, the chances of a person having a seizure are reduced.

    2.3.1 allows flashing if it is dim enough or is confined to a small enough area. 2.3.2 does not allow flashing greater than three per second, regardless of brightness or size.

    Even a single flashing pixel violates this criterion. The intent is to guard against flashing areas that are larger than a single pixel; but since an individual may require magnification or high contrast settings, the prohibition is against any flashing.

Additional Resources

For additional information see:

Guideline 2.4 Different Ways to Navigate

Provide ways to help users navigate, find content, and determine where they are.

2.4 Level A

  • 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

    People who cannot use a mouse often use the Tab key to navigate around Web pages: they press Tab to move "forward" through the content; Shift + Tab to move "backwards"; and Enter to activate links and buttons. At best, Tab key navigation is a tedious way to get around, but for some non-mouse users, it is the best option.

    Many Web pages have content that is repeated on every page. For example, a site may have the same navigation links on the top of all pages. If there are 20 navigation links, a non-mouse user could be forced to press the Tab key 20 times just to reach the main content — and do this on every page.

    By meeting this requirement, keyboard users can go directly to the main content without the need to press a lot of keys. A simple way to achieve this is to place a "Skip to Content" link as the first link on every page.

    "Skip to Content" links also benefit people who use portable Web-enabled devices, such as cell phones. Because the screens of these devices are so small, it may be more convenient to click a "Skip to Content" link than to scroll through many screens to reach the content.

  • 2.4.2 Page Titled : Web pages have titles that describe topic or purpose.

    If you check the narrow "stripe" that runs along the top edge of your browser window, you will find the name of the browser ("Internet Explorer," "Mozilla Firefox," "Safari," and so on); "Maximize," "Minimize," and "Close" icons; and a description of the Web page.

    These descriptions are called "titles," and every Web page has one. Well-written titles help users orient to a Web site. A good title summarizes a page in a few words, so users do not have to read an entire page to know what it is about. Many screen reader users take advantage of titles to keep track of where they are. Pressing a hotkey causes the screen reader to "read" the title out loud.

    Descriptive titles help people interpret search engine results. Many search engines, including Google, display "hits" as a list of page titles.

    When writing Web page titles, it is recommended that each title:

    1. Identify the site
    2. Identify the subject of the page
    3. Make sense
    4. Be short
    5. Be unique for the site

    Examples of descriptive titles:

    For a page containing a chocolate brownie recipe on www.yummydesserts.com:
    [blue]Yummy Desserts - Chocolate Brownie Recipe[/blue]

    For a chapter in a textbook called "Gender and Stereotype":
    [blue]Gender and Stereotype, Chapter 3: The Origins of Patriarchy[/blue]

    For a Web-based banking application that lets customers retrieve monthly statements:
    [blue]Bank of Hudson Bay, Account 10001, Statement for October 2010 [/blue]

  • 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

    Content should make sense when navigating by keyboard. Many people who cannot handle (or have difficulty handling) a mouse rely on "tab-key navigation" to interact with Web pages: they press Tab to move "forward" through the content; Shift + Tab to move "backwards"; and Enter to activate links and buttons. Knowing a handful of other hotkeys makes it possible for non-mouse users to interact with any Web page.

    When navigating through a Web page via keyboard, people should encounter information in a logical order. This is especially important for screen reader users, who cannot observe how pages are visually organized. When designing for the Web, strive to make the visual organization and the tabbing order correspond.

    This example illustrates two versions of the same form. The only difference is the tabbing order (shown as red numbers). The tabbing order on the first form is unambiguous: you provide your name, age, and citizenship, followed by your child's name, age, and citizenship.

    A form with logical tabbing order. The six fields are in this order: Your name, age, and citizenship. Your child's name, age and citizenship.

    The tabbing order on the second form is confusing. When completing the form, you alternate between providing information about yourself and your child. If you cannot see the screen, it is hard to tell which "Name" field corresponds with which "Age" field and which "Citizenship" field. After completing the second field, "Child's name," the next field encountered is "Age." There is no way to infer from the tabbing order whether this means your or your child's age.

    A form with illogical tabbing order. The six fields are in this order: Your name, your child's name; your age, your child's age; your citizenship, your child's citizenship.
  • 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

    Links that make sense by themselves enhance usability for everybody. The preferred way to meet the requirement is write link text that clearly indicates what to expect if the link is followed. For example:

    On a recipe Website:

    [blue]

    [u]Appetizers[/u]

    [u]Soups[/u]

    [u]Main Courses[/u]

    [u]Desserts[/u]

    [/blue]

    On an on-line weight training forum:

    [blue]

    [u]Strength Training Principles[/u]

    [u]Getting Started[/u]

    [u]Developing a Routine[/u]

    [u]Injured Yourself? What to do[/u]

    [/blue]

    It is OK to use link text as part of a sentence, paragraph, list item, table cell, and so on, provided that the link text plus the surrounding text provides enough context to make it understandable. In general, it is best to place the context before the link. For example:

    [blue]

    Learn about the regal [u]excesses in pre-revolutionary France[/u].

    Need instant cash? [u]Borrow now[/u]!

    Next Chapter: [u]Preparing for the Next Stock Market Crash[/u]: What we learned last time.

    [/blue]

    By meeting this requirement, a site conforms at Level A. To conform at Level AAA, see 2.4.9.

2.4 Level AA

  • 2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

    Different people use different ways to zero-in on content on a Web site. Some prefer site maps; others like navigation links or breadcrumbs; still others rely on site searches.

    Make it possible for visitors to your site to find content in at least two ways. Choose from among these techniques:

    • A site map
    • A site search
    • A table of contents
    • Links on the home page to all pages on the site
    • Links to all other pages on the site
    • Links to navigate to related Web pages

    An exemption applies when content is not "findable." A banking Web site, for example, lets customers transfer funds between accounts. The page that confirms the transfer is exempt because the page does not exist until the customer completes the transfer. WCAG 2.0 acknowledges that pages that are "the result of, or a step in, a process" do not need to conform to 2.4.5.

  • 2.4.6 Headings and Labels: Headings and labels describe topic or purpose.

    When headings and labels are clear and descriptive, they helps users understand what information is contained in Web pages, and how that information is organized.

    Examples of clear and descriptive headings

    A Web site for a newspaper lists today's headlines. Each headline is a heading. After each headline is the article. Each headline gives a clear idea of the article's subject:

    [blue]

    Housing Prices Plunge 5% Since August

    Rebel Planes Attack Capital

    UFO Sightings Soar

     [/blue]

    Examples of clear and descriptive labels

    A form consists of three input fields. The label for the first field is [blue]First name[/blue]. The label for the the second field is [blue]Last name[/blue]. The label for the third field is [blue]E-mail address[/blue]

  • 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

    "Keyboard focus" is the one point within a window that receives information from the keyboard. Only one component can have focus at a time. When keyboard-only users press keystrokes to navigate around a Web page, they are moving focus from one component to another.

    Here are three views of the same Web page. The page has three components:

    • "Services" - a link
    • "Name" - a text-entry field
    • "Submit" - a pushbutton
    Three views of a Web page with three components: each time the Tab key is pressed, the next component gets focus.

    In this illustration, a dotted rectangle indicates the component that has keyboard focus. In View 1, the "Services" link has focus. A keyboard user presses Tab to move focus to the "Name" field (View 2). Only when the "Name" field has focus will it accept the text that a user types. This is analogous to clicking inside the field before typing. Pressing Tab a second time moves focus to the "Submit" button (View 3). Now that the button has focus, a keyboard user can press Enter or spacebar to activate it. This is equivalent to clicking the "Submit" button.

    People who rely on a keyboard to interact with Web pages must know which component has focus. By complying with 2.4.7 keyboard users can tell, at a glance, exactly what they are interacting with on a Web page.

    By default, browsers display focus indicators when navigating by keyboard. For the most part, these indicators appear as faint rectangles that surround the focused component. In text fields, the focus indicator is usually a flashing cursor. Web authors who use CSS and Javascript can enhance the appearance of focused components, or make them invisible or hard to see. WCAG 2.0 requires Web authors to ensure that all focused components are easy to spot when navigating by keyboard.

2.4 Level AAA

  • 2.4.8 Location: Information about the user's location within a set of Web pages is available.

    When a Web site or a Web application consists of dozens, hundreds, or thousands of pages, it can be easy to become disoriented, and tricky to find related information. To help visitors orient themselves, include information about the current location in relation to the whole. This can be done, for example, by:

    1. Indicating the current page within a set of navigation links
    2. Providing a breadcrumb trail
    3. Describing the relationship of a page to a larger collection of pages

    This requirement may also be met by including a site map. Although this involves navigating away from the current page, a site map is a good way to show how information on one page (or in one part of the site) relates to the whole.

  • 2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

    Help visitors understand the purpose of each link. This is a more stringent version of 2.4.4, which requires that links either make sense when read out of context, or make sense in the context of the surrounding text. To meet 2.4.9, all link text must make sense when read out of context. This benefits screen reader users who use a feature to extract all links from a page and display them as a list. When each link is unambiguous, individuals who rely on this techique can confidently decide whether they want to follow a link.

    Some visitors may find pages that consist entirely of unambiguous links easier to access, while others may find them harder to access. The word "mechanism" gives Web authors the option to make all links understandable out of context, or to provide a way to make them this way. Providing this option gives all visitors the ability to customize the "wordiness" of links to match their needs.

    There is an exception to 2.4.9 when the purpose of a link cannot be determined from information that appears anywhere on the Web page. In this case, a person with the disability is not disadvantaged, as the context is not available to anyone.

  • 2.4.10 Section Headings: Section headings are used to organize the content.

    Whenever possible, divide pages into sections, and begin each section with the heading that reflects the place of the section within the whole.

    For example, a long document may be divided into chapters, the chapters into topics, the topics into subtopics, and the subtopics into paragraphs. Headings are designed to organize content hierarchically; they are the scaffolding that give shape to documents.

    For HTML documents, use these elements to organize content hierarchically:

    • <h1> for the highest level of page organization
    • <h2> for the second level
    • <h3> for the third level
    • and so on.

    For Word documents, use these styles to organize content hierarchically:

    • Heading 1 for the highest level of page organization
    • Heading 2 for the second level
    • Heading 3 for the third level
    • and so on.

    Section headings clarify the organization of the content, facilitate navigation, and aid comprehension. Other page elements, such as horizontal rules and boxes enhance the visual presentation, but are not sufficient in themselves to identify document sections.

    This provision is included at Level AAA because headings may be impractical or unsuitable. For example:

    • Headings are inappropriate for historical documents that do not have headings. However, if the original document has a title, mark it up as <h1>.
    • Headings are not normally used in letters, even when letters cover a range of topics.
    • Some electronic file formats have no built-in support for hierarchically structured documents. For example, bitmap images contain no structural markup.

Additional Resources

For additional information see:

Ways to Avoid Creating Barriers

This section is intended primarily for a technical audience, or the people who will be implementing accessibility strategies. Less technical readers might choose to skim this section, or skip over it.

Understanding Operability Barriers

Operability barriers can occur when particular features in Web content are reliant on a particular input device to function. Perhaps the most common operability barriers are created when Web content developers use mouse dependent event handlers in their content (e.g. onmouseover, on mouseout). When these device dependent functions are used, there must either be a device independent version used in addition to the device dependent one, a separate alternate to the device dependent feature or content must be provided, or the device dependent event handler must have no affect on accessibility, such as creating visual decoration. When you are developing Web content, always be sure it is fully functional without having to use a mouse.

Operability also encompasses Usability. Web content may be "technically" accessible but unusable. A common occurrence of this type of barrier is found when Web sites present a large number of navigation links across the top and left side of the screen. Because screen readers read from top left to bottom right, it can mean a blind person must pass through all those links to reach the important content that most often appears to the bottom right, and they must do so every time a page loads. You can imagine how much time could be wasted using the Tab key to move through hundreds of links commonly found in Web site navigation elements. For a Web site to be usable in such a case, there must be a way to skip over those repetitive navigation elements, and jump directly to the important information on the page.

Operability issues often arise when multimedia content is embedded in Web content. Not only does the content itself need to be operable (like clicking a Flash button), the plugins used to display them needs to be operable (like clicking a play button on a movie player). While accessibility of multimedia content, and their players, has improved greatly in recent years, there are still lots of movies, flash presentations, java applets, and other embedded content that remains inaccessible to many assistive technology users. When developing multimedia content it is important to remember to make content operable, and to provide accessible plugins with which to view or play the content. Also common to multimedia plugins are keyboard traps, in which the content and plugins may very well be operable, but once inside operating the plugin, it is not possible to get out and return to the surrounding HTML based content. In addition to testing your content without the use of a mouse, be sure it is possible to exit embedded content and get back to the content surrounding it.

Below is a list of common situations where content may not be operable for some people, and thus would fail an accessibility test. Review the Common Failures below to understand where barriers are created. Then move on to the Success Criteria which describe strategies for removing these barriers, and then go on to the HTML markup strategies in the Sufficient Techniques pages, that put these success criteria into practice.

Common Failures for Guideline 2.1 (Keyboard access)

  1. due to using only pointing-device-specific event handlers (including gesture) for a function
  2. due to combining multiple content formats in a way that traps users inside one format type

Common Failures for Guideline 2.2 (Enough time)

  1. due to using meta redirect with a time limit
  2. due to using meta refresh with a time-out
  3. due to including scrolling content where movement is not essential to the activity without also including a mechanism to pause and restart the content
  4. due to using the blink element
  5. due to having a session time limit without a mechanism for saving user's input and re-establishing that information upon re-authentication

Common Failures for Guideline 2.3 (Flashing and seizures)

  1. due to content that flashes more than three times in any 1-second period

Common Failures for Guideline 2.4 (Different ways to navigate)

  1. due to not providing means to skip over repetitive content.
  2. due to the title of a Web page not identifying the contents
  3. due to using tabindex to create a tab order that does not preserve meaning and operability
  4. due to providing link context only in content that is not related to the link
  5. due to using null alt on an image where the image is the only content in a link
  6. due to lack of headings used to signify document sections
  7. due to lack of descriptive labels for form elements
  8. due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator
  9. due to a lack of indicators identifying one's location in a set of Web pages

A more detailed list, including less common failures, can be found in How to Meet WCAG 2.0

Success Criteria

Success Criteria for Guideline 2.1 (Keyboard Accessible)

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

  1. due to using only pointing-device-specific event handlers (including gesture) for a function

    Many people with disabilities may not use a mouse when using a computer, so it is important to ensure that features on a Web page can be operated without using a mouse. People who are blind for example, can't see a mouse pointer, so very few will use one.

    Most operable HTML is keyboard accessible by default, but these elements are often marked up with Javascript event handlers that produce some functionality outside the capability of HTML. Event handlers such as onmouseover or onmouseout, will not be operable for a blind user for instance, because they can only be operated on using a mouse. To make features operable, use a combination of mouse and keyboard event handlers (e.g onmouseover and onkeypress). Or, better, use device independent event handlers like "onblur" and "onfocus".).

    The one exception to the rule is the "onclick" event handler. Despite its suggestion of being mouse dependent, over time it has become device independent, with developers programming in both keyboard and mouse operability. Nevertheless, other device independent event handlers should be used instead of "onclick".

    Device Dependent Event Handlers (avoid using these)

    • onmouseover
    • onmouseout
    • onclick
    • ondblclick

    Device Independent Event Handlers (use these instead)

    • onfocus
    • onblur
    • onchange
    • onselect

    Be careful using onchange with select menus. Despite being device independent, it can make select menus inaccessible by keyboard for items beyond the first item in the menu. If a person is using a keyboard to access the menu, pressing the down arrow to move to the first item in the menu, onchange will be activated, and can prevent the person from reaching the second item in the menu, and beyond. Do not use onchange to auto-redirect people. Instead have them press a button, or provide an alternative menu for those using a keyboard.

    Do not use ondbleclick. There is no accessible alternative to it.

  2. due to combining multiple content formats in a way that traps users inside one format type

    This problem often occurs when non-HTML is embedded in HTML content, such as embedding Flash, Java Applets, or other multimedia objects that open an embedded player. People with disabilities, will often use the Tab key to move through an HTML page to find their way into one of these embedded objects, only to find the mouse pointer has become trapped in the object, and any content that appears after the object becomes inaccessible. Often the only way to escape is to reload the page.

    There are a variety of ways to prevent keyboard traps. First the plugin itself should include a feature that allows keyboard users to escape from the plugin and return to the parent page. If such a feature is not available, you might suggest to people that they use a different plugin if accessibility is an issue for them.

    If a different plugin is not available, contacting the plugin developer and asking (nicely) for an escape feature might help resolve the problem. With the raised public awareness of accessibility issues in recent years, developers are now more likely to oblige such requests.

    Another option is to create your own keyboard escape. This can often be done by creating an HTML accesskey that directs a person to some other location on the page, such as an anchor that follows the embedded object. Of course this needs to be documented, and be easy to discover. One way of make this functionality discoverable is to add a link prior to an object that allows a user to skip over the object to an anchor below it. The link could be an invisible one, using an invisible image with Alt text, that is only visible (i.e. readable) by screen reader (discussed more below in Success Criteria for guideline 2.4). The Alt text with the skip over object link might state alt="skip over Flash below, or use Alt + 1 to exit the Flash object," or something to that effect. You assign an anchor below the Flash object the accesskey "1" (i.e. accesskey="1"). Choose another accesskey if this one is already being used elsewhere on the page.

A more detailed list, including less common failures, can be found in How to Meet WCAG 2.0

Success Criteria for Guideline 2.2 (Enough Time)

Guideline 2.2 Enough Time: Provide users enough time to read and use content.

  1. due to using meta redirect with a time limit

    The meta redirect (i.e <meta http-equiv="refresh" content="5; url=http://www.example.com/newpage" /> ) is often used in the head area of an HTML page to automatically send a person to another location on the Web after a specified period of time. For example, after viewing a splash screen for a Web site, a person might then be sent to the site's home page. The trouble with using this strategy is it often prevents people with disabilities from accessing the content of the screen because they are redirected before being able to read its content. People who are blind, have poor vision, or perhaps have a reading disability, will need more time than the average person to read the page. Don't assume that everyone takes the same amount of time to read the page as you might take, or even twice as long.

    If the page on which the redirect appear contains no content, or the redirect is set to "0", in which case the person is redirected immediately, it is acceptable to use a redirect. In this case the person would not be missing anything. This strategy is often used to send a person to a new site, being redirect immediately from an old one.

    Ideally though, visitors to a Web site should be able to choose when to leave a page. Rather than using the redirect, provide a link instead, that leads to wherever the redirect would have sent the visitor.

  2. due to using meta refresh with a time-out

    Very much like the problem described in the previous Success Criteria, where visitors to a Web site are redirected to another location, using the <meta http-equiv> to refresh a page can result in a similar problem. This strategy is often used to reload a Web page where the content is updated on a regular basis. For example, news sites will often refresh after short period to get changes in the headlines. Much like the problems associated with redirecting, people who are using a screen reader may not have time to finish reading the page before it reloads, after which they will be forced to start reading at the top of the page.

    Where pages are refreshed, be sure the refresh rate is sufficiently long so those who take longer to read have enough time to get through the content of the page. Or, provide a means to turn off refreshing.

  3. due to including scrolling content where movement is not essential to the activity without also including a mechanism to pause and restart the content

    Scrolling content will not be accessible to many assistive technology users because of its dynamic nature. When a blind person accesses a page, a screen reader will take a snapshot of the text on the page, and begin reading it aloud. If content is moving, a screen reader can not access that content, thus it becomes inaccessible to a blind person. Avoid using scrolling text, or if it must be used, as in the case of a stock ticker for instance, provide a scripted means to stop the scrolling, thus assistive technologies to read the text.

  4. due to using the blink element

    Blinking content produces barriers very much like scrolling content does. Because it is dynamic, assistive technologies are often unable to read the content. Avoid using blinking content, or provide a scripted means to stop the blinking so assistive technologies can read the text. Also see Success Criteria for Guideline 2.3.

  5. due to having a session time limit without a mechanism for saving user's input and re-establishing that information upon re-authentication

    Many Web sites these days are built upon different types of Web applications, such as Content Management Systems (CMS), Learning Managements Systems (LMS), blogs, or wikis etc. These Web applications generally require a person to login and start a user session. If that session times-out too quickly, a person filling out a form may not be able to save or submit data before the time-out occurs. A blind person for instance, will generally take much longer to complete a task than a sighted person. They can be logged out and their data lost if the time-out period is too short. While it is necessary in some cases to time-out a user session after a particular period of inactivity for security reasons (e.g. on a banking site), there needs to be a way to maintain data in a form partially completed if a time-out occurs. Or, the time-out period needs to be long enough so there is no chance a person can't complete a task before being logged out.

    Simply put, one way of maintaining data is by recording the location of the form (i.e. its URL) and storing the values of the form in GET or POST variables after forcing the form to submit when a time-out occurs, then restoring those values into hidden fields on the login screen. When the person logs in again, he or she is redirected to the form, and the values previously entered repopulate the form so it is possible to continue completing the form from where one left off. There are many different ways to accomplish this functionality with various programming languages common on the Web.

    Another strategy might be to have a Javascript open a confirm dialogue box that warns the person the session is about to expire, and provides the option to extend the session by pressing "yes". The confirm dialogue box itself should have a time-out, so the session is ended after a relatively short period of time, and security is maintained if there is no one there to make the confirmation. But, the time-out on the confirmation should provide sufficient time for a screen reader to read the message presented in the dialogue box, and for the person to press the Yes button to reset the session. Thirty seconds or more may be required to make the confirmation using a screen reader.

Success Criteria for Guideline 2.3 (Seizures)

Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.

  1. due to content that flashes more than three times in any 1-second period People with photosensitive epilepsy can have seizures when viewing content that flashes at a rate between three and 30 times per second (i.e. 3 to 30 hertz). Do not produce content that flashes more than 3 time per second. For more about photosensitive epilepsy, including triggers other than flashing content, visit the National Society for Epilepsy in the UK.

Success Criteria for Guideline 2.4 (Navigable)

Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

  1. due to not providing means to skip over repetitive content.

    Most Web sites today have a series of navigation links across the top of the screen, and often a series down the left (or right) of the screen, that visitors can use to navigate through major sections of the site. In many cases there are 30, 40, 50, or more navigation links in a typical site navigation template. These links create a barrier for some assistive technology users.

    A blind person using a screen reader to listen to the text of a Web page, may have to listen to the navigation links every time a page loads, before being able to reach the important or relevant information that usually appears to the bottom right. Because screen readers read in sequence from the top left of the page to the bottom right, it can take a blind person a very long time to find their way to the information they are looking for if there are many navigation links to get past before reaching that information.

    Navigating a Web site with many navigation links can be improved greatly for assistive technology users by adding a few "bypass" links. The most common bypass link is located in the top left corner of a Web page, appearing to a screen reader as one of the first features on the page, that links to an anchor located at the top of the content area to the lower right of the screen. By following the link, a screen reader can skip over all the links at the top and left of a page, and immediately begin reading the relevant content.

    By pass links can also be used to jump to other key locations in a page, like jumping from the top left opening of the screen to a particular navigation menu, or jumping from the bottom of a content page back to the top, or jump past a large data table that would otherwise take a long time to read using a screen reader. Bypass links can also be used to jump over embedded objects like Flash, Java, or other multimedia players or plugins contained in Web content.

  2. due to the title of a Web page not identifying the contents

    The first thing a screen reader reads when it encounters a Web page is its title. The title is contained within the HTML title element, which is located in the head area of an HTML page. Across the Web, more often than not, the content of the title element provides insufficient information about the content of the page it represents. Assistive technology users will often attempt to deduce from the page title, whether the information they are looking for can be found there. If the title does not provide enough information about the content of the page, people with disabilities may have to navigate through the page to determine if the information they need is there. If it isn't there, much time can be wasted searching.

    It is important to always include a title element with every HTML page, and that its value provide a summary of the page content. Avoid using the site's name exclusively for all title elements on a Website. Instead use the site's name, and attach the main heading that appears at the top of the content area, so each page has a unique title.

    Descriptive titles also help people using a search engine to find information on your site. If page titles are unique and descriptive, searching the site will be much more effective

  3. due to using tabindex to create a tab order that does not preserve meaning and operability

    For those navigating Web content with a screen reader, the sequence in which the cursor moves through the content can affect how meaning in the page is interpreted. For example, when filling out a registration form, it is fairly standard to have a first name field followed by a last name field. If for some reason the address field appears between the first name and last name fields, confusion will likely arise. The HTML tabindex attribute can be used to reorder the path the cursor takes through content to correct situations like that just described. Such situations are often caused when tabindexing has been added, after which the page is edited but the tabindex order remains the same as it was before editing.

    Tabindexes must be used with caution so as not to disrupt the normal sequence of features on a page. For example, a site may have a search field perhaps located on the left side in a navigation menu. If a tabindex is added to the search field, a screen reader user may be forced to start navigating from the search field each time a page loads. As a result, this person may miss all the navigation elements that appear before the search field. Use of Tabindex should be limited to places where normal navigation through elements using the Tab key does not produce a meaningful sequence.

    Tabindex could be used on pages where the primary content of the page is a form, and where users know they are about to open a form. For instance, if a person clicks in a "register" link, it is reasonable to expect there will be a registration form on the page that opens. In this case a tabindex can be associated with the first field in the form, so when the person begins navigating the page, they are immediately taken to the form, rather than having to navigate through menus etc. to find their way to it.

  4. due to providing link context only in content that is not related to the link

    When navigating a Web site, a blind person using a screen reader will often extract the links on the page, using a function in the screen reader, to gather a list of places the page leads to. It is not uncommon to use repetitive link text such as "Read more..." which might appear after a brief introduction to a news article for instance. In a screen reader's link list, a link like "Read more..." on its own, without the content of the news article introduction prior to the link, is not meaningful. The screen reader users is left asking “Read more about what?.”

    Ideally link text should be meaningful on its own, without the need to search through the surrounding text to discover its meaning. Instead of using "Read more...," use "Read more about Accessibility Laws in Ontario," for example. In this latter case it is clear what a person will find if the link is followed.

    The alternative is to provide context for otherwise meaningless link text. For example, when viewing a list of news headlines, make the title of the article a link to the full article, followed by the introduction to the article, followed by the "Read more ..." link, which also leads to the full article. In this case the title of the article gives meaning to “Read more...” .

    Probably the most common error in creating link text is to follow a statement about some content with a link that reads "click here." Accessibility reviewers cringe when they see this. Instead of using "To learn more about accessibility laws in Ontario, click here" use "Learn more about accessibility laws in Ontario", with the link markup in the latter case around a meaningful phrase. Not only does this make the page more accessible to people using a screen reader, it makes it more accessible to everyone. A sighted person also benefits from meaningful links, being able to scan through the page quickly, and have the contrasting link text stand out, and provide a quick list of locations linked from the page. The same sighted person scanning through a page where "click here" is used throughout, then has to read through the rest of the text on the page to figure out what each of those "click heres" mean.

  5. due to lack of headings used to signify document sections

    Much like screen reader users can extract links from a Web page to produce a link list, they can extract headings from a page to produce a heading list. This list provides a summary of the content on the page, and provides information about the relationships between sections and sub-sections of the content. Headings in a heading list can also be used to navigate through the page. So, if the section containing the information of interest happens to appear at the end of the page, the person can jump directly to that section through its heading.

    Without proper headings, using the HTML h1, h2, h3 elements etc. the page will appear to a screen reader user as one large block of unstructured text, that can only be navigated through from beginning to end. A screen reader user would be forced to listen to the whole page, before discovering that last section of the page contains the information of interest. Worse, after listening to the early parts of a page without structural markup, a person might decide incorrectly that the information they seek is not going to be found on the page, and thus may never end up finding it.

  6. due to lack of descriptive labels for form fields

    Labels describe the function of a particular component of a Web page, which could serve to describe the purpose of a form field, the purpose of a collection of form fields, a grouping of links, or an embedded object like a video or flash movie. Labels are not necessarily created using the HTML Label element, though it is one common form of label. Labels might also be headings, captions, a fieldset, or even title or Alt text. In each case the text associated with a label describes the function of a element in a Web page.

    Wherever functional elements appear in a Web page, be sure to label the element so it is clear what it represents. A common failure is often found with simple search fields that do not have a label to describe what content should be entered into the field. In some cases a person can navigate through the surrounding content and deduce the purpose, but this is inefficient, and can be time consuming. If a label for such a form disrupts the layout of the search tool, try using style elements to make the label invisible. Sighted people can usually determine the purpose of a search field with a quick scan, so they may not need to see the label. While the label may not be viewable to them, it can be readable by assistive technology. A variety of CSS related strategies can be used to hide labels.

  7. due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator For people with poor vision, following a cursor through components of a Web page using the keyboard can be difficult, particularly when styling has been applied to remove the focus indicator when the cursur passes over an active object. Even with no styles applied, it can be difficult to follow the cursor, even for people with full sight. A variety of strategies can be used to help make the path of the cursor through content more easy to follow, perhaps making the text of active elements bold, or with a bright border, or perhaps by adding a contrasting background when an element is active.
  8. due to a lack of indicators identifying one's location in a set of Web pages

    In addition to being able to track a cursor through locations on individual Web pages, people should be able to identify where they are within a Web site as a whole. There are many ways of accomplishing this. A common method is to highlight a Tab, in commonly used tab navigation that often appears across the top of a Web site. While on the Home page, the Home tab would be highlighted. While in the Resource section of the Web site, the highlight is removed from the Home tab, and instead appears with the Resources tab, and so on.

    Another common method for helping people identify their location is to present "breadcrumbs." These are often located across the top of a Web page, and represent a hierarchy of sections and subsection. For example, if a person is in the Resource Section of a site, in the Tools Sub-section, viewing Accessibility Tools, a set of breadcrumb links might appear as "Resources>Tools>Accessibility Tools", showing Tools and Resources as links. These links enable a person to identify their location within a hierarchy of topics. They can follow a path to the top of a hierarchical arrangement of pages.

    Content menus are also a common method used to help visitors identify where they are within a collection of related topics and subtopics, as well as their location within a collection of unrelated topics. While viewing a particular page within a collection of related topics, the page being viewed, its parent topic, and its parent topic might all be highlighted to display one's location within a hierarchy of related topics.

    Sitemaps can also be useful for identifying one's location within a Web site, or within a collection of Web pages. Sitemaps can also act as a central navigation point for some people using assistive technology, not only to help them know where they are within a Web site, but also to help them develop a mental picture of the site's structure, and find their way to locations in the site they want to visit.

A more detailed list, including less common failures, can be found in How to Meet WCAG 2.0

Sufficient Techniques

Sufficient Techniques for Guideline 2.1 (Keyboard Access)

These techniques can be used to add keyboard access to Web content, and to conform with WCAG 2.0 Guideline 2.1

1. Keyboard Operable Links

It is critical that all functionality in Web content be operable by keyboard. Most people will take the availability of a mouse for granted, and will, for the most part, use a mouse pointer to navigate the Web. Though there are a some screen reader users who can use a mouse through a feature in their screen reader that allows them to move a mouse pointer around by selecting quadrants then sub quadrants of the screen until they have narrowed it down to a clickable size over a feature they want to click, the majority of blind users will not be able to use a mouse. To make Web content accessible to these individuals, there should be no content that relies on a mouse alone to operate.

In the following examples two visually identical hide/show boxes have been created using different methods. The first relies on the ability to click with a mouse pointer, while the second will operate with either a mouse or a keyboard.

Example 1: Keyboard Operable Links

In this first case, the javascript toggle is applied to the div element, which is not keyboard operable.

EDIT

2. Keyboard Traps.

Keyboard traps occur when a user attempts to access content or objects embedded in a Web page, and either can not get to the content without using a mouse, or perhaps can get into an object, but can't get out. In the Flash calculator below, depending on the Web browser being used, a keyboard trap is demonstrated.

Browsers are getting smarter, and will sometimes provide a means to navigate past keyboard traps. You will notice that using a current version of Firefox (v 3.0), it is not possible to access the calculator using the keyboard's Tab key. Likewise, if you click inside the calculator, which itself is accessible to screen readers once inside, it is not possible to exit the calculator and get back to the surrounding content without the aid of a mouse click outside the calculator.

On the other hand, in a current version of Internet Explorer (v 7.0) it is possible to both enter the calculator using the Tab key, and just as easily exit the calculator to return to the surrounding content.

Example 2: Keyboard traps

This example requires a Flash plugin be installed with your browser.

Using two or more different browsers to view this page, use the keyboard's Tab key to navigate to the Flash calculator below. Notice whether you are able to use the calculator without the aid of a mouse.

[media|300|300]calculator.swf[/media]

Additional Resources

For additional techniques see:

Sufficient Techniques for Guideline 2.2 (Enough Time)

These techniques can be used to manage time in Web content, and to conform with WCAG 2.0 Guideline 2.2

1. Allow enough time to read.

The average person reads between 200 and 300 words per minute. There are however, many reasons why a person might read at a slower rate than that. A person with a print disability might read at 100 words per minute, or less. While it is typical for blind users to have their screen reader set to read faster than the average user, it often takes additional time to find one's way to the readable content. In the example below for instance, it might take the better part of a minute to find one's way to the text using a screen reader.

It is common for Web developers to create an introduction, or "splash" screen that after a few seconds redirects the person to another page on the site. This is often done using something like <meta http-equiv="refresh" content="3";url="http://someplace.com">. This can be a problem for some people if the refresh rate (content="3") is not long enough. In this case either leave a very long time, or do not use this method at all. It is important to leave enough time for slower readers to read the content before redirecting them to another location, or to provide a means to stop or extend the time before redirecting.

Note that there are some exceptions to allowing enough time. For example, allowing a person to complete a task, such as a test or quiz, a psychological assessment, or other timed activities, might invalidated the results if more time were allowed.

The example below simulates for readers of average speed, what might be experienced by a slow reader when they encounter timed content that does not provide them with enough time to read it. In the second example, users can disable the timer, and thus take as long as they need to read the content.

Example 1: Allowing enough time to read.

EDIT Most people will not be able to read the content in this example in the short amount of time provided.

2. Extending a session timeout.

Another example where timing is used is when a period of inactivity occurs, and a person gets logged out of a system for security reasons. This is done so others can't access an inactive session, and perhaps act maliciously. For a blind person or a person with a print disability, it may take a very long time to get through the content of a Web page, and as a result when they go to save their data, it is lost because the session has timed out. In such a case, timeout should be set to several times longer than it might take the average users to finish with the page. WCAG 2.0 suggests 20 hours as a timeout period, though from a security perspective, this is too long to allow an inactive session to run. Instead, provide users with the means to extend the session.

In this example, when time is about to run out, a warning pops up asking the person if they want to continue or to let time run out. While this functions effectively here as a demonstration, and allows the person to continue reading, where security is a concern, a popup browser window would be used instead of a javascript dialog box. The popup window itself should time out after a short period and thus allows the user session to expire. A javascript dialog will remain on the screen until someone clicks a button in the dialog box, thus if someone walks away from their computer, another person could potentially take over the session, with the possibility of malicious activity.

Example 2: Extending a Session Timeout.

EDIT

Additional Resources

For additional techniques see:

Sufficient Techniques for Guideline 2.3 (Flashing and Seizures)

These techniques demonstrate flashing in Web content that is associated with WCAG 2.0 Guideline 2.1

1. Technique 1: Flash Rate

This technique is more of a "what not to do" than it is a technique for creating content that does not have a flash rate faster than the 3 flash per second threshold. Ideally, you should not create flashing content, period. In the example below, you can select the flash rate for the square above the radio buttons, to experience how fast a flash rate appears to the eye. Depending on your computer monitor's capability, rates over 25 flashes per second may not appear any different. Physiologically, humans can not detect flashing over about 55 milliseconds per flash (a little more than 20 flashes per second), though this rate will vary depending on the contrast between flashes, with faster detection rates with higher contrast. This rate is called Critical Flicker Frequency (CFF). Flashing faster than CFF will appear as a solid colour. For more about flash detection, read about Temporal Resolution

WARNING: though the flash area has been kept small to reduce the possibility of causing a seizure, those who know they are photosensitive should not attempt to view flash rates greater that three per second.

Example 1: How fast is three flashes per second.

Additional Resources

For additional techniques see:

Sufficient Techniques for Guideline 2.4 (Different Ways to Navigate)

These techniques can be used to add navigation to Web content, and to conform with WCAG 2.0 Guideline 2.4

1. Create a logical tab order.

The order in which content or features appear on a Web page can have an effect on a person's ability to comprehend, and ultimately use a Web page. For someone who is blind, it is particularly important that content be laid out in a way that makes sense when moving through it in sequential order. In Example 1 below, two visually identical forms are presented. In the first form however, the tab order does not follow a logical path, while in the second it does.

Logical order for a simple form, like a login form, is often first: register, then enter a login name, then a password, then select auto login, then submit to login. This is the order in the second form below. In the first form however, without any control over tab order, the cursor starts with the login, then goes to submit, then password, then register, then auto login. This latter path through the form make little sense with respect to the steps one might take to login to a site, and will take considerable time for screen reader users to figure out. The former login form will be understood the first time a screen reader user moves through it.

Example 1: Tabindex to control focus order

In this first example, position your mouse cursor some place before the form, then press the Tab key and watch the path the cursor takes through the form.

// In this markup a form is laid out with an illogical tab order // that will be difficult to comprehend for a blind person.

[Register]

The above markup produces for following appearance.
[Register]

In this second example, position your cursor before the form, then press the Tab key, and notice the cursor moves through the form in the logical order one might take to login to a Web site. In this case, you will notice in the code example, that the tabindex attribute has been used to control the path the cursor takes through the form.

// In this markup a form is laid out with an illogical tab order, // but "tabindex" has been used to create a logical order // that will be easy to comprehend for a blind person. <form&rt; <table style="background-color: transparent;" cellpadding="1"&rt; <tbody&rt; <tr&rt; <td align="right"&rt;<label for="username2"&rt; <small&rt;Username:</small&rt;</label&rt;</td&rt; <td&rt;<input name="username" class="input" size="5" id="username2" tabindex="2" type="text"&rt;</td&rt; <td&rt;<input name="submit" class="submit" value="Sign-in" tabindex="5" type="submit"&rt;<br&rt;</td&rt; </tr&rt; <tr&rt; <td align="right"&rt;<label for="password2"&rt; <small&rt;Password:</small&rt;</label&rt;</td&rt; <td&rt;<input name="password" class="input" size="5" id="password2" tabindex="3" type="password"&rt;</td&rt; <td rowspan="2" valign="top"&rt; <small&rt;[<a href="/my/register.php" tabindex="1"&rt;Register</a&rt;]</small&rt;</td&rt; </tr&rt; <tr&rt; <td colspan="3" style="white-space: nowrap;" align="center"&rt; <input name="auto_login" value="1" id="auto2top" tabindex="4" type="checkbox"&rt; <small&rt;<label for="auto2top"&rt;Enable auto-login</label&rt;</small&rt; </tr&rt; </tbody&rt; </table&rt; </form&rt;

The above markup produces the same appearance as the example above, and does provide structure.
[Register]

Of course, it is possible to create a form such as the one above, by physically positioning the components of the form in a logical order, in which case tabindex is not required, and should not be used. The tabindex attribute should only be used when the layout of particular features on a Web page do not by default produce a logical tab order. And, without saying, tabindex should not be used to produce an illogical tab order.

Also keep in mind that tabindex can affect accessibility in a negative way if not used carefully. For example, if the example login form above is located in the content area of a page (usually the lower right of a Web page), and tabindex is set to "1" for the first component in the form, if a screen reader user uses the Tab key to begin navigating through a page, the cursor will jump to the form and skip over the content above it. This may be fine, if the login form is the primary content on the page. But if the form is not the primary content, it can make the content before the form inaccessible, or at least make it difficult to navigate or to imagine the layout of a Web page.

Note: While in theory tabindex can make Web content easier to navigate, in reality not all browsers support it, and some that do support it, don't support it very well. Regardless, if you are creating a form that does not produce a logical tab order by default, use tabindex as it was intended to be used. If you are unsure, lay out the form so it produces a logical tab order without having to use tabindex.

2. Bypass Links

Example 2: Jump to Content and Jump to Menu Bypass Links

In the top left corner of ATutor there are two hidden bypass links that when clicked (or more likely keypressed), the cursor is repositioned to either the top of the content area to the lower right, or to the content menu to the left. You can access these links by positioning your mouse cursor outside the content window, perhaps in the browser's location/address field, then press the Tab key until the cursor enters the content window. When it does, watch the status bar at the bottom of the browser window and note the URL (i.e. http://accessibility.atutor.ca/content.php?cid=194#content) the "#content" part of the URL is a reference to an anchor positioned at the top of the content area (i.e. <a name="content"></a>).

Without this bypass link a blind person may be forced to listen to everything at the top and left of the page, everytime a page loads. You can imagine how much time would be wasted navigating to the content area if the bypass link was not there. There can be 100 links or more to move through before reaching the content.

// These two links are located at the very // start of the HTML. Notice these links include an // accesskey, making it possible to jump // the top of the content or to the menu from // anywhere within the page by pressing Alt+c and Alt+m.