"Information and the operation of user interface must be understandable." - WCAG2.1
Readable
"Make text content readable and understandable." - WCAG2.1
Language of Page
The language of the page should be programmatically determinable in order to give users the best experience and enable user agents to present text and other content correctly. With this, both assistive technologies and conventional user agents can present the text more accurately, e.g., screen readers can read the page with correct pronunciation, visual browsers can display characters correctly, etc. As a result, users with disabilities will be better able to understand the content.
The Using the language attribute on the HTML element technique says to specify the language as an attribute on the root html element.
<html lang="fr">
<head>
<title>document écrit en français</title>
<meta charset="utf-8" />
</head>
<body>
...document écrit en français...
</body>
</html>
Predictable
Make Web pages appear and operate in predictable ways. - WCAG2.1
Any change of context should always be an expected action to help people with visual disabilities, cognitive limitations, and motor impairments.
On Focus
Any element that can trigger an event when it receives focus must not change the context to keep the functionality predictable. Examples of context changes on focus:
- form submitted automatically when a component receives focus
- new windows launched when a component receives focus
- the focus is changed to another component when that component receives focus
Focus may be changed using a keyboard or the mouse. An important thing to mention is that hovering over an element does not change the focus (unless scripting implements this behavior).
To satisfy this Success Criterion, do not use the onfocus event or change the context on focus.
On Input
When a user enters data or selects a form control, the effects of such actions should be predictable. Changing a setting on a webpage should not cause a change of context, such as opening a popup window or refreshing content. In addition, users should not be taken away from a webpage when changing something without warning.
Examples:
- Selecting an option from a dropdown should not trigger a form submit.
- A form containing fields representing US phone numbers.[j][k] All numbers have a three-digit area code followed by a three-digit prefix and finally a four-digit number, and each part of the phone number is entered into a separate field. When the user completes one field entry, the focus automatically moves to the next field of the phone number. This behavior of phone fields is described for the user at the beginning of the form.
The simplest solution to satisfy this is to provide a submit button. More info can be found in the following techniques: Providing a submit button to initiate a change of context and Providing submit buttons.
Input Assistance
"Help users avoid and correct mistakes." - WCAG2.1
Error Identification
Make sure users know that an error has occurred and that they can determine what is wrong. For that reason, the message should be as specific as possible. In addition to the text description, it is perfectly acceptable to indicate the error in other ways, such as image, color, etc.
Please note that NIST recommendation for error messages regarding the email/username and password fields should not be specific to each field. For example, "Email does not exist", but rather a general message regarding the combination of two, e.g., "Credentials are incorrect" to prevent leaking additional information to attackers.
In case of an error when submitting a form, re-displaying the form and indicating the fields in error is insufficient for some users. Screen reader users, e.g., will not know there was an error until they encounter one of the indicators. As a result, they may abandon the form before encountering the error indicator.
Per the definition in WCAG 2.0, an "input error" is information provided by the user that is not accepted. This includes:
- information that is required by the web page but omitted by the user, or
- information that is provided by the user but that falls outside the required data format or allowed values.
If fields that require user input were not completed by the user or are provided in an incorrect form, then the error should be shown to the user. This error can be client-side validation or server-side validation. In combination with an error, one more sufficient technique is to use the aria-invalid property on fields.
<div class="control">
<p>
<label for="email">Email address: [*]</label>
<input name="email" id="email" aria-invalid="true" aria-describedby="err_1" required />
</p>
<span id="err_1">Error: Data is missing</span>
</div>
Notice that the
aria-describedbyis used to programmatically connect the field to an error message.
Sometimes, an error might be connected to two or more fields. In such cases, alert dialogs or live regions can be used.
Find more about WCAG sufficient techniques.
WordPress
Eightshift Forms provides validation and useful error messages out of the box.
Labels or Instructions
When a user lands on a page with form controls, content authors should present information and/or labels that identify them. This way, the user knows what input data is expected from them. The idea is not to clutter the page with a ton of information - as too much can be just as harmful as too little.
The goal is to ensure enough information is provided for the user to accomplish the task without undue confusion or navigation.
This can be accomplished by providing a label to a form control.
<div>
<label for="firstname">First name</label>
<input type="text" name="firstname" id="firstname" />
</div>
WordPress
Blocks and components from the Eightshift Development Kit provide attributes for setting labels and aria-labels where applicable. Eightshift Forms provides labels for form fields out of the box.