Testing a community-course registration form
Complete, invalidate, correct, and submit a realistic registration form while examining its form relationships and messages.
- Difficulty:
- beginner
- Estimated time:
- 25 minutes
Objectives
- Evaluate the visible and accessible names, instructions, and groups in a form.
- Trigger and inspect a deterministic invalid-submission state.
- Verify focus handling and programmatic relationships for validation errors.
- Correct the form and evaluate how successful submission is communicated.
Instructions
Use the Testing forms and validation method to review the community-course registration form. Start the exercise from the Exercise workspace.
- Review the form before entering information. Compare visible labels, instructions, and grouped questions with what browser inspection and a screen reader expose.
- Complete the form with a keyboard, but deliberately leave some required information missing.
- Submit and record how the failure is communicated, where focus remains, and how you locate and understand each error.
- Revisit the affected controls with a screen reader and inspect their programmatic relationships.
- Correct every error and submit successfully.
- Record how the confirmation is presented visually and whether assistive technology is informed of the change.
- Identify exactly six accessibility findings. For each one, record the state, affected element, current behavior, expected result, user impact, and remediation direction.
The form runs entirely in your browser and does not send or retain the information you enter.
Exercise workspace
Community course registration form exercise
The exercise opens on a separate page. Return to this page whenever you need a hint, or when you are ready to continue and review the solution.
You can open the exercise in a new tab if you want to keep these instructions and hints available.
Hints
- Compare what is printed beside each control with the name and description exposed in the accessibility tree.
- After invalid submission, note both what appears and where focus remains, then revisit each affected field with a screen reader.
- A message that is visually obvious after submission is not necessarily announced to someone who cannot see the change.
Solution
The form contains six findings involving one label, one instruction, one group, invalid-submission focus, inline error relationships, and successful-submission communication.
The full-name label is not associated with its input
Full name is visibly placed above the input, but its for value does not match the input ID. The field therefore has no accessible name. Match the label and input identifiers or wrap the input with its label.
The email format instruction is not connected to the field
The expected email format is visible, but the email input has no programmatic description that references it. Associate the instruction so it is available with the field name when users encounter the input.
The attendance choices have no programmatic group name
In person and Online each have a label, but their shared question is not associated with the group. Use a fieldset and legend or an equivalently named group so the question is announced with the choices.
Invalid submission leaves focus on the submit button
The error summary appears earlier in the page while focus remains on the submit button, so a non-visual user may not discover the failure efficiently. Apply a deliberate strategy that makes the summary or first invalid field immediately available.
Inline errors are not associated with their fields
The errors are visible near their controls but are not referenced by aria-describedby or aria-errormessage, and invalid state is not exposed. Connect each error to its field and communicate the invalid state.
Successful submission is only communicated visually
The confirmation is inserted visually but does not receive focus and is not exposed through a status or live region. Use an appropriate focus or announcement strategy so assistive-technology users learn that submission succeeded.