Form
This page contains the inaccessible version of the component including the description of issues, additional considerations, and also the more accessible version of the component for comparison.
(future video slot)
Inaccessible Version
Issues
Expand each issue to see the user impact.
Form field labels are missing.
Every form field should be associated with the <label> element. There are exceptions, such as a "search" field that commonly does not have the visible label, however, it has the magnifier icon and programmatically associated accessible name. The label defines the accessible name of the form field, and also allows mouse users to focus the form field by clicking on the label too. The label should be placed close to the connected form field so sighted users understand the connection and users with magnification are able to see both of them. Currently, there are no <label> elements or another methods of providing accessible names and a visual indicators of the purpose of the form fields.
Form fields' border color has an insufficient color contrast.
Users with low vision may not distinguish the border of the form field because its color contrast against the background color is too low.
The form field description has an insufficient color contrast.
Users with low vision may not be able to read the form field description text because its color contrast against the background color is too low.
The form field description relationship with the field itself is missing.
There is no programmatically associated relationship set between the form field and the form field description using aria-describedby so blind users, for instance, might completely miss the description as the screen reader would not even read it. That is because you are inside the form, or when tabbing through form fields, the screen reader is automatically put into the "forms" (or "focus") mode where only interactive elements are reachable. Standard text without any association is ignored.
The explanation of what the asterisk symbol (*) means is missing.
The required fields are marked with the asterisk sign (besides the required attribute in the code) but the explanation needs to be provided as not all users would understand it, even though it is considered to be sort of a standard.
The form submission message is not presented to assistive technologies.
When the form is submitted, the error message or the success message is displayed above the form. However, screen reader users, for instance, might completely miss it as nothing is announced when the form is submitted.
The usage of the number input for the phone number is invalid.
Number inputs should be used for amounts, such as count numbers or a price. The increment/decrement feature is useless for phone numbers, plus when using the telephone inputs, an appropriate keyboard is displayed for mobile users.
The usage of the type attribute on textarea is invalid.
The type attribute is relevant only for <input> elements. There is no support for that attribute there.
The form cannot be submitted by pressing the Enter key.
Currently, the form can only be submitted by the submit button. However, it is also necessary to allow users to submit it by pressing the Enter key. When the submission handler is attached to the form instead of the button, the problem is solved (if the button has the submit type).
The type of the submit button is incorrect.
In order to submit the form by pressing the Enter key (not just by pressing the button), either the button type must be submit or the type attribute omitted.
There is no focus change after the form submission.
If the form is invalid, it is necessary to let users know this information. For example, it is possible to move the user focus to the first invalid field, so they can immediately fix the error.
Invalid inputs are marked only with different border color.
Using the color only is not enough for users to know there is an error in the form. Users with low vision, color blindness, or total blindness would not see the color change at all, and also any users might have trouble figuring out what to do to fix the error. The error description containing the instructions on how to fix the error must be provided and programmatically associated with the relevant form field by the aria-describedby attribute.
The form has a fixed width.
Using fixed width creates a horizontal scrollbar on smaller viewports which could make navigation difficult for some users, especially those using screen magnification.
Considerations
The usage of certain techniques depends on the circumstances. Expand each consideration to learn more.
Consider putting a word "required" to the label.
For instructions to be even more clear, the asterisk symbol can be avoided completely, and instead, the word "required" might be a part of the labels of all required fields. For instance, "Full name (required)".
Consider the validation type.
You can validate the form on any change in the input field, blur, and form submit. All methods have pros and cons, but we recommend the on-submit validation. Why? Some screen reader users first navigate through all the form fields to learn how many are there before they start filling out the form. Users may also accidentally click or tab into/from any form field. It might be obtrusive if errors are displayed immediately when users did not start filling the form.
Consider different focus locations when submitting invalid data.
When the form is submitted and contains errors, the focus can be set also to the error message itself, instead of the first invalid field.
Consider listing all errors in the error message above the form.
For better clarity, maybe in larger forms, all the error messages can be listed together inside the error box to give users an overview of all errors they need to fix so they can submit the form.