WCAG 2.1

The Web Content Accessibility Guidelines 2.1, commonly known as WCAG 2.1,
provide testable requirements for making websites and web applications more
accessible to people with disabilities.

WCAG 2.1 was published by the World Wide Web Consortium as a W3C
Recommendation on June 5, 2018. It extends WCAG 2.0 with additional
requirements addressing mobile accessibility, people with low vision and
people with cognitive and learning disabilities.

WCAG 2.1 remains a valid accessibility standard. However, W3C encourages
organisations beginning new accessibility work to use the latest version,
WCAG 2.2, because it includes all WCAG 2.1 requirements together with
additional success criteria.

What is WCAG 2.1?

WCAG 2.1 is a technology-neutral accessibility standard for web content.
It can be applied to websites, web applications, online forms, multimedia,
documents delivered through the web and browser-based digital services.

The guidelines are intended for:

• Web developers.
• Designers.
• Content authors.
• Product teams.
• Quality-assurance teams.
• Accessibility auditors.
• Procurement teams.
• Organisations defining digital-accessibility requirements.

WCAG 2.1 and WCAG 2.0

WCAG 2.1 includes all of the success criteria from WCAG 2.0 and adds
17 new success criteria.

This means that content conforming to WCAG 2.1 also conforms to WCAG 2.0
at the same level, provided all applicable conformance requirements are met.

WCAG 2.1 preserves:

• The four accessibility principles.
• The existing WCAG 2.0 guidelines.
• The A, AA and AAA conformance levels.
• The numbering of the earlier success criteria.
• The WCAG conformance model.

The four WCAG principles

WCAG requirements are organised under four principles, often abbreviated
as POUR.

Guidelines, success criteria and techniques

WCAG contains several layers of guidance.

Principles

The four principles provide the highest-level accessibility framework.

Guidelines

Guidelines organise broad accessibility objectives, such as providing text
alternatives, making functionality keyboard accessible and helping users
avoid mistakes.

Success criteria

Success criteria are the testable requirements used to determine WCAG
conformance.

Techniques

W3C publishes sufficient and advisory techniques showing possible ways to
meet the success criteria. Techniques are helpful implementation guidance,
but they are not themselves the normative requirements.

WCAG 2.1 conformance levels

Level AA is commonly referenced in legislation, procurement policies and
organisational accessibility standards. Meeting Level AA requires satisfying
all applicable Level A and Level AA success criteria.

It is not generally recommended to require Level AAA for an entire website
because some types of content cannot satisfy every Level AAA success criterion.

What did WCAG 2.1 add?

WCAG 2.1 added 17 success criteria to address accessibility gaps involving
mobile devices, low vision, touch interaction and cognitive or learning
disabilities.

New Level A success criteria

2.1.4 Character Key Shortcuts

When functionality uses a shortcut consisting only of a letter, number,
punctuation mark or symbol, users must be able to turn it off, remap it or
limit it to when the relevant component has focus.

This helps prevent speech-input users from activating commands accidentally.

2.5.1 Pointer Gestures

Functionality requiring multipoint or path-based gestures must also be
available through a simpler single-pointer method unless the gesture is
essential.

For example, a user should not be required to perform a precise swipe,
pinch or drawn movement when a button or simple tap could provide the
same result.

2.5.2 Pointer Cancellation

Pointer actions should not normally complete as soon as the pointer is
pressed down. Users should have an opportunity to cancel or reverse the
action before it is completed.

This reduces accidental activation for users with limited dexterity,
tremors or difficulty controlling a pointer.

2.5.3 Label in Name

When an interface control has visible text, its accessible name should
contain that visible text.

This supports speech-input users who activate controls by saying the label
they can see.

2.5.4 Motion Actuation

Functionality triggered by moving the device or detecting user motion must
also be available through interface controls, and users must be able to
disable motion activation unless it is essential.

For example, shaking a phone should not be the only way to undo an action.

New Level AA success criteria

1.3.4 Orientation

Content should not be restricted to portrait or landscape orientation unless
a specific orientation is essential.

This supports users whose devices are mounted in a fixed position and users
who cannot easily rotate a phone or tablet.

1.3.5 Identify Input Purpose

Fields collecting common personal information should expose their purpose
programmatically when the field matches one of the defined input purposes.

This can support browser autofill, personalised presentation and assistive
technologies.

1.4.10 Reflow

Content must reflow without loss of information or functionality when viewed
at a width equivalent to 320 CSS pixels for vertical scrolling content,
subject to defined exceptions.

Users should not normally need to scroll in two dimensions to read paragraphs
or operate controls after zooming.

1.4.11 Non-Text Contrast

Important visual information used to identify controls, states and graphical
objects must have sufficient contrast against adjacent colours.

This can include input borders, selected states, focus indicators and
meaningful chart elements.

