a11y teacher edition W3C WCAG 2.2 & WCAG 3.0 draft reference
Plain English Accessibility Hub

Translating W3C Standards for Designers, Developers, QA & Product teams

SC 4.1.3 Level AA Robust

Status Messages

WCAG 2.2 success criterion • Guideline: Compatible

Tier 1 ยท The normative floor

Baseline compliance

What the normative text of WCAG 2.2 requires, and nothing more. Only a failure of this tier is a WCAG failure.

The bare minimum

In content built with markup languages, status messages can be programmatically determined through role or properties, so assistive technologies can present them without them receiving focus. WCAG defines a status message as a change in content that isn't a change of context and that tells the user about success or results, waiting, progress, or errors.

Normative text

Verbatim from WCAG 2.2, W3C Recommendation 12 December 2024. Underlined terms are defined below.

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.

Not required by the normative text

Common claims that this criterion does not support. Don't log these as WCAG failures.

  • Announcing messages that take focus or change context. Those aren't status messages by definition.
  • Announcing every dynamic change. Only status messages as defined.

Definitions used (4)

Glossary definitions are normative. Their notes are informative.

status message

change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

programmatically determined

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

role

text or number by which software can identify the function of a component within Web content

assistive technology

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

Informative notes (3)

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles.

Tier 2 ยท The gap

Usability & user impact

Where content can meet this criterion and still make things harder for people with disabilities. These are not failures of SC 4.1.3, so raise them as usability defects. Known failures, including failures of related criteria, are listed in Tier 1.

Over-announcing (live regions for every update) can drown out the messages that matter.

Tier 3 ยท The golden path

Recommended best practice

The pattern that meets the floor, closes the gap, and avoids audit disputes. A recommendation, not a requirement.

Use role="status" for results and progress and role="alert" sparingly for urgent errors, and keep messages short.

W3C's Understanding document and techniques for SC 4.1.3 โ†— are informative: sufficient techniques show ways to pass, and documented failures show common ways to fail, but neither changes what the criterion requires.

How SC 4.1.3 maps to the WCAG 3 draft

From this site's reviewed map to the WCAG 3 editor's draft. It's an interpretation: W3C has not published a mapping.

Successor provisions

From WCAG 2.2, section 5.1: โ€œThe main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.โ€