Accessibility and Inclusive Content
Form Instruction Accessibility Check
Review labels, requirements, examples, input formats, help, errors, recovery, timing, privacy context, confirmation, and completion instructions in forms.
Free editable Markdown · Content designers, accessibility testers, and form owners ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Form context
- Form and version
- [URL/build]
- User task
- [What submission accomplishes]
- Audience and access needs
- [Relevant range]
- Sensitive fields
- [Personal, financial, health, other]
- Required/optional convention
- [How communicated]
- Time limit and save behavior
- [Details]
- Final consequence
- [Account, payment, request, publication, other]
- Test environment
- [Browser, device, assistive technology]
Field or state record
- Field/group
- [Name]
- Visible label and accessible name
- [Exact]
- Requirement and format
- [Rule]
- Example or help
- [Exact]
- Current error
- [Exact message]
- Recovery instruction
- [How to fix]
- Focus/announcement
- [Observed result]
- Value preserved
- [Yes/no]
- Privacy context
- [Why requested and link]
- Revision/owner
- [Content or implementation action]
Completion checks
- Labels persist and are programmatically associated.
- Required status and formats appear before submission.
- Errors identify problem and recovery without color alone.
- Valid entries and focus are preserved.
- Timeout and server states explain submission status.
- Final action names the real consequence.
- Confirmation provides status and next step.
- Keyboard, zoom, assistive technology, and mobile states are tested.
How to use this template
- Inventory form purpose, audience, fields, requirements, sensitive data, time limits, and final consequence.
- Review labels, groups, examples, formats, help, and required-state communication before input.
- trigger every validation, server, permission, and timeout error and inspect recovery.
- Test keyboard order, focus, announcements, zoom, mobile layout, review, submission, and confirmation.
- Resolve content and implementation defects, then verify the complete live journey with safe data.
Explain before input
Give every field a persistent, programmatically associated label. State required status, expected format, units, and important constraints before submission, with a realistic example when it clarifies rather than restricts. Placeholder text should not replace a label because it disappears and can be mistaken for a value. Group related choices with a meaningful legend and explain why sensitive information is requested near the field or through a findable privacy route.
Make errors specific and recoverable
Identify the field, what went wrong, and how to fix it without blame. Preserve valid entries and focus so users do not repeat work. An error summary should link to affected fields when appropriate, while inline messages provide specific repair. Do not rely on red color, icons, or vague “invalid” text alone. For server or network failure, distinguish a temporary service problem from invalid user input and state whether submission occurred.
Clarify commitment and completion
Before the final action, summarize consequential choices, cost, consent, or data submission and use a button label that describes the action. Explain timeouts in advance, allow extension where possible, and save progress responsibly. After submission, state whether the action succeeded, provide a reference or next step, and avoid leaving users unsure whether to submit again. Check email or document follow-up because it is part of the form journey.
See the fields in context
Fictional example: community room request
HallKey is an invented booking form and all fields are illustrative.
- Current error: “Invalid date,” announced only after a full-page reload.
- Revision: “Choose a date at least three fictional working days from today,” associated with the field and linked from the summary.
- Preservation: Other entered values remain, and focus moves to the error summary before returning to the date.
- Consequence: Button changes from “Send” to “Submit room request,” followed by a confirmation that no booking exists until approval.
- Privacy: The contact-number field explains its scheduling purpose and links to the invented privacy notice.
Frequently asked questions
Can placeholder text serve as a field label?
No. It disappears during entry and may not provide a reliable accessible name. Use a persistent associated label.
Should errors appear only after submission?
Use timing appropriate to the field without interrupting input. Always provide a clear full-form recovery path at submission.
How should optional fields be marked?
Use a consistent convention that makes required and optional status clear before entry, following your design system and applicable guidance.
Is a success banner enough confirmation?
It should explicitly state what succeeded, what happens next, and how to reference or correct the submission where relevant.