WCAG 2.1 success criteria and foundational testing

OCTO-DE has determined WCAG 2.1 Level A and AA success criteria will be the new standard for accessibility in web applications and content. This new standard improves accessibility for mobile, cognitive, and vestibular considerations.

What’s new in WCAG?

WCAG 2.1 introduces 17 new success criteria to improve accessibility for mobile and cognitive considerations. Platform is committed to meeting 13 of these criteria in our drive for accessibility beyond compliance.

Veteran-facing services (VFS) teams are responsible for ensuring the accessibility of the products. The Office of the Chief Technology Officer - Digital Experience (OCTO-DE) platform supports their work at scale by creating and maintaining VA.gov accessibility standards required for production and by providing guidance as VFS teams work to meet those standards. Code quality is the responsibility of each individual VFS team.

Working with Platform - accessibility roles and responsibilities

Why do we need this?

WCAG 2.0 became a legal requirement for government websites in 2018. It moved us from a simpler, less mature set of rules (WCAG 1.0) to a more comprehensive set of rules—for the desktop web.

WCAG 2.0 didn’t include much for mobile or cognitive considerations. The mobile-first web wasn’t well established when WCAG 2.0 was written.

WCAG 2.1 was written to address mobile-first web considerations. It became a W3C Recommendation in June 2018. WCAG 2.1 goes above our legal requirement, but is the standard OCTODE has committed to.

OCTO-DE’s expectation for accessibility defects

Code quality is the responsibility of each individual VFS team. This includes:

Meeting Section 508 compliance for WCAG 2.0 Level A and AA success criteria
Meeting new WCAG 2.1 Level A and AA success criteria

How will we define success with WCAG 2.1?

Web applications, web content, and documents must meet WCAG 2.0 Level A and AA success criteria to be Section 508 compliant.
Product teams must also meet the 13 new WCAG 2.1 success criteria to be aligned with the OCTO-DE standard for accessibility.
Platform uses automated and manual testing to ensure content and applications are accessible for the largest group of users. Product teams are required to assist with foundational testing, so accessibility specialists can conduct advanced testing, including assistive technologies.

Success criteria labels

Testing will be done by product teams with assistance from accessibility specialists

No additional testing is required. Be on the lookout in future web or native applications.

Updates will be made in the design system. No action required by product teams.

Mobile success criteria

Two smartphones. One is oriented in portrait, the other is oriented in landscape.

There are 5 new mobile success criteria in WCAG 2.1 that we will meet as part of VA’s commitment to accessibility beyond compliance. Designing mobile-first is critical to meeting these requirements. As of August 2021, 48% of VA.gov traffic was from mobile devices. Product teams should work toward a sound mobile solution first, then scale their solutions to larger screens.

Success Criteria 1.3.4 - Orientation (Level AA)

Learn more about success criteria 1.3.4

Short description:
Style your website so that it doesn’t lock on or require a single display mode.

Key takeaways:

Consider usability for vertical and horizontal displays
Consider how layouts respond when devices are rotated

How to test:
Review your application or content using mobile devices in portrait and landscape display.

Success means:

Layout responds to changes in a device’s orientation
Content is readable in both mobile and landscape display modes

Success Criteria 1.4.10 Reflow (Level AA)

Learn more about success criteria 1.4.10

Short description:
Ensure users can zoom in on your website without requiring scrolling in two dimensions.

Key takeaways:

Content must be easy to read:
- On mobile devices
- On browsers zoomed up to 400%
Content shouldn’t spill off the right or left of your page or viewport
Exceptions can be made for data tables or large images, however
Any exceptions can’t cause a poor user experience or they’ll be called out for redesign

How to test:
Review your content with a mobile device (iOS, Android). Also review your content with a browser window set to 1280px width. Zoom the browser to 200%, 300%, and 400%.

Success means:

Content can be read without scrolling in two directions
Content should have good margins from the device edges
Functional UI like buttons, links, and form inputs should be easy to use

Success Criteria 2.5.1 Pointer Gestures (Level A)

Learn more about success criteria 2.5.1

Short description:
We must provide simple alternatives (for example, single tap vs. swipe) for complex motions or gestures on touch screens.

Key takeaways:

Content must be easy to read:
- On mobile devices
- On browsers zoomed up to 400%
Content shouldn’t spill off the right or left of your page or viewport
Exceptions can be made for data tables or large images, however
Any exceptions can’t cause a poor user experience, or they’ll be called out for redesign
We don’t include complex gestures in our website today, but we should be aware of the requirement for future work

How to test:
Use a mobile device to navigate your application or content. Watch for multi-finger gestures or complex interactions.

Success means:

Complex gestures are redesigned to single finger gestures
All application tasks can be completed with simple gestures

Success Criteria 2.5.2 Pointer Cancellation (Level A)

Learn more about success criteria 2.5.2

Short description:
Provide a way to cancel an event trigger when you click with a mouse, press, or touch with your finger.

