Map the journey
List entry, required fields, help, attachments, consent, submission, error, success and follow-up message.
GUIDE / PROTOCOL
Audit a form from start to finish
A form works when a person understands the request, can correct errors and knows what was submitted.
Direct answer
What should be checked beyond the submit button?
Walk through every form state with keyboard and mobile. Check the need for each field, clear labels, errors, server-side validation, data retention and the confirmation actually received.
01 / Review method
Review method
Test input
Try valid, empty, long, international and invalid values; review labels, examples, tab order and preservation of entered data.
Check server response
Inspect server-side validation, targeted errors, duplicates, network failures, repeated submissions and timeouts.
Check what follows
Verify acknowledgement, functional recipient, stated timeline, stored data and the ability to resume without needless re-entry.
IN PRACTICE
Check a journey, not just a screenshot
A readable screen can still block an action. Test a complete goal: find the right section, use the control, understand the result and go back. Record the first obstacle and its practical effect.
Which check comes first?
Choose the situation you observed. Each path gives a first check, useful evidence and the limit of that check.
The task works with a mouse but not a keyboard
- First check
- Repeat a task using Tab, Shift+Tab, Enter and the component’s expected keys. Track focus: where does it enter, which control receives it and can you leave a menu or dialog?
- Evidence to retain
- Step, key, focused control, open or closed state and the exact point where the task blocks or becomes unclear.
- Limit to remember
- Logical focus order does not certify overall accessibility. Also examine control names, announced states and content reading.
A form rejects input without explaining why
- First check
- Trigger one field error and review its label, expected format and associated message. Check that it can be corrected without losing other useful values.
- Evidence to retain
- Field, non-sensitive test value, message, error-to-field association, focus behaviour and result after correction.
- Limit to remember
- A visible message may not be associated with its field or announced at the right time. Also test submission, confirmation and unavailability.
Text overflows or becomes hard to read
- First check
- Narrow the window, enlarge text and repeat the task. Identify the component forcing the whole page to scroll horizontally; distinguish it from a table needing two-dimensional layout.
- Evidence to retain
- Viewport width, zoom level, language, component, hidden text and genuine need for two-direction scrolling.
- Limit to remember
- One mobile screenshot does not cover every zoom, language and state. A table exception does not justify whole-page overflow.
Further reading
| Situation | Avoid | Useful correction |
|---|---|---|
| Navigation | Testing only with a mouse. | Traverse by keyboard and retain visible focus. |
| Form | Relying on temporary text inside a field. | Keep a visible label and connect the error to its field. |
| Dynamic result | Changing a number without context. | Provide the result, unit and what changed. |
Locate
Does the heading describe the right task?
Act
Is the control accessible and understandable?
Understand
Are the result and next action explicit?
Final check
Repeat the journey with Tab, Shift+Tab and Enter, then at 200% zoom. While scrolling, check that the fixed header does not completely hide the focused control. Open and close the menu using the keyboard, trigger a form error and check that you can correct it. Record the page, action and obstacle observed; these targeted checks are not WCAG certification.
Documentary references
Consulted on .
Reading workshop
Confirmation, storage and delivery need separate evidence
Fictional case DEMO-F22 follows duplicate submission and refresh without transmitting a real message.
Fictional data and records for learning: none of these results comes from a live service query.
An explicit retry contract for K1
The demonstration application specifies that two POSTs with key K1 and identical content return receipt R1 without creating two files. Check that behaviour separately from HTTP status.
First POST
- Scenario observation
- K1; 303 to /receipt/R1
- What it establishes
- A confirmation redirect is observed.
- Next action
- Retain method, response and non-sensitive identifier.
Read and refresh
- Scenario observation
- GET /receipt/R1; 200; refresh uses GET
- What it establishes
- This refresh does not replay POST in the sequence.
- Next action
- Also test another submission, not only this page.
Identical second POST
- Scenario observation
- K1; identical content; same receipt R1
- What it establishes
- The scenario follows its deduplication contract.
- Next action
- Compare processing logs; a key alone is insufficient.
Demonstration internal states
- Scenario observation
- 1 stored file; delivery pending
- What it establishes
- Storage is corroborated, delivery is not.
- Next action
- Display “recorded, delivery pending”; track the next stage separately.
Which conclusion is supported?
Open each proposition to compare its diagnosis. More checks may still be needed.
303 proves the recipient received the message.
No: status establishes neither storage nor delivery.
Safe refresh proves every double click is handled.
No: repeated GET and a second POST are different checks.
One stored file, identical retry grouped, delivery unconfirmed.
Appropriate here. Different content with the same key needs a separate contract-defined case.
Retry and processing record
Case: DEMO-F22 POST 1: K1 → 303 → /receipt/R1 GET and refresh: /receipt/R1; 200 POST 2: K1; identical content; receipt R1 Log: one stored file Delivery: pending Outcome: storage established in case, receipt by recipient unestablished
Link receipt, storage log and delivery tracking by test identifier. Do not put personal form content in URLs or public evidence.
Documentation of the rules, separate from fictional examples
02 / Evidence to keep
Evidence to keep
Case matrix
Inputs, expected state, displayed message and observed outcome for each case.
Journey capture
Labels, help, focus, errors, summary and confirmation on mobile and keyboard.
Redacted technical log
Response status, timestamp and test identifier without real personal information.
Decision
Barrier, task impact, fix, owner and retest.
Compare other situations and exercises
PRACTICAL CHECK
Before reaching a conclusion
A frequent misreading and the check that helps avoid it.
Premature conclusion
A form that submits during an internal test may still be unusable by a keyboard user, on mobile or after validation errors.
Decisive check
Test every step under realistic input constraints: required fields, errors, retained values, confirmation, keyboard access and delivery-service state.
AFTER THE REVIEW
Decide from the evidence
An error clears previously entered fields
Treat data loss as a journey failure. Preserve non-sensitive values, focus the error summary and retest correction.
Success appears without verifiable receipt
Do not mark the journey complete. Check the server response and actual processing with fictitious data, then fix the message.
Decision and review trail
Decision and review trail
What the check must help decide and what to retain so the choice can be reviewed.
Sufficient evidence
Test valid input, errors, keyboard, mobile, retained values and confirmation. A successful interface state does not prove mail delivery.
Next decision
Fix the first broken step, then retest end to end with an authorised test recipient. Track accessibility and delivery separately.
Detailed inspection cases
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
A success message does not prove receipt
What to inspect
Distinguish browser submission, server acceptance and receipt in the destination system. Use an authorised test environment and destination to follow each stage.
Decision and action
Describe the result at the level actually observed. If only acceptance is confirmed, do not claim demonstrated delivery; investigate the missing stage and an appropriate recovery mechanism.
Record to retain
Keep non-sensitive test identifiers, times and observed states without copying secrets or unnecessary personal data.
An error erases previously entered answers
What to inspect
Test rejected validation, a network interruption and a return to the form. Check retained fields, associated messages and whether the user can correct and submit without starting over.
Decision and action
Restore an understandable state and retain useful values according to their sensitivity. Do not put form content into a URL to compensate for lost state.
Record to retain
Keep the sequence, affected fields, displayed message and second-attempt outcome using test values.
Rejection erases useful input
What to inspect
Test invalid input and check errors, language and retained fields.
Decision and action
Preserve useful non-sensitive input without triggering real delivery.
Record to retain
Test input, expected rejection, focus and recovery path.
Review before deciding
These questions complement the method. They help establish what is actually supported while retaining qualifications in the record.
Error then recovery
In a test environment, does invalid input explain the problem without losing other useful fields? Also check keyboard, language and recovery after server failure.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- After a test-address error, the form also clears the valid subject and message.
- Declared state
- Observed discrepancy
- Decision and next check
- Preserve useful input and explain the affected field error. Retest recovery with fictional data.
No duplicate submission
Can double activation or a late response produce two operations? Distinguish displayed success, confirmed receipt and final processing without using real personal data.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The browser shows success after two activations; the number of server-side operations was not observed.
- Declared state
- Not checked
- Decision and next check
- Keep uniqueness unverified. In the test environment, link request identifier to receipt and final processing.
Server-side validation
In the test environment, is an invalid request rejected without browser validation? A client-side message does not guarantee server-side handling.
Documentation consulted : MDN · Constraint validation ·
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- An invalid test request is rejected by the server without browser validation; no processing record is created.
- Declared state
- Verified within this scope
- Decision and next check
- Retain fictional input, response and server observation. Repeat when validation or processing changes.
TOOLS / REGISTERS
Information to record
Test success, input error and server failure with identified test data. Check that announced messages match actual outcomes and entered data remains recoverable.
- Access date and time zone
- Exact URL
- Task / journey step
- Device / browser
- Expected result
- Observed result
- Acceptance criterion
- Decision / next action
- Review owner
- Next review
03 / FAQ
Frequently asked questions
Is JavaScript validation enough?
No. It helps immediate feedback, but validation is also required on the server.
Should required fields be identified?
Yes, clearly before input and in error messages.
What after an error?
Explain the fix, connect the message to its field and retain other values where possible.
How to test without sensitive data?
Use fictitious cases and check minimized logs.
How to test without sending real requests?
Providing an appropriate test environment or channel and fictitious data. However, the method should allow to verify the actual stages that condition reception and treatment.
04 / Official references
Official references
Describe a context
DOCUMENTED REFERENCE
Autofill: read tokens in the right order
Two addresses in one form can require different values even when the fields have the same name. autocomplete describes a purpose and a field group; it replaces neither the visible label nor validation. These examples illustrate HTML grammar, not collected identities or contact details.
| Reference | Value or form | What it identifies |
|---|---|---|
| section-* | 1 | The section- prefix comes first. Its value distinguishes a group; the browser must not infer a family relationship or business meaning from it. |
| shipping | billing | 2 | shipping or billing identifies the destination of the details. These two tokens cannot both occur in the same list. |
| home | work | mobile | fax | pager | 3 | home, work, mobile, fax or pager can precede a contact field such as email or tel-national. work postal-code does not follow this grammar. |
| name | postal-code | email | … | 4 | A detailed list needs one purpose token. address-line1 address-line2 does not describe two fields: it supplies two where only one is expected. |
| webauthn | 5 | A final webauthn token can signal public-key credentials with conditional mediation. The attribute alone does not implement authentication. |
| on | off | single token | on and off used alone on an applicable visible field are general modes, not detailed purposes. They are not allowed as such on input type=hidden. |
Read 16 token examples
These examples concern visible fields of the stated type. They isolate the grammar: neither autofill nor authentication is executed.
<input type="text" autocomplete="section-primary shipping work email">
Ordered detail list · Group, destination, contact, purpose: the order in the published ACT example.
| autocomplete attribute | Field type | Reading | Interpretation |
|---|---|---|---|
| section-primary shipping work email | text | Ordered detail list | Group, destination, contact, purpose: the order in the published ACT example. |
| section-blue shipping postal-code | text | Ordered detail list | Two named groups can separate two shipping addresses while keeping the postal-code purpose. |
| section-red shipping postal-code | text | Ordered detail list | Two named groups can separate two shipping addresses while keeping the postal-code purpose. |
| billing postal-code | text | Ordered detail list | A destination and a purpose; a section group is optional. |
| mobile tel-national | tel | Ordered detail list | The contact modifier precedes a telephone purpose. |
| current-password webauthn | password | Ordered detail list | ACT example: password purpose followed by the public-key credential token. |
| given-name | text | Ordered detail list | A purpose alone is enough; prefixes are optional. |
| on | text | General mode | General mode without detailed purpose; ACT rule 73f2c2 excludes this case from its scope. |
| off | text | General mode | General mode without detailed purpose; ACT rule 73f2c2 excludes this case from its scope. |
| work shipping email | Incorrect list | The contact modifier comes before the destination: incorrect order. | |
| work,email | Incorrect list | A comma is not a token separator for this HTML list. | |
| address-line1 address-line2 | text | Incorrect list | Two distinct purposes occupy a position that accepts only one. |
| shipping | text | Incorrect list | The destination alone supplies no purpose. |
| work photo | text | Incorrect list | work cannot modify photo: it is not a contact field. |
| email invalid | Incorrect list | The extra invalid token is not allowed after the list. | |
| current-password webauthn invalid | password | Incorrect list | The extra invalid token is not allowed after the list. |
Implication for the record
Correct token order does not prove that the purpose matches the field, that autofill will occur or that the form meets WCAG 1.3.5. That criterion concerns certain information about the user and depends on the technology used. These examples do not inspect an external form.
Primary documentation
Documentation consulted on .
DEEPER READING / PRACTICE
Testing the forms with realistic cases
A form appears normally but refuses a legitimate entry or confirms a submission that fails. The operation test distinguishes quality of input, validation and final processing.
Updated on .
Priority checks
Test compulsory fields, formats, length, errors, consent and double submission. Use test data and control the actual outcome without transmitting confidential content.
Interpretation pitfalls
An active button or a success message is not enough to show the completion of the processing. The cases of session expiration and unavailability must also remain understandable.
Working record to retain
The operation test sheet retains non-sensitive test data, step, expected result and observed result. Each correction is accompanied by a complete track control.