The third principle of the Web Accessibility Guidelines is Understandable. Information and operation of the user interface must be understandable. Aim for clear and predictable website operation and provide instructions for complex tasks. Use plain language and avoid jargon or technical terminology. Present content clearly and understandably.
I won't go through every single criterion on this site. If you are curious about the more detailed contents of WCAG, hop over to my WCAG site!
This guideline focuses on the readability and understandability of the content. It is surprising how many criteria fall under AAA-level compliance. I recommend you pay attention to all of these criteria regardless of the level you are aiming for.
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.
This is usually done by adding a lang attribute to an element that contains the text in another language. This should be added to language menus and any content that might be on the page in a different language. This helps screen readers to offer the content in the right language.
A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.
In essence, explain all unusual words you use. If there is an easier word to use, prefer those over the more unusual ones.
A mechanism for identifying the expanded form or meaning of abbreviations is available.
There are several ways you can take care of this. One I often go for is to explain the abbreviation after using it. The best way to handle this is by having that explanation close to the content so the user doesn't have to go to another page or site just to understand the content.
When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.
There are ways to check the reading level of your content. One tool I like to use is the Hemingway Editor. It will tell you the reading level of your content as well as show if sentences are hard to very hard to read. Usually, it is better to use plain language to ensure your primary content meets the reading level recommendations.
A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation.
You can provide the pronunciation immediately following the word. Or you can provide a glossary or link to pronunciations. These are all sufficient techniques to comply with this criterion.
This guideline is all about making sure users don't get confused by inconsistent site structure and functionality.
This guideline focuses on helping users avoid and correct mistakes.
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
The best practice is to include a message or alert, as some users may not be aware that an error has occurred and could assume that the form is not functioning correctly. It is also best practice to include an error notification in the page title (title element) since a screen reader user is likely to believe the page was submitted correctly and continue to navigate to another page as soon as the new page is returned instead of reading the main content area of the page again.
For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
In practice:
On a simple, 1-page form this is easy because the user can review the form before submitting it. On a form that spans multiple Web pages, however, data is collected from the user in multiple steps before the transaction is committed. The user may not recall all of the data that was entered in previous steps before the step which commits the transaction.
One approach is to cache the results of each individual step and allow the user to navigate back and forth at will to review all data entered. Another approach is to provide a summary of all data collected in all steps for the user to review prior to the final commitment of the transaction.
Before the final step that commits the transaction to occur, instructions are provided to prompt the user to review the data entered and confirm. Once the user confirms, the transaction is completed.
For Web pages that require the user to submit information, at least one of the following is true:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
This is pretty much the same as 3.3.4 except with AAA level error prevention is required from all forms. I recommend handling this always as this is one of the easier AAA conformance criteria to achieve.