Key takeaways:

Allow users to abort or undo an action
Avoid down events in JavaScript handlers
- Down events fire as soon as soon as the mouse is clicked or a key is pressed
- Wiring on the “up” or “press” event lets users move their mouse or pointer device away from the pressed element and release to cancel the event

How to test:
Review and interact with your application or content using a mobile device. Press and hold links and buttons, drag your finger away from the input and release.

Success means:

Releasing a button or link when users have dragged their finger away from the input should not take any action

Success Criteria 2.5.4 Motion Actuation (Level A)

Learn more about success criteria 2.5.4

Short description:
For any functions activated by motion (tilting, shaking, gesturing toward the phone), provide a simpler, alternative means of action.

Key takeaways:

Watch for motion actions in future web and native apps. For example, shaking the device to reset a form could also be handled with a tap or click event on a button

How to test:
Review and interact with your application or content using one or more mobile devices. Watch for actions that require users to tilt, shake, or point their device.

Success means:

Motion actuation tasks also allow users to complete tasks with standard UI elements
Motion actuation can be turned off by the user

Cognitive success criteria

A hand held against a window, with droplets of water on the exterior of the window. Another building is partly visible through the window.

There are 4 new cognitive success criteria in WCAG 2.1. Cognition is a large and diverse part of accessibility testing. It requires care and empathy for users, as well as awareness of our own presumptions.

We all process in our own way

Cognitive considerations are a large part of WCAG 2.1. These can include but are not limited to:

Cognitive and learning disabilities
- Significantly reduced ability in one or more areas of cognitive function, such as communication, reading, writing, or math, that affect learning
- Significantly reduced ability to understand new or complex information and learn new skills, with a reduced ability to cope independently
Neurodiversity - the different ways the brain can work and interpret information
Traumatic Brain Injury (TBI) - damage to the brain which can lead to long-term impairment of executive function, memory, learning, coordination, speech, and emotions
Post-Traumatic Stress Disorder (PTSD) - mental health condition that's triggered by a terrifying event — either experiencing it or witnessing it

Success Criteria 1.3.5 Identify Input Purpose (Level AA)

Learn more about success criteria 1.3.5

Short description:
Inputs should be programmatically identifiable for assistive technologies, and use HTML autocomplete attributes where they would be beneficial.

Key takeaways:

Programmatically identifiable means there must be a machine-readable relationship between inputs and their labels. Assistive technology must be able to explicitly determine these relationships.
Autocomplete attributes can help users fill in common information like name, address, city, state, postal code more quickly, and with fewer errors
Autocomplete must be balanced with privacy considerations for public use, like a library or VA medical center. Autocomplete should be turned off in browser settings if the device is likely to be used by multiple people.

How to test:
Enable autofill setting for your preferred browser:

Fill out a form using the same name, address, email, phone number, etc.

Success means:

Inputs with autocomplete attribute enter data on focus
No axe-core violations

Success Criteria 2.2.6 Timeouts (Level AAA)

Learn more about success criteria 2.2.6

Short description:
Users are warned when a period of inactivity could cause data loss. This might occur when users leave a session signed in with no activity.

Key takeaways:

Give users a chance to continue their session. We do this now with a modal window that informs users they’ll be signed out in the next few minutes if they don’t extend their session.
Preserve user data for more than 20 hours

How to test:
If your application requires users to login:

Log in a test user with access to your application
Let the browser session be inactive for 30 minutes
Verify the timeout modal opens and gives you an option to extend your session or log out

Success means:

Users can extend their session easily

Success Criteria 2.5.3 Label in Name (Level A)

Learn more about success criteria 2.5.3

Short description:
Inputs with a text label must have an accessible name that contains the visual label. Accessible labels are a combination of a visual label and contextual information. They can be built using ARIA markup or descriptive visual language.

<!-- Accessible visual label -->
<button type="button">Submit your 10-10ez form</button>

HTML

<!-- Accessible label using aria-label -->
<button
  aria-label="Submit your 10-10ez form"
  name="submit_button"
  type="submit"
  value="Submit"
/>

HTML

Key takeaways:

If your visual label says “Submit,” ask yourself “Submit what?”
Accessible labels should answer that question without needing to read nearby content
A good accessible label might be “Submit your 10-10ez form”
Accessible name calculation

How to test:
Review accessible labels by right clicking an element, and looking for an aria-label or aria-labelledby attribute in HTML.

Success means:

An accessible label is present and communicates clear intent for each repeated button, link, or actionable UI. Assistive technology should announce accessible labels and display accessible labels in application menus for things like links and buttons.

Success Criteria 4.1.3 Status Messages (Level AA)

Learn more about success criteria 4.1.3

Short description:
Status messages (errors, notices, loading indicators) should be announced to assistive technologies without receiving focus.

Key takeaways:

