Skip to main content

Manual

Manual testing is divided into steps. A visual inspection is followed by pointer and keyboard checks. Testers then validate the ability of the content to resize. They complete manual testing by confirming the accessibility of interactions.

Inspect visual content

    Check labeling, link names, and page titles

  • Make sure that...
    • All form fields and controls have visible text labels
    • Page title is unique within the application and generally matches the level one heading
    • Link names make sense on their own
    • Links with the same name must point to the same target

    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.

    Fully addresses
    Partially addresses
  • Check use of color, contrast, and images of text

  • Make sure that...
    • Color is not the only indicator to convey meaning
    • Links not underlined are distinguishable when viewed in gray scale
    • There is clear contrast between all text and its background
    • All parts of any gradient background have clear contrast with their text
    • Confirm images of text pass testing for alternative text and contrast
    • There is clear contrast between components and the background
    • All parts of meaningful graphics have a contrast of 3:1 against adjacent colors
    Why?

    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

    Partially addresses
  • Read text for clarity; check for foreign and sensory words

  • Make sure that...
    • Non-sensory words are provided for sensory-worded instructions
    • Headings and labels are clear and concise
    • Instructions are always provided for required user input, expected formats, and keyboard interaction
    • Headings, labels, instructions, and foreign words and pages are noted for later confirmation that they are also compatible with the screen reader
    Why?

    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.

    Fully addresses
    Partially addresses
  • Check for audio, video, flashing, and auto-play

  • Make sure that...
    • Any flashing content is below required thresholds
    • Any audio or video has a label describing the content
    • Any audio, video, or auto-playing content is noted for further testing
    • If no media listed above exists, the items below are not applicable
    Why?

    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.

    Fully addresses
    Partially addresses
  • Note any curiosities

  • Make sure that...
    • Dynamic and any potentially problematic components are noted for further testing with the screen reader
    • Technology-specific requirements and considerations are noted
    • Icons used for meaningful content are noted for high contrast testing
    Why?

    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.

    Partially addresses

Test without a keyboard

    Check pointer hover

  • Make sure that...
    • Any indication of pointer location does not negate state indicators, such as focus
    • Rollover and hover effects do not cause contrast failures
    • Content exposed via hover behaves predictably
    • Content exposed via hover is also keyboard operable
    Why?

    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.

    Partially addresses
  • Validate pointer operations

  • Make sure that...
    • Pointer operations do not cause contrast failures
    • Pointer operations do not rely on multipoint or path-based gestures
    • Pointer operations can be aborted, undone, or reversed
    • Pointer interactions that alter content are noted for keyboard tests
    Why?

    When a pointer acts on content via a click or similar action, resulting indications of a change of state, such as expanded, selected, 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) or path-based gestures can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential. As well, to reduce accidental activation of controls, pointer operations must have the ability to be cancelled.

    For any interaction offered using the pointer, there must be a keyboard equivalent. Any unusual interactions should be noted for future keyboard testing.

    Fully addresses
    Partially addresses
  • Check motion operation

  • Make sure that...
    • Applications do not prevent orientation changes
    • Applications do not rely on motion
    Why?

    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.

    Completes testing for:

Test with a keyboard

    Check tab or navigation order

  • Make sure that...
    • Elements receive focus in an order that preserves meaning
    • No interactive elements are missed
    • Keyboard interaction and navigation is never trapped in a component
    • There is a visual indicator of focus at each tab stop

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

    • All operable parts of the page can be reached using the next/prior gesture
    • From the bottom, all operable parts can be reached by using the prior gesture
    Why?

    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.

    Partially addresses
  • Check focus indicator

  • Make sure that...
    • Initial focus is evident
    • There is a visual indicator every time a key press/action changes focus
    • A focused item is differentiated from a selected item
    Why?

    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.

    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.

    Partially addresses
  • Check component keyboard interaction

  • Make sure that...
    • All actions in a widget can be performed with the keyboard
    • Items can be traversed in forward and reverse order
    • Standard keyboard interaction for a component is supported
    • Visual indicators of focus and state (where relevant) exist
    • Audio, video, and auto-playing content (players) are fully operable with keyboard
    • Audio and video contain appropriate controls to activate captions, audio descriptions, or text alternatives
    • Custom shortcuts are not accidentally triggered
    Why?

    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.

    On iOS mobile devices, similar tests can be carried out using basic VoiceOver gestures in combination with Rotor settings.

    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.

    Completes testing for:
    Partially addresses
  • Check bypass blocks, consistent navigation, and multiple ways

  • Make sure that...
    • Users can skip to main content or move between sections of content
    • ARIA landmarks are consistently structured and labelled
    • No text falls outside a region (orphaned) for ARIA landmarks
    • There are multiple ways to navigate content
    • Navigation mechanisms repeated throughout occur in the same relative order or location
    Why?

    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.

    Fully addresses
    Partially addresses

Assess page transformation

    Resize and re-space text

  • Make sure that...
    • Text wraps appropriately when resized to 200%
    • When zoomed, scrollbars are present and offscreen content can be brought into view
    • Full content is available to the user through focus or activation when text is truncated
    • Content supports increasing the letter, word, paragraph and line spacing
    Why?

    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.

    Fully addresses
  • Reflow text

  • Make sure that...
    • Content can be enlarged to 400% or equivalent
    • Horizontal scrollbars do not appear
    • No content or functionality is lost
    Why?

    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.

    Completes testing for:

Confirm page interaction

    Dynamic update triggers and effects

  • Make sure that...
    • Context changes are only triggered when users activate a control
    • Context changes do not occur when users change their focus
    • Context changes do not occur when users input data
    • Context changes do not occur when users interact with a component
    • Content changes do not contribute to timing issues for a user
    Why?

    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.

    Fully addresses
    Completes testing for:
  • Maintaining user’s point of regard

  • Make sure that...
    • Users return to the same relative position, or point of regard, when they return to a previous screen or page.
    Why?

    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.

    Completes testing for:
  • Error handling and instructions

  • Make sure that...
    • Error handling and instructions are easily detected
    • Errors are described in text
    • If they are known, suggestions for correction are provided
    • Instructions are provided for specific formatting or values
    • Inputs that collect common information about the user are populated automatically (autofill)
    • Users have a chance to check, confirm, or reverse actions
    • There is another indicator if color is used to convey meaning
    Why?

    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.

    Fully addresses

    Completes testing for:

    Partially addresses
  • High contrast and OS settings

  • Make sure that...
    • When platform high contrast is activated, the application adopts the high contrast theme
    • After high contrast is activated, focus indicators and component interaction remain visible via keyboard
    • After high contrast is activated, all images and icons that convey important information are visible or replaced by a text alternative
    • After high contrast is activated, pointer effects are still visible
    Why?

    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.

    Partially addresses

    Software:

  • Time limits

  • Make sure that...
    • For each time limit that is set by the content, the user can turn off or adjust the time limit before encountering it, or the user is warned before time expires and allowed to extend it
    • If there are no means to turn off or extend time limits, confirm it is an allowable exception
    Why?

    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.

    Fully addresses