WCAG 2.0 - Understandable
3.1.1 Language of Page
How to test?
For pages that are mainly English, check that the <html> element identifies the page’s language as using the LANG attribute, as in <html lang="en-NZ"...>. For XHTML pages, you should find matching LANG and XML:LANG attributes: <html lang="en-NZ" xml:lang="en-NZ"...>.
For pages that are mainly in Maori, the language should similarly be indicated, but with the "mi" language code.
3.1.2 Language of Parts
If a page includes a section of content in a language other than the page’s main language, this section should be enclosed in an element that specifies its language, e.g., <h2 lang="mi">Te Tari Taiwhenua</h2> for content in te reo Maori on an English page. Again, in XHTML pages, the language must be specified using both LANG and XML:LANG attributes, e.g., <h2 lang="mi" xml:lang="mi">Te Tari Taiwhenua</h2>.
How to test?
View the HTML source of the page in question and ensure that the appropriate LANG attribute and value is used on an element wrapping or containing the text and only the text that is in a language different from that of the page as a whole.
3.2.1 On Focus
In essence, don’t trigger any change of context when a page element receives focus. Changes in context include changes of focus, of viewport, and of the page the user is on. An example would be when setting focus to a form field and a popup window automatically opens with focus being moved to the pop-up. This would make it impossible for a keyboard user to ever tab past that field.
Note that loading a new window, e.g., a pop-up that advertises certain content, as soon as a page loads is a failure of this requirement (see F52: Failure of Success Criterion 3.2.1 and 3.2.5 due to opening a new window as soon as a new page is loaded.)
How to test?
Using the Tab key, move focus to each of the focussable elements on the page, and note the behaviour. If there is a change of context upon moving focus to an element, this constitutes a failure of WCAG 3.2.1.
3.2.2 On Input
This requirement is similar to 3.2.1 On Focus, but applies when input is entered into a form element and there is an unrequested change of context. Don’t send users off to a new page based on a value that they enter into a form field, without the user expressly clicking a submit button to initiate the change of context.
Note that not all changes of content are changes of context. Consider the kind of event where a user moves focus to a radio button, thereby populating the page with further options, e.g., a user checks a radio button labelled “Auckland” which causes a drop-down list of Auckland suburbs to appear immediately below. This is NOT considered a change of context and is acceptable.
In essence, they above two criteria suggest that a site shouldn’t direct a user to a new page until an explicit submit button is activated.
How to test?
For every form input, enter content or change its value, and note the behaviour. If there is an unrequested change of context, this constitutes a failure of WCAG 3.2.2.
3.2.3 Consistent Navigation
How to test?
Ensure navigation is consistent (and labelled consistently) across the site. For example, do not change the order of main navigational elements across different pages or sections of a site.
3.2.4 Consistent Identification
How to test?
Ensure that functional components used in different parts of the site are consistently labelled. For example, with a search submit button, don’t use the the word “Search” in some parts of the site and “Find” in others.
3.3.1 Error Identification
Where an error has occurred when submitting a form, a textual error message describing the specific error is provided. It is not enough merely to indicate what form fields were in error.
How to test?
Enter incorrect information into the form (i.e., try to cause errors), submit it, and note the error message(s), if any. Check that error messages are provided and that they adequately describe each error.
3.3.2 Labels or Instructions
Form fields should be accompanied by labels and instructions that make it clear to the user as to what is expected in each field.
The labels or instructions should be visually located close to the input field (for users of screen magnification technologies who may be looking at a very small field of view). Where form fields that need specific values in particular formats (e.g., date fields), clear instructions should be included, preferably as part of the relevant <label> element.
How to test?
For each form control, ensure that it is accompanied by a clear and descriptive label or instruction.
3.3.3 Error Suggestion
The site must provide suggestions on how to correct form input errors. If, for example, a user is required to enter a day of the month, an entry of ‘32’ could be met with an error message stating that allowable values are between 1 and 31. The W3C provides the following example:
An input field requires that a month name be entered. If the user enters "12," suggestions for correction may include
- A list of the acceptable values, e.g., "Choose one of: January, February, March, April, May, June, July, August, September, October, November, December."
- A description of the set of values, e.g., "Please provide the name of the month."
The conversion of the input data interpreted as a different month format, e.g., "Do you mean 'December'?"
How to test?
Enter incorrect information into the form (i.e., try to cause errors), submit it, and note the error message(s), if any. Check that the error message(s) provide suggestions on how to correct the errors.
3.3.4 Error Prevention (Legal, Financial, Data)
This refers to forms that lead to financial or legal commitments or involve storage of user-managed data. If your site has forms of this nature, read Understanding 3.3.4.
How to test?
Review any relevant forms on the page and check that users are given the opportunity to review their information prior to submitting, to correct any input errors identified upon submission, or to reverse the submission if necessary.
- Last modified: