Forms
Introduction
In order for users to know how to fill out a form, the form has to be accessible. Key concepts include:
- Labels for form inputs
- Labels for groups of inputs
- Instructions and hints, where necessary
- Error prevention
- Form validation
With all of these, information must be visible on the screen, accurate and meaningful, programmatically discernible, and programmatically associated with the appropriate form element or group.
The more interactive a form element or process is, the more attention needs to be given to accessibility with respect to:
- Focus management
- Setting and updating ARIA names, roles, and values, where necessary
- ARIA live announcements, where necessary
Perhaps most importantly, all form elements need labels associated to them to be accessible. Where a label is not associated, the screen reader user is not informed of the field’s purpose upon focusing that field.
WCAG criteria
- 3.3.2 Labels or Instructions (level A)
- 3.3.3 Error Suggestion (level AA)
Scope of the issue
As mentioned in Page structure, C3 uses a layout table throughout the application, rather than semantic markup. This means that labels are missing throughout all the child forms and <span>
elements are used in their place.
Fixing the issue
It is recommended that the child forms be reworked to use semantic structure including labels, fieldsets, and legends. An accessible version of the Alerts Lookup form (under “Edit an Alert” in Alerts) might be rewritten as follows:
<form>
<fieldset>
<legend>Alerts Lookup Selection Criteria</legend>
<label for="trustnum">Trust #: </label>
<input type="text" id="trustnum" aria-invalid="true">
<label for="typecode">Type Code:</label>
<select id="typecode">
<label for="resp">Responsible:</label>
<select id="resp">
<label for="freq">Frequency:</label>
<select id="freq">
<label for="fdt">Starting date between:</label>
<input type="text" id="fdt">
<label for="tdt">and</label>
<input type="text" id="tdt">
</fieldset>
<button type="submit">Submit</button>
</form>