WCAG 2.1 & Quality Assurance

Overview

The success criterion states that content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Adaptable: The website should function properly in any device orientation. Rotating the device should not cause any loss of functionality.

How to test

Accessing a website via a tablet, a smart phone or other mobile devices. Verify the website works as intended in every orientation allowed by the device.

Signs of failure

• Website/videos stay in the same format when tablet, phone, or other orientation-driven device is turned.
• Controls do not function the same in landscape mode as portrait mode.
• Website messages and eReader do not display information properly in portrait and landscape modes.

Overview

The success criterion states that the purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a function identified in the "Input Purposes for user interface components" section, and
• The content is using technologies that support identifying the expected meaning of form input data.

Adaptable: Text fields should identify the data input type. The browser should store information compatible with input field suggestions (Auto fill of UID, email, phone, etc.).

How to test

Verify:

• The form's label matches the autocomplete token in the input.
• The browser identifies the user's basic personal information and purpose from stored data, so the information doesn't need to be re-entered after the first time.

Signs of failure

• Some personal information fields are not suggested by the browser or automatically filled.
• Autofill suggests the wrong type of information in data fields.

Overview

The success criterion states that the content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

• 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.
• Examples of content which requires two-dimensional layout are: images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

Adaptable: The website should resize to display properly on various devices, including computers, tablets, and phones, without loss of functionality.

How to test

• View the website on different types of mobile devices, and verify it only scrolls in one dimension (usually vertically).
• Verify that when text is enlarged (zoomed at 400%), the text does not cause the website to be scrollable in two directions to view the content.

Signs of failure

• When accessing a website on a mobile device, the onscreen text requires horizontal and vertical scrolling to read the content.

Overview

The success criterion states that the visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

• User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
• Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Adaptable: An updated success criterion now includes non-text elements, such as graphical objects and user interface components, under the Contrast Minimum requirement. These elements must have a contrast ratio of at least 3:1.

How to test

Use a color contrast tool to verify the interface components and essential parts of graphical objects meet the 3:1 ratio requirement.

Pay attention to keyboard focus, notably the focus around buttons and graphics such as stylized links.

Testing tools

• Dev Tools (within a browser - use F12 or right-click and select Inspect)
• Accessible Name & Description Inspector (ANDI) Bookmarklet
• WAVE Extension Tool
• WebAIM Contrast Checker or Colour Contrast Analyser

Signs of failure

• User interface components are difficult to differentiate from their background or do not meet the 3:1 ratio requirement.
• Graphical objects are difficult to differentiate from their background or do not meet the 3:1 ratio requirement.

Overview

The success criterion states that In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Adaptable: Text spacing should be adjustable to improve readability. This includes minimum standards for line height (line spacing), paragraph spacing, letter spacing, and word spacing. Users should be able to adjust these settings without losing functionality.

How to test

• Verify that the user can modify the text spacing via style sheet, bookmarklet, extension, or application.
• Inspect the code to note whether the author set the CSS height property. If authors do not set the CSS height property, it can help ensure that paragraphs expand.
• Experiment with expanding the text by interacting with the text with an extension or application.

Signs of failure

• The author has set the CSS height property.

Overview

The success criterion states that where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

• Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
• Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Adaptable: Content displayed on hover can be dismissible, hoverable, or persistent.

How to test

For each area of additional content that appears on pointer hover:

• The pointer can move over the new content without the additional content disappearing.
• The appearance of additional content is controlled by the user agent, not the author.

Signs of failure

• Tooltip or hover-content cannot be dismissed.
• Tooltip or hover-over content is not persistent and disappears after a certain amount of time, even if the user is still engaged with it.

Overview