1.4.12 Text Spacing

Users must be able to apply specified increases to line height, paragraph
spacing, letter spacing and word spacing without losing content or
functionality.

This supports users who adjust text presentation to improve readability.

1.4.13 Content on Hover or Focus

Additional content appearing on hover or keyboard focus must generally be
dismissible, hoverable and persistent.

Examples include tooltips, custom dropdowns and informational popovers.

4.1.3 Status Messages

Important status messages must be programmatically communicated to assistive
technologies without requiring the message to receive focus.

Examples include:

• An item was added to a shopping cart.
• A form was submitted successfully.
• Search results were updated.
• A loading process completed.
• A validation error occurred.

New Level AAA success criteria

1.3.6 Identify Purpose

The purpose of interface components, icons and regions should be
programmatically determinable where the implementation supports the
defined vocabulary.

2.2.6 Timeouts

Users should be informed about inactivity timeouts that could cause data
loss unless the data is preserved for a defined period.

2.3.3 Animation from Interactions

Motion animation triggered by interaction should be disabled when users
request reduced motion, unless the animation is essential.

2.5.5 Target Size

Pointer targets should generally be at least 44 by 44 CSS pixels, subject
to the exceptions defined in the criterion.

2.5.6 Concurrent Input Mechanisms

Websites should not restrict users to one input mechanism when other
supported methods are available.

For example, connecting a keyboard should not prevent a user from continuing
to use touch input.

WCAG 2.1 and mobile accessibility

WCAG 2.1 does not contain a separate mobile-accessibility section. Its success
criteria apply across desktop, tablet and mobile experiences.

Important mobile considerations include:

• Supporting portrait and landscape orientation.
• Providing alternatives to complex gestures.
• Preventing accidental pointer activation.
• Supporting device and browser zoom.
• Allowing content to reflow.
• Providing sufficient contrast for controls.
• Supporting external keyboards.
• Providing alternatives to motion activation.
• Ensuring controls work with mobile screen readers.

Keyboard accessibility

WCAG 2.1 requires web functionality to be available through a keyboard
interface except where the underlying function depends on the path of the
user’s movement.

Keyboard testing should confirm that:

• All interactive controls receive focus.
• Focus order is logical.
• Focus is visible.
• No component creates a keyboard trap.
• Menus and dialogs support expected keyboard behaviour.
• Hidden content does not remain in the tab order.
• Focus is managed after dynamic changes.

Read the practical guide to

ARIA and keyboard accessibility
.

Forms and input accessibility

Accessible forms should provide:

• Visible and programmatically associated labels.
• Clear instructions.
• Identification of required fields.
• Accessible error messages.
• Suggestions for correcting invalid information.
• Logical focus movement.
• Programmatic input purposes where applicable.
• Review and confirmation for important transactions.

A form must be tested as a complete user journey rather than only as a
collection of individual fields.

Responsive design and reflow

Responsive design can help meet reflow requirements, but a responsive layout
is not automatically accessible.

Teams should test whether:

• Text can be enlarged without overlapping.
• Controls remain visible and usable.
• Content does not disappear at narrow widths.
• Navigation remains accessible.
• Dialogs fit within the viewport.
• Users are not forced to scroll horizontally to read paragraphs.

Content displayed on hover or focus

Tooltips, menus and popovers can create barriers when they disappear too
quickly or block other content.

When additional content appears on hover or focus, users should generally
be able to:

• Dismiss it without moving focus.
• Move the pointer over the additional content.
• Keep it visible until it is dismissed or no longer relevant.

Status messages and dynamic interfaces

Modern web applications frequently change content without loading a new page.
Visual updates alone may not be communicated to screen-reader users.

Important status messages may include:

• Search results were loaded.
• A product was added to the cart.
• A filter changed the results.
• A form contained errors.
• A save operation completed.
• A process is still loading.

Developers may use appropriate status roles or live-region techniques, but
announcements should be concise and should not interrupt users unnecessarily.

Does WCAG 2.1 guarantee legal compliance?

WCAG 2.1 is a technical standard, not a law by itself.

It may become legally or contractually relevant when it is referenced by:

• National or regional legislation.
• Government regulations.
• Public procurement requirements.
• Contracts.
• Settlement agreements.
• Internal organisational policies.

Meeting WCAG 2.1 can provide strong technical evidence of accessibility,
but legal compliance depends on the applicable law, jurisdiction, scope and
circumstances.

WCAG 2.1 and WCAG 2.2

WCAG 2.2 includes the WCAG 2.1 success criteria and adds nine new success
criteria.

The additional WCAG 2.2 criteria address:

• Keyboard focus being obscured.
• Focus appearance.
• Dragging movements.
• Minimum target size.
• Consistent help.
• Redundant data entry.
• Accessible authentication.

