[wcag-3.0] Submission status should require programmatic notification and distinct pending/success/failure states

Accessibility Guidelines Working Group,

I am submitting a focused comment on the current WCAG 3 Working Draft
concerning Guideline 2.5.2, particularly the supplemental requirement
“Submission status notified.”

The current requirement says that data entry interfaces notify users
of submission status when submission succeeds or fails, and its test
checks that the user is notified immediately afterward. However, it
does not explicitly require that the submission outcome be conveyed
programmatically. That differs from nearby requirements such as
“Page/view change notified,” which explicitly require both a visual
change and programmatic notification, and “Change of content
notified,” which requires meaningful visual changes such as status or
error messages to be conveyed programmatically.

I suggest making equivalent programmatic access explicit for
submission state, and distinguishing pending or indeterminate state
from confirmed success and failure when those states exist.

Possible requirement language:

“When a data submission is initiated, its meaningful submission state
is available visually and programmatically. Pending or indeterminate,
confirmed success, and failure are distinguishable when those states
exist. A confirmed-success state is not communicated while the result
remains pending or indeterminate.”

This could remain implementation-neutral. A synchronous operation that
returns a confirmed result immediately would not need an artificial
pending state. For asynchronous or network-dependent submissions,
however, a user should not receive an accessible equivalent of
“submitted successfully” until the application has actually reached
that state.

A useful test matrix would include:

- Initiate a submission whose response is intentionally delayed;
verify that pending/indeterminate state, when presented visually, is
also programmatically available.

- Complete the submission successfully; verify that the transition to
confirmed success is conveyed visually and programmatically without
requiring an unrelated focus movement.

- Cause a server or network failure; verify that failure is conveyed
visually and programmatically and that confirmed success is not
announced.

- Where the outcome message is temporary, verify that users have
sufficient opportunity to perceive or revisit the result.

This is especially important for consequential submissions such as
applications, payments, medical or benefits forms, emergency-service
requests, and other transactions where uncertainty about whether the
action completed can itself cause harm. A sighted user may see a
spinner, banner, restored form contents, or visual error state while
an assistive-technology user receives no equivalent state
transition—or receives an optimistic success message that is later
contradicted visually.

I also suggest considering whether “Submission status notified” should
remain supplemental. For a data-entry interface, knowing whether a
submitted action succeeded or failed is often necessary to complete
the task at all, and programmatic outcome awareness seems analogous to
the core treatment already given to page/view changes and meaningful
content changes.

Thank you for considering the comment.

Seth Morrow

Received on Saturday, 29 August 2026 00:46:47 UTC