The success criterion states that if a keyboard shortcut is implemented in content using only letters (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
• Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Distinguishable: Users should be able to turn off shortcuts, remap them, or set them to work only when a component is focused (so the shortcut applies only to the focused component, not the entire page).

Note: This success criterion does not apply if keyboard shortcuts have not been implemented.

How to test

• Determine if the website or app has specific keyboard shortcuts and if users can turn them off or remap them with one or more modifiers. Verify if the keyboard shortcut works only when an element receives focus.

Signs of failure

• If the user is unable to turn off or remap keyboard shortcuts.

Overview

The success criterion states that all functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Note: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Distinguishable: If multipoint or path-based gestures (like pinching, swiping, or dragging across the screen) are not required for functionality, the same action should be achievable with a single-point activation, such as pressing a zoom button on a map.

How to test

For each part of the content that includes a function activated by a path-based gesture:

• Check controls are available to perform the same function with simple taps or clicks using a keyboard or touch.

Signs of failure

• If no other means of activating the functionality exists, the content fails this success criterion.

Overview

The success criterion states that for functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

How to test

Open the content on a device with pointer inputs (mouse, touchscreen, stylus) and for all available controls (buttons, links, complex widgets):

• Trigger down-events (e.g., by pressing but not releasing the mouse button, or placing a finger or stylus on the touchscreen) and check if functionality is executed prior to the up-event (e.g., releasing the mouse button or lifting the finger/stylus).
• If functionality was executed on the down-event, check if triggering the up-event (releasing the pressed mouse button or lifting the finger or stylus from the touchscreen) reverses the outcome.
• Evaluate if it could be deemed essential for the controls to execute and complete functionality on the down-event.

Signs of failure

• Functions activate on the down event that do not need to.

Overview

The success criterion states that for user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Note: A best practice is to have the text of the label at the start of the name.

Distinguishable: For user interface components with labels that include text or text images, the name should match the text presented visually.

How to test

For all controls with a visible label (e.g., link text, button text, programmatically linked label, images in links with text), check that:

• The accessible name is the same as the visible label.
• The accessible name contains a match for the string of the visible label.

Testing tools

• Dev Tools (within a browser - use F12 or right-click and select Inspect): Accessibility Tab (to view the Accessibility Tree)
• Accessible Name & Description Inspector (ANDI) Bookmarklet
• WAVE Extension Tool

Signs of failure

Code inspections either manually or via an automation tool:

• The text in a search button reads "Go" but the accessible name provided in an aria-label attribute is "Find in this site"
• <button id="sitesearch" aria-label="Find in this site">Go</button>

A download link reads "Download specification" but there is invisible link text so the accessible name of that link is "Download gizmo specification." While the visible label text is contained in the accessible name, there is no string match which may prevent the link from being activated by speech input:

• <a href="#">Download <span class="accessibly-hidden">gizmo</span> specification</a>

An input of type="submit" with the value="search" which is exposed as a visible label of the input, has a programmatically linked and accessibly hidden label enclosing the text "Find in this site" referenced by aria-labelledby. Because aria-labelled by takes precedence over the value of the input, the accessible name of the input in most browser/screen reader combinations will be "Find in this site." Speech users speaking a command such as "Click search" will be unable to activate the input:

• <div id="hidden-label">Find in this site</div>
• <input type="submit" aria-labelledby="hidden-label" value="search">

Overview

The success criterion states that functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported interface: The motion is used to operate functionality through an accessibility supported interface;
• Essential: The motion is essential for the function and doing so would invalidate the activity.

Distinguishable: The functions triggered by moving a device (shaking or tilting) can be operated by conventional user interface components.

How to test

For each function triggered by a motion sensor:

1. Check if a motion sensor is essential or required for making the function accessible.
2. Check if there is a user setting that can disable motion detection.

Signs of failure

• If #1 and #2 are false, the control fails this success criterion.

Overview

The success criterion states that in content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Compatible: Ensure users are informed of important content changes that do not receive focus, without disrupting their workflow. Status messages should be programmatically determined and presented to the user without automatically taking focus.

How to test

• Access the website, trigger all alerts and status messages, then verify focus does not automatically change to the status alert/message.
• Verify status alert/message is dismissible without changing focus (commonly using the "Escape" key).

Signs of failure

• Focus jumps to status alert/message instead of staying on the focus before the status alert/message.
• Inability to dismiss status alert/message without changing focus.