WCAG 2.2 also removes Success Criterion 4.1.1 Parsing because it is considered
obsolete in modern web technology. The remaining WCAG 2.1 success criteria
continue unchanged in WCAG 2.2.

Organisations beginning new audits or development work should generally use
WCAG 2.2 unless a law, contract or procurement requirement specifically
identifies another version.

How WCAG conformance works

A valid WCAG conformance claim applies to complete web pages.

Important conformance requirements include:

• All applicable success criteria at the claimed level must be satisfied.
• Complete processes must conform, not only selected steps.
• Accessibility-supported technologies must be used.
• Nonconforming content must not interfere with the accessible use of the page.

A claim should identify the WCAG version, conformance level, scope and
technologies relied upon.

Automated testing and WCAG 2.1

Automated tools can detect many accessibility problems, including:

• Missing alternative-text attributes.
• Some contrast failures.
• Missing form labels.
• Duplicate identifiers.
• Invalid ARIA attributes.
• Some heading and landmark problems.

Automated testing cannot determine complete WCAG conformance.

Human review is required to evaluate:

• Whether alternative text is meaningful.
• Whether focus order is logical.
• Whether keyboard interactions work.
• Whether status messages are announced correctly.
• Whether errors are understandable.
• Whether a complete user journey can be finished.
• Whether content remains meaningful after reflow or zoom.

How to test against WCAG 2.1

1. Define the scope:
   identify templates, pages, components, documents and critical user journeys.
2. Run automated scans:
   detect repeatable technical findings across representative content.
3. Perform keyboard testing:
   verify access, focus order, visibility and operation without a mouse.
4. Test responsive behaviour:
   review orientation, zoom, reflow and text spacing.
5. Test forms and errors:
   complete important form journeys from beginning to end.
6. Test dynamic components:
   review menus, tabs, dialogs, tooltips and status messages.
7. Use assistive technologies:
   test representative journeys with screen readers and other relevant tools.
8. Review content:
   assess alternative text, headings, links, instructions and multimedia.
9. Document findings:
   record the affected element, user impact, criterion and reproduction steps.
10. Verify remediation:
    retest corrections before closing findings.

Common WCAG 2.1 failures

• A mobile interface works only in portrait orientation.
• Content requires horizontal scrolling after zoom.
• Input borders have insufficient contrast.
• A tooltip disappears when users move the pointer toward it.
• A voice user cannot activate a button using its visible label.
• A carousel requires a precise swipe gesture.
• Shaking the device is the only way to perform an action.
• A shopping-cart update is not announced to screen readers.
• Text-spacing adjustments cause content to overlap.
• Single-character keyboard shortcuts activate unexpectedly.

Prioritising remediation

Teams should prioritise barriers based on user impact, frequency and the
importance of the affected journey.

High-priority areas commonly include:

• Navigation.
• Authentication.
• Registration.
• Search.
• Forms.
• Checkout and payment.
• Booking.
• Customer support.
• Essential documents.

Shared templates and reusable components should often be corrected first
because one fix can remove the same barrier across many pages.

Maintaining WCAG conformance

Accessibility can regress after:

• A website redesign.
• A content-management-system update.
• A new form or component.
• A third-party integration.
• A design-system change.
• A new document or video upload.
• A mobile-app release.

Accessibility should therefore be included in design, development,
content publishing, quality assurance and release management.

How Pluro supports WCAG accessibility workflows

Pluro is an accessibility workflow platform that helps organisations manage
findings from detection through verified remediation.

Teams can use Pluro to:

• Centralise automated and manual findings.
• Capture keyboard and behavioural evidence.
• Connect findings to WCAG criteria.
• Assign responsibility to design, development, content or QA.
• Provide remediation guidance.
• Track correction status.
• Verify fixes before closing findings.
• Maintain an accessibility history.
• Monitor websites after future changes.

Pluro is not an overlay or a one-click compliance solution. Automated
detection is combined with controlled remediation, manual review and
verification.

WCAG 2.1 checklist

• Define the required WCAG version and conformance level.
• Include all complete user journeys in the scope.
• Test with automated and manual methods.
• Verify keyboard access and visible focus.
• Test orientation, reflow and text spacing.
• Review contrast for text and interface components.
• Provide accessible names, labels and instructions.
• Support simple pointer alternatives.
• Provide alternatives to motion activation.
• Communicate important status messages.
• Test forms, media and documents.
• Verify fixes with assistive technologies.
• Retest after releases and content updates.

Important notice

This page provides general information and does not constitute legal advice
or a formal WCAG conformance audit. Accessibility requirements depend on
the website, applicable law, contract, jurisdiction and assessment scope.

Review the official

Web Content Accessibility Guidelines 2.1
.

Review

what WCAG 2.1 added
.

See how Pluro manages accessibility workflows
or
start a 14-day free trial
with no credit card required.