Verify - manual

Why?

This step is to ensure that the text information in the content achieves the Web Content Accessibility Guidelines (WCAG) principle of Understandable. Labels, links, and page titles should be clear, concise, and unique. Only elements that perform the same action should have identical labels.

Why?

This step checks for requirements relevant to consistent behavior across multiple pages or processes. Most accessibility considerations focus on a single page at a time. However, pages are often part of a cohesive user experience. These new cross-page considerations were introduced in WCAG 2.2, and are not yet officially part of IBM requirements, though some teams are choosing to proactively adopt them.

Check that mechanisms that provide page-level help are consistently placed on any page that includes them. Such mechanisms can include contact information, chat clients and links to Frequently Asked Questions.

Check that users are not asked to re-enter the same information multiple times within the same process, whether on the same page or later in the process.

Finally, if you have developed your own login process, confirm there is a way for users to reset their passwords that does not rely on them remembering their username.

This step checks whether the content achieves the WCAG principle of Perceivable, and that users with low vision or color deficiency (‘color blindness’) can understand everything. Differences in color should not be the only means of conveying information, both in text, charts, and in graphical elements. Look for color words in the content, such as red, yellow, or green as a tip for which types of content to check. Look for the correct use of 3 to 1 contrast in addition to use of color to distinguish the color differences. After these checks, it can also be helpful to view the page without color to confirm all content is still useable.

Automated testing should have already detected most text contrast issues. Check for links that are not underlined to see if they are distinguishable from the surrounding text as links by their contrasting color. Any occurrences of color background gradations should be inspected manually. Teams can use a tool like Colour Contrast Analyser for spot checking.

Check for images of text. They are simple to identify with a mouse – the text in the image cannot be selected. Alternatively, removing or changing the color of real text can help isolate images of text.

Identify parts of components (such as the square outline on a checkbox or the indicator for text input) and check that each has a 3 to 1 contrast with the background and adjacent (touching) graphical elements. Also check contrast on meaningful graphics, such as bar charts and button icons. They must meet 3 to 1 contrast against the background but also against adjacent parts of the same graphic. For example, in a pie chart, each of the colored slices needs to have a 3 to 1 contrast ratio with its neighbors, or needs to have a contrasting outline width of at least 3 pixels

This step is to ensure that your content achieves the WCAG principle of Understandable. You will quickly read through all text on the page looking for any confusing or vague textual content. Headings and labels should be clear, concise, yet descriptive. Instructions must be provided where users require guidance to complete a task easily, especially where an unusual keyboard interaction is required.

Language that uses sensory terms for position (such as “left”, “top” or “corner”) or shape (“circle”, “square”) must have an additional non-sensory way of describing such information. Some text must be tested with a screen reader in a later step to confirm support for assistive technology: words and phrases in a different language should be flagged for further confirmation, as should headings, labels, and instructions.

The absence of time-based media, as well as flashing or auto-playing content can quickly be confirmed and set to NA in your test results. When flashing content is present, check that it is below the threshold. Check for animated carousels and other looping information on the screen. When such content is present, note where it is found so it can be fully tested in a later step.

This initial manual inspection is a good time to actively look for potential problems or curiosities. As you become more experienced with accessibility verification testing, looking holistically at the page can surface items that need further investigation with either manual testing or with a screen reader. Make a note of anything that needs extra attention, such as dynamic custom components, technology-specific or platform-specific implementations, or potential oddities. Components like embedded media players and carousels should always be identified for thorough investigation.

If you are doing software testing, this is also a good time to look for some of the additional requirements for non-web applications in the IBM accessibility requirements.

When a pointer is moved around on a screen, changes to content may occur without the user otherwise intentionally interacting with the page. Such effects include ‘rollovers’ on buttons and content exposed by hover.

It is essential that hover effects do not reduce the accessibility of the page, which can happen if the user cannot distinguish between which item has focus and which item happens to be under the pointer’s current position. Similarly, visual rollover effects should not cause content to fail minimum contrast, for either text or non-text.

Where hover causes new meaningful content to appear, check that the content behaves predictably. It should remain on screen until dismissed by the user. The user should be able to bring the pointer over the top of the new content without it disappearing (allowing users with low vision to see it).

Any new content that appears or is operable via hover should also trigger via the keyboard. Common failures of keyboard equivalence include exposing label or help information only via tooltips, or not providing a keyboard method (normally pressing the Escape key) to dismiss the new content.