When you need a loading indicator, think about what you’d like it to say. Loading messages should acknowledge that data is loading or a form is being submitted, and also be written in short and succinct sentences so the message can be read before the action is complete.
Error messages should be descriptive and relevant to the input type and data being requested

How to test:
Turn on a screen reader like NVDA or VoiceOver

Review content that uses our Loading Indicator component
Review error messages in forms

Success means:

Loading indicators need a role=”status” and visible text
Screen readers announce loading text, error messages without needing keyboard focus

Vestibular success criteria

Looking down through the center of a spiral staircase.

There is just one new vestibular success criteria in WCAG 2.1. The new success criteria outlines expected behavior when users prefer reduced motion or animation.

It’s more than balance

The vestibular system includes the parts of the inner ear and brain that process the sensory information involved with controlling balance and eye movements.

Vestibular symptoms can include, but are not limited to:

Imbalance or unsteadiness
Vertigo – a spinning or whirling sensation
Dizziness – a lightheaded, floating, or rocking sensation
Blurred or bouncing vision
Nausea
Hearing changes

Vestibular.org - About vestibular disorders

Success Criteria 2.3.3 Animation from Interactions (Level AAA)

Learn more about success criteria 2.3.3

Short description:
Animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Key takeaways:

Design animations using the “less is more” principle. Discuss if animation is warranted for this particular design.
Consider if micro-interactions might enhance your design
Honor users’ preference for reduced motion
- Make sure animations don’t include flashes or strobing effects
- Consider adding a JavaScript check for the “prefers-reduced-motion” setting, and turning off animation if users have it set

How to test:

Turn on the prefers reduced motion setting: MDN: Preferred reduced motion settings
Interact with content that uses animation

Success means:

Animation behavior(s) should be turned off
Scrolling should be instant, not smooth scroll

Color contrast success criteria

There is just one new color contrast success criteria in WCAG 2.1. The new success criteria says adjacent colors (or elements) must have a color contrast of 3:1 or greater. The requirement applies to things like:

User interface components
Graphical objects (charts, backgrounds, divider lines)
Focus haloes

Success Criteria 1.4.11 Non-text Contrast (Level AA)

Learn more about success criteria 1.4.11

Short description:
The visual presentation of user interface components and graphical objects have a contrast ratio of at least 3:1 against adjacent colors.

Key takeaways:

Test color pairs early and often. There are many tools to quickly determine contrast ratios:

How to test:

Check color contrast pairings for non-text items:

Success means:

UI components, graphic objects, focus haloes, all have a 3:1 contrast ratio with adjacent non-text colors.

Text spacing success criteria

There is just one new text spacing success criteria in WCAG 2.1. The new success criteria focuses on text spacing for line height (leading), margin after paragraphs, letter spacing (tracking), and word spacing.

Success Criteria 1.4.12 Text Spacing (Level AA)

Learn more about success criteria 1.4.12

Short description:
Text must be legible at various line heights and font sizes. Users must be able to set multiple text spacing styles without content becoming unreadable or basic functionality being lost.

Key takeaways:

Design headings and paragraphs with good spacing. Think about increasing leading as line length increases.
Test that users can easily and correctly set the following text spacings:
- Line height (leading) at least 1.5 times the font size
- Spacing after a paragraph at least 2 times the font size
- Letter spacing (tracking) at least 0.12 times the font size
- Word spacing at least 0.16 times the font size
All text spacing declarations can be verified using the CSS inspector in modern browser developer tools.

How to test:

Pick two or three views content or application views. Use browser developer tools to adjust CSS for the following typographic declarations:

Success means:

Line height can be at least 1.5 times font size
Margin after paragraphs can be at least 2 times
Letter spacing can be at least 0.12 times
Word spacing can be at least 0.16 times
Avoid !important rules on inline styles for these declarations

Keyboard success criteria

There is just one new keyboard success criteria in WCAG 2.1. The new success criteria focuses on a consistent user experience when using keyboard shortcuts.

Keyboard shortcuts

Some websites like Gmail or GitHub have implemented keyboard shortcuts to let users navigate.

For instance, pressing “j” in Gmail will open the next oldest message. Pressing “k” will open the next newest message. Pressing “.” in GitHub launches a full VSCode editor.

These shortcuts are useful, but must be used responsibly.

Success Criteria 2.1.4 Character Key Shortcuts (Level A)

Learn more about success criteria 2.1.4

Short description:
Certain rules must be followed for keyboard shortcuts in order to maintain basic usability, as well as functionality for assistive technology.

Key takeaways:

Shortcuts like Enter or Space should only be active when an element has keyboard focus
Keyboard shortcuts can be turned off by users
Consider remapping shortcuts to use additional keys like Control or Option

How to test:

Use a keyboard to interact with UI elements like accordions, modal dialogs, forms, or skip navigation links.

Success means:

Shortcuts are only active when an element has focus or
Shortcuts can be turned off or
Users can remap shortcuts to include non-printable keys like Control, Command, Alt