UX WRITING · FORMS & RECEIPT

“Message sent”: was your request actually received?

Understand errors, resume your input and check receipt: try the states of a form.

Submit the empty form. Then compare the wording, with identical rules.

Your fictional request

Demo with fictional data. No message is sent to Edikka.

All four fields are required.

The form stays inactive until JavaScript starts.

Summary wording

The same messages appear in the summary and beside the fields. Validation starts on submission, then updates when leaving a field.

Follow what happens

What the interface knows

Nothing submitted.

What the service has recorded

Simulation register · browser memory

Attempts received by the service: 0
Records created: 0

Reference confirmed to the interfaceNot confirmed

This panel explains internal events. The form uses only responses it actually receives.

Trial timeline

No attempt made.

What this trial shows

No conclusion before the trial.

Contract and trial details

An opaque key belongs to a snapshot. A retry keeps the key. Different content under the same key produces a conflict.

The register disappears when the page closes (simulation) or the server stops (HTTP). No email.

Next status check (counter-test)

This counter-test sends other fictional text under the existing key. It does not replace the original request.

{}

Export evidence without field values

Exports exclude entered values and their fingerprints. Links include only language and scenario.

EDIKKA · METHOD & LIMITS

Words that match what is known.

Four bounded experiments, two modes, one rule: only confirm what a response establishes.

An extension of the UX writing protocol

The Edikka archive dated 3 September 2026 (v1.0.1) records two wording corrections on the contact form: UXW07 and UXW08. UXW09–UXW12 were already satisfied. UXW06 belongs to the AI agent test and remains “To test”. This demo does not rewrite those observations.

Public simulation, real local HTTP lab

On GitHub Pages, no field leaves the browser. The local lab actually reserves and stores in memory on 127.0.0.1; scenario C closes the connection after storage. Both modes share validation and contract. A browser-simulated fault is not a real HTTP interruption.

Keyboard, errors and announcements

The summary receives focus after an invalid submission. Its links target the fields. Hints stay associated. One status region announces responses without moving focus; the summary does not combine focus with a live alert. DOM observations do not prove what a screen reader announces.

Four documented scenarios

Understand and correct
Submit the empty form. Then compare the wording, with identical rules.
Retry after a refusal
The first valid attempt is refused before storage. A retry is allowed and can succeed.
Lost response
The service records the request, then the response is lost. What can the form say?
Wait without duplicates
The service waits 4 seconds before recording. Activate the button again, then retry the same request.

Explained example: after a lost response, a request may already be recorded. The interface stays uncertain until a status response arrives. Retrying the same key finds the same record.

No claim of global conformance, user research or conversion improvement. No email delivery, no contact forwarded, no durable storage.

Sources and reproduction

WAI · Forms notifications · WCAG 3.3.1 · WCAG 3.3.3 · WCAG 4.1.3 · GOV.UK · Error summary · GOV.UK · Error message