WCAG 2.0 - Operable
2.1.1 Keyboard
This requirement is intended to ensure that all page functionality can be operated using the keyboard only.
How to test?
To overcome the possibility that the site’s CSS hides any visual focus indicator (see requirement 2.4.7 Focus Visible), it is suggested that you disable CSS in your browser when testing this requirement.
When the page you want to test is loaded in your browser, click in the address bar of the browser. Then start hitting the Tab key. Depending on your browser, you’ll see focus move through the browser controls and tabs (if you’re using a tabbed browser), and onto the page as a whole (a dotted line may appear around the entire page). Then focus will cycle through the links and form elements in the page. Keep an eye on the status bar to watch focus moving from one link URL to the next. As links or form elements receive focus, you’ll see (most likely) a dotted line appear around the control that has focus. Press Enter to activate the control and verify that it responds to keyboard input. You need to test that you can navigate through the site and use any forms (e.g., search) purely with a keyboard.
Note: Shift-Tab will move focus backwards up through the focussable elements.
2.1.2 No Keyboard Trap
Keyboard traps are fairly rare. They occur when you’re using a keyboard and get trapped inside a form or other element: You can press Tab and cycle through all the focussable elements in the form or object, but you can’t exit from it and move to the elements on the rest of the page.
How to test?
While you’re doing the test above (for 2.1.1), make sure that you can use the Tab key to reach all focussable elements, from the top of the page through to the links in the footer.
On a standard content page or homepage, make sure you don’t get into a situation where you end up tabbing from search input box to search button to search input to search button.... You have to be able to tab into, through, and out of a form.
2.2.1 Timing Adjustable
How to test?
If a time limit is set on any activity, make sure that it can be disabled or extended. This is not likely to be an issue for most sites.
2.2.2 Pause, Stop, Hide
How to test?
In essence, for any page that contains moving, blinking, scrolling, or automatically updating content alongside other static content, make sure there is a facility to pause or stop the movement. An example is the moving slider on the home page of dia.govt.nz for which pause and play buttons are provided.
2.3.1 Three Flashes or Below Threshold
How to test?
Unlikely to be relevant to most of govt.nz sites. In summary, make sure that content or item that flashes doesn’t flash more than three times in one second.
2.4.1 Bypass Blocks
You must provide a way for users, particularly keyboard-only users, to bypass blocks of content that are repeated on every page, such as banners and navigation menus.
The most common way to do this is to place, at or near the top of the page, a "skip to main content" link that allows users to move directly to the main content on the page. For example, a page might have a link element, e.g., <a href="#content">Skip to main content</a>, shortly after the <body> tag, and an <h1> heading with corresponding ID attribute, e.g., <h1 id="content">, at the top of the page’s main content area.
This "skip link" may be visible or hidden. If it is hidden, ensure that it remains available to assistive technologies like screen readers (i.e., does not use the CSS declarations "display: none;" or "visibility: hidden;").
Another way to satisfy this Success Criterion is to provide heading elements at the beginning of each section of content, including sections like main and secondary navigation, main content, and the footer (see WCAG 2.0 Sufficient Technique H69).
How to test?
The easiest way to check that a "skip link" exists is to disable CSS in your browser and look near the top of the page. Clicking the link should move focus to the top of the main content on the page.
Then turn CSS back on, and check to see if the "skip link" is visible or hidden. If it is hidden, ensure that it is able to receive keyboard focus when using the Tab key. The "skip link" may become visible upon receiving focus, but it may not, in which case, keep an eye on the browser's status bar as it should indicate the URL for each link that gains focus.
If there is no "skip link" on the page, or if it does not work, e.g., it is set with "display: none;" in the CSS, check that all the major sections of content like navigation menus, sidebars, main content, and footer have introductory headings.
2.4.2 Page Titled
Every page needs a unique title (using the <title> element) that clearly identifies the content of the page and distinguishes it from every other page in the site. A good rule of thumb is to make the page’s <title> element using, first, the page’s main content heading, followed by the name of the site, e.g., “Strategic Direction | Ministry of Health”.
Titles are shown in the title bar (at the very top of the browser window). They are also displayed for bookmarks and in a browser’s history.
How to test?
Check the title bar at the top of the browser window, or view the page's HTML markup and find the <title> element inside the <head> element near the top. Make sure that each page’s title is unique and relevant to the content of each page.
2.4.3 Focus Order
How to test?
When you check that all functionality is available via the keyboard in accordance with requirement 2.1.1, make sure that the order in which elements receive focus (also known as the Tab order), corresponds closely with the visual layout of the content on the page, in a left-to-right and top-to-bottom fashion.
2.4.4 Link Purpose (In Context)
Whenever possible, provide link text that identifies the purpose of the link without needing additional context.
If you have repeated links (e.g., multiple ”read more” links pointing to different content), then W3C’s Understanding 2.4.4 page contains useful guidance: Make sure that the link's purpose can be known from the heading element that immediately precedes the link, or the “text that is in the same paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.”
How to test?
Evaluating this standard requires some knowledge of HTML.
Check all links on the page and verify that the link text is meaningful.
Where scenarios with repeated or vague link text (e.g., "Read more") exist, check that the link is immediately preceded by a meaningful heading, or is part of the same paragraph, or list as the text that indicates the link's purpose. Such a link can also be located in a table cell whose header cell contains text that provides context for the link.
Unless the page complies with this guidance, you should check “No.”
2.4.5 Multiple Ways
How to test?
Websites are required to provide more than one way of locating content. Check that your site provides at least two of the following mechanisms for finding content:
- search function
- navigation menu
- site map
Of course, providing all three is better. For more options, see How to meet 2.4.5.
2.4.6 Headings and Labels
How to test?
Review all text content and form controls on the page. Verify that blocks of related content have headings whose text clearly describes the content it subsumes. Similarly, check that the labels for form and other interactive controls make it easy for users to understand what each control does.
2.4.7 Focus Visible
Most browsers visually indicate focus by putting a fine dotted line around the element that has focus.
The visual indication provided by this dotted rectangle may be sufficient if it offers reasonable visibility. However, where the page’s visual design diminishes the visibility or contrast of the focus rectangle, it may be necessary to provide some other visible indication of focus, such as by duplicating the link’s CSS “:hover” state with the “:focus” state (and the “:active” state to support Internet Explorer 7 and below). This will give links that receive keyboard focus the same visual indication that they have when hovered over with a mouse.
How to test?
While you’re performing the test for requirement 2.1.1, make sure there is a clear visual indication for each element when it receives focus.
Where “skip links” are concerned (see 2.4.1 Bypass Blocks), make sure that these links are visible at least when they receive keyboard focus.
- Last modified: