Confirm success when a submission works
G199 puts a message on screen confirming that a submission worked, so the reader is not left guessing. Status is split here and the split matters. W3C marks it sufficient only for 4.1.3 Status Messages at Level AA, and only when it is paired with the ARIA technique that announces the message without moving focus. At the three error-handling rules, including error identification at Level A, W3C lists it as advisory, which means recommended and not accepted as evidence of conformance. The reason is plain once stated. Confirming success is not identifying an error, so a success message cannot satisfy a rule about errors. W3C's own test for this technique is visual only, checking that a message appears. The programmatic half is what the pairing supplies.
How we find it in an audit
Our reviewers submit forms correctly and watch what happens with a screen reader running. A banner that fades in silently is the common finding, because it satisfies the eye and announces nothing. We check the message is exposed as a status, that focus stays where it was, and that the wording says what happened rather than only that something did.
How affected users experience it
A screen reader user presses Submit and hears nothing. Did it send? They re-read the page hunting for a clue, submit again to be safe, and now hold two support tickets and a worry about being charged twice. An announced 'Your request was sent, reference 4471' ends the transaction with certainty instead of doubt, and costs one attribute to deliver.
Passes vs. fails
Passes
<div role="status">Message sent. We will reply within two business days.</div> is populated on success, visible to everyone and announced automatically.Fails
After submitting, a green banner fades in at the top of the page, nothing is announced, and focus stays on the button as though nothing happened.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Error message describes invalid form field valueA tool finds candidates, you decide
The other techniques filed under this rule
13 guides on this site are filed under 3.3.1 Error Identification. W3C lists this one as advisory for that rule rather than sufficient, which means it helps real readers without being accepted as evidence you conformed.
- ARIA18sufficientRaise blocking errors in an alert dialog
- ARIA19sufficientAnnounce form errors with role=alert
- ARIA21sufficientFlag invalid fields with aria-invalid
- G83sufficientTell users which required fields they missed
- G84sufficientExplain when input is not an allowed value
- G85sufficientExplain format errors and show the fix
This guide is our interpretation of W3C technique G199: Providing success feedback when data is submitted successfully. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.