Make a quote-request receipt discoverable without moving focus unnecessarily

Identify whether the receipt changes the page

Complete a marked request and observe whether the browser loads a new page or updates the existing form. A small success message inserted dynamically may be visible to a sighted visitor but not announced through assistive technology. Record the actual acceptance state and receipt behavior. The first question is whether the customer can discover the outcome of their task.

Match the announcement to the accepted state

WCAG Status Messages addresses programmatic communication of applicable status updates without requiring focus. W3C's form-notification guidance also discusses success feedback. Ask the maintainer to choose semantics that fit the actual component. A dynamic status, new confirmation page and dialog have different behaviors; adding a generic alert everywhere is not a complete design solution.

Use the receiving evidence your system actually provides. If it stores submissions, inspect the marked record there. Otherwise ask the maintainer to verify server acceptance and the intended receiving destination through supported logs or delivery evidence. A thank-you screen alone is not proof. Wix-specific submission-table names belong to the Wix example.

Source checks: W3C: Understanding Status Messages · W3C WAI: User Notification

Test what the user hears after submission

Use appropriate assistive-technology support to test the receipt. The owner can define the acceptance boundary and wording, while the maintainer verifies implementation. Keep the test non-sensitive and marked. Observe whether the message is announced once, whether it describes the correct state and whether the next action remains reachable.

• Confirm a successful test has a matching accepted request in the receiving system.
• Identify whether the receipt is a dynamic status, new page or interactive dialog.
• Ask the maintainer to implement supported semantics for that actual receipt type.
• Test the announcement and the customer's route to next-step information.
• Repeat an invalid-input test and confirm it does not announce successful receipt.

Avoid repeated or premature success messages

Do not announce success before the request is accepted. Repeated messages on every field change can become distracting. Moving focus unexpectedly may interrupt review or navigation, while a silent update leaves the outcome undiscoverable. If the receipt says a booking is confirmed when the record is pending, accessible delivery of that text does not fix its accuracy.

Record the announcement and request separately

Record the receipt type, announced wording and test environment, along with a request reference or supported acceptance and delivery evidence. Note duplicate, missing or incorrect announcements. These observations establish the behavior of the tested component and state. They do not certify every assistive-technology combination or show a quantified business result.

Preserve receipt semantics during redesign

Keep the approved receipt wording and semantic behavior with the form configuration. Retest after changing the component, redirect or confirmation layout. Maintain a clear fallback contact route for an uncertain delivery result. Staff should understand that the receipt confirms acceptance of a request, not necessarily review, pricing or appointment approval.

Worked example: an illustrative customer journey

For example, a service form saves TEST-ANNOUNCE-3901 and replaces its button area with 'Request received'. The visual update works, but the tested screen-reader path gives no status announcement. The maintainer adjusts the supported dynamic-message implementation.

A repeat test announces the accepted receipt once and keeps useful next-step information reachable. A rejected test receives a different outcome. This demonstrates state-specific feedback, not full accessibility certification or evidence that all customers use the same device.

Questions about this task