[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