The task and original case
Audit three form barriers with reproducible evidence and a repair for each. The invented form has an unlabeled date input, a required field indicated only by color and an error message unassociated with its field. Your report should avoid collapsing these different problems into one vague “accessibility issue.”
| Case element | Value or requirement |
|---|---|
| Inputs | Three inputs include an unlabeled date field, a required field indicated only by color and an unassociated error message. |
| Build | An accessibility issue list with reproducible keyboard and assistive-technology steps. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Create an issue record with element, current behavior, affected task, reproduction steps and proposed acceptance condition. For the date control, add a visible label linked to the input. For the required field, add text identifying the requirement and the appropriate control semantics. For the error, associate its message with the relevant field and explain how to correct it.
W3C's forms tutorial covers labels, instructions and user notifications. Inspect the accessible name and description after each repair, then operate the form using a keyboard. The exercise's three supplied barriers are a starting scope; they do not imply that all other states or controls are already accessible.
Sources[1]
Check the worked result
The issue register should contain three distinct entries. A date field has an understandable name; the required state is available beyond color; and an invalid field exposes its specific corrective message. Each entry has a separate acceptance check, allowing a reviewer to see which repairs are complete.
Keep proposed and verified states separate. A suggested label in a document is not an implemented label, and an implemented attribute is not automatically a successful task experience. Record the actual environment and interaction evidence used for verification.
Make the failure visible
Test the form after another invalid submission and verify that the error association still points to the current message. Check the required-field instruction without color and ensure it remains understandable. A placeholder alone can disappear when a user types and may not provide a sufficient persistent label; keep the actual label visible.
Revise it and ask someone to reproduce it
Ask a peer to follow your reproduction steps without additional explanation. Revise any step that relies on an unspecified field or screen state. Then repeat the three acceptance checks after changes and retain before-and-after evidence. Mark any assistive-technology review you did not perform as unverified, rather than inferring it from a screenshot.
- Each barrier has an element, task impact and repeatable steps.
- Proposed repairs are distinguished from verified outcomes.
- Keyboard and accessible-name/error-state evidence match the reviewed environment.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Produced an independent form-accessibility issue register with three distinct barriers, specific repairs and reproducible verification conditions.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.