When a pointer acts on content via a click or similar action, resulting indications of a change of state — such as expanded, selected, or pressed — should not cause content to fail minimum contrast. As well, if state changes are indicated only through color differences, they should be tested using high contrast mode.

Check all functionality that uses multipoint (multi-touch) activation or path-based gestures can also be operated with a single pointer without such complex gestures, unless they are essential. If your product is aiming to meet the newer WCAG 2.2 requirements, also ensure there is a single pointer alternative to drag and drop.

If testing for WCAG 2.2, confirm targets are at least 24x24 pixels, or sufficiently spaced from other targets.

Pointer operations need to have the ability to be cancelled. Finally, for any interaction offered using the pointer, there must be a keyboard equivalent, so any unusual pointer interactions should be noted for future keyboard testing.

Orientation changes and motion testing are normally carried out on mobile devices. When a mobile device is tilted 90 degrees, its sensors trigger a change in orientation of content. This is expected behavior at the platform level, so the test ensures the application does not prevent the content from displaying in both landscape and portrait.

In the same way the platform offers a lock to prevent the user from accidentally triggering orientation changes, any application supplied actions that are triggered by motion must include a mechanism to disable the motion activation. Check the application provides another means than motion detection for the activation.

For iOS mobile devices, substitute the first two checkboxes with:

Repeatedly pressing the Tab key should allow users to navigate to all interactive elements or composite components and groups in the content. It is important to actively look for items missing from the tab order, not simply to follow along with the visual focus indicator. It is also important to confirm a user can traverse the page from bottom to top using Shift+Tab. Often, complex widgets (composite components) are accessed by a single tab stop, with arrow key navigation between the widget’s elements. This is acceptable behavior and is further discussed in the Check component keyboard interaction step.

For iOS mobile devices, a similar verification of navigation order can be obtained by turning on the VoiceOver screen reader and navigating through the entire contents using the Flick Right/Left gesture to move to the Next/Prior Item. To apply the following guidance to mobile, substitute references to tabbing with Next/Prior Item gestures.

Although checking the focus indicator is given here as a separate testing step, it is normally carried out in tandem with the preceding and following steps, Validate pointer operations, Check tab or navigation order, and Check component keyboard interaction. This is because the focus indicator should only change as a result of a user action.

Verify that the indicator of the keyboard focus (or in the case of VoiceOver on iOS, the navigation focus) is always highly visible or the browser default. Where it is not highly visible, further testing is required to determine if the lack of visibility is the default for the user agent or platform (which is acceptable, since it can be enhanced by user settings) or if it is a result of coding, which may have suppressed or attempted to modify the focus indicator. If testing for WCAG 2.2, another possible way the focus may not be visible is if it has been obscured by other content.

Where designers or developers have altered the default focus indicator, it is critical that such an alteration does not prevent enhancements to focus indication by the user’s platform settings or by assistive technologies. This is tested more thoroughly in the High contrast and OS settings step.

Ensure that there is a focus indicator within a complex widget or composite component, such as when navigating items in a menu, grid, or tree. Ensure that where an element can both receive keyboard focus and be selected, the indicator for focus is different than the indicator for selection. An example would be an item in an expanded list box or toolbar. One item may be selected by default, but because there is a different indicator for keyboard focus, a user can navigate to any of the items while knowing which item retains its selected state.

Navigation and interaction within components and widgets must also be tested for keyboard accessibility. This includes confirming a keyboard equivalent to interaction and information revealed by Onmouseover actions. Generally, the keys used for interaction are Escape, Spacebar, Enter, Home, End, PageUp, PageDown and the arrow keys. Modifier keys such as Shift, Ctrl and Alt may be used in conjunction with these keys, such as when selection of multiple items needs to be supported. Visual indicators of focus and, where relevant, states such as selected/unselected, expanded/collapsed are provided. If testing for WCAG 2.2, it is also important to confirm that new content or overlays that appear as a result of keyboard interaction do not persist onscreen and potentially obscure an item receiving focus.

Where there are established models for keyboard interaction for a widget or component, all standard methods for selecting and navigating the component should be supported. We recommend using the ARIA authoring practices as a model for keyboard interaction. In cases where keyboard conventions are not followed or keyboard interaction is complex, prevalent and clear keyboard instructions or accessible documentation must be provided.

Pay attention to operability and accessibility of audio-video included in the application, as well as unusual behavior observed during the visual inspection steps.

Test that any custom keyboard shortcuts that do not contain modifier keys must be able to be remapped or turned off unless they are only activated when the component has focus.

The ability to move between regions of the page makes applications more usable with keyboards and assistive technologies. More than one site navigation mechanism must be provided, for example a search field, site navigation links, landmarks, skip to main content link, or a site map. The chosen methods must be consistently used throughout the application. For web applications, ARIA landmarks enable keyboard and assistive technology users to traverse page content by region. Where there is more than one of any type of landmark on the page, each needs a label (typically provided with aria-labelledby in association with an existing text heading).

Note: Although the concepts apply, this testing step does not apply to most software applications.

The ability to resize text is built into most operating systems and user agents. Ensure that when content is scaled it is still fully usable and understandable. Scaling can be the result of zooming all content or just resizing the text. Many teams will only test zooming all content, although arguably the ability to resize only the text is of significantly more value to many users since it allows more screen context.

Check that the application accommodates changes to text spacing. A simple script can be used to modify text to meet the new spacing requirements, at which point it can be inspected to ensure no loss of content, such as through truncation.

The ability to simply resize text is no longer sufficient. Applications must now provide content that reflows to fit on a typical mobile device screen without horizontal scrolling. The same responsive design that achieves this reflow of content to a small screen also allows users with low vision to magnify the content to 400% on a desktop screen without the need to scroll horizontally.

During reflow, content can be repositioned (to menus, for instance); however, it must still be available.

Changes to the content of a page can be triggered by user action. A change of context describes major changes in the content that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. To be accessible, dynamic updates that change a user’s context need to be predictable. For keyboard operation, context changes should only be triggered when users activate a control either by pressing Enter, or by altering a component’s state then pressing the Tab key to move to the next component. Context change should not occur when users simply change their focus on the page, begin inputting data, or begin interacting with a component.

Note: If content on a page is updated, it is not necessarily a change of context, especially if the change occurs for content the user has not yet navigated to on the page. Where content is changed, it is important that the changes do not contribute to timing issues for a user. For instance, if a country being selected in a list box causes the values for states or provinces to be updated in a following list box, the update needs to happen in such a way that it does not disrupt keyboard navigation or screen reader output.

On a mobile device, activation typically occurs by tapping or left/right swiping the screen.

A “user’s point of regard” refers to the portion of an interface with which the user is interacting. When a dialog or new page replaces a user’s current focus, once that overlay is dismissed, the user should return to their prior focus to maintain the user’s point of regard. When an application returns the user to the prior page but at a different location, the user is said to have lost their point of regard. A common problem is if the user has been moved to the top of the page.

Maintaining a user’s point of regard can dramatically improve the usability of an application, especially for users of assistive technology. It can improve efficiency, comprehension and predictability. Maintaining a user’s point of regard is especially critical when dismissing dialogue boxes and warning messages, or when moving a user backward through a step-by-step process, such as when they are correcting errors. A point of regard can refer to an element that has focus, a region of the content (page) that was in the viewport, or a set of data or search results with which a user is carrying out tasks.

A user’s point of regard can also be disrupted if other content covers part of the page. If testing for WCAG 2.2, ensure that any new content that overlays other content does not obscure any item receiving keyboard focus.

A critical part of testing page interaction for accessibility is to determine how the system responds to user input errors. Frequent causes of accessibility failures include non-modal dialogs that do not prevent accidental keyboard movement to other parts of the screen potentially obscuring the viewport and interfering with assistive technologies. This includes instructions and inline messages that are not properly surfaced to the user. Enter incorrect data to produce all the known types of error handling, notifications and instructions, so that they can be verified.

Check that input fields that collect typical information about a user are programmatically set to use the correct HTML autocomplete attribute.

Completes testing for:

The requirements for applications to support operating system platform accessibility features and user preferences are covered in different ways by existing and developing standards. A relatively simple test that confirms an application’s ability to support both user preferences and platform settings is to activate the Windows operating system’s high contrast mode. Traverse the page with a keyboard, confirming the continued presence of a visible focus indicator. Where applicable, interact with a pointer and confirm Onmouseover effects are still visible.

Software:

If you are unfamiliar with the system being verified, it can be difficult to test for accessible time limits since many are based on a period of inactivity. For transaction-based applications with known time limits, it is just a question of waiting. For application-wide timeouts, the easiest way to surface timeout functionality may be leaving an application dormant but connected to the network overnight. Consider including accessible timing verification during functional or system testing that exercise time limit situations.

Allowable timing exceptions include real-time events such as an auction and time limits longer than 20 hours.