Understandable

In cases where the content of a page includes words or phrases that are in a different language to the primary language, use the lang attribute on an element wrapped around the term in question (e.g. a <span> if no semantic element is available) to set an appropriate language for it.

You don't need to set a different language for words or phrases that are the same regardless of language (for example proper names, technical terms that aren't part of a specific language).

Where abbreviations are used, you should provide an expansion of them, or a definition as required.

The <abbr> element is often thought of as the preferred way to provide an expansion for an abbreviation — it takes a title attribute that contains the expansion, and this appears when the acronym is moused over. However, the title contents are not accessible via keyboard, nor are they reliably read out by screen readers. A better way to handle this is to again provide links to glossary pages containing the acronym expansion and explanation, or at the very least include them in the surrounding text in context.

If text is provided that requires a higher reading level that lower secondary education level (typically children around 11-14 years old), provide supplementary explainer material to help people who can't read it, or provide an alternative version that is written at lower secondary level.

This doesn't mean that all subject matter should be understood by everyone, but that the style of writing should be accessible by everyone. It is better to just write all content at lower secondary level, even technical documentation like programming tutorials, unless there is a good reason not to (e.g. an alternative style for poetic effect), or they have to be written in a strict style (e.g. W3C specs).

A mechanism should be provided to give users access to pronunciation of words where they are is needed to understand the content fully.

The HTML <audio> element can be used to create a control that allows the reader to play back an audio file containing the correct pronunciation, and it also makes sense to include a textual pronunciation guide after difficult words, in the same way that you find in dictionary entries.

When a control or other page feature receives focus, it should not change the context in a way that may confuse or disorientate the user.

This is a matter of sensible design — people don't want interfaces to surprise them; they want things to be intuitive and behave as expected. For example, focusing a navigation menu option should not change the displayed page — it should be activated before the display changes.

When data is inputted into a control, or a setting is changed, context should not be changed unexpectedly. The user should be warned/advised of the impending change before it occurs.

Again, sensible design should be implemented. For example, if pressing a button causes the application to exit the current view, the user should be asked to confirm this action, save their work if appropriate, etc.

Navigation menu/control style and positioning should be consistent between different pages or views of a web page, and the existing items should appear in the same order, even if for example new items are added. If the user has initiated a change, e.g. choosing a different color scheme or position for the navigation, their choice should be respected across all pages.

Again, sensible design — make the navigation controls the same across all pages or views.

Controls or components that have the same functionality should be identified in the same way across different pages or views. A currency converter appearing on every page of a world travel site for example should be exactly the same, semantically and in terms of labels.

Again, sensible design!

Changes in context that could possibly confuse or disorient users should only occur only when requested by the user, OR the user should be able to turn them off.

If you need to have something that significantly changes the current view (e.g. content or controls), let the user control when they want that change to occur (e.g. what page to show, when to advance to the next photo in the gallery...)

If you need to have something like a carousel on a page, provide an option to stop it automatically advancing. Better to avoid such functionality if possible.

Web pages that contain help mechanisms, including self-help options and human contact details, that are repeated on multiple web pages, need to place those mechanisms in the same order on all pages, unless a change is initiated by the user.

Check out the consistent help documentation for this standard to learn more.

When a user is filling out a form or choosing between options, any error that is detected should be clearly reported to the user, along with the form control that the error relates to.

It is advisable to implement client-side error detection and handling, via HTML form validation features, and/or JavaScript, whatever is best for your situation. When an error is detected, an intuitive error message should be shown next to the form input that is at fault to help the user correct their inputs. For screen reader users, you can use aria live regions to alert the user to a change on the page.

Clear instructions should be provided when data input is required. When a simple instruction or prompt is required, you can use <label> elements for single inputs like name or age, a combination or <label>s and <fieldset>s/<legend>s for multiple inputs that go together (like the elements of a date of birth or postal address).

When more complex explanation is required, you can always include explanatory paragraphs too, or maybe you need to try to make your forms more intuitive.

• Meaningful text labels
• How to structure an HTML form
• Text labels and names

When an error is detected and suggestions for correction are known, provide these to the user (e.g. suggesting alternatives when the user is choosing a user name and has selected one that is already taken), unless doing so would cause a security issue (e.g. when entering a password) or context problem (e.g. they are trying to answer a question in a quiz app).

In such cases, when this is appropriate, you'll probably use a combination of JavaScript and server-side functionality to check if the entry is correct, and if not, what viable suggestions can be given to the user. Such suggestions should be displayed usefully in context, just like error messages (see 3.3.1).

In the case of forms involved with entry of sensitive data (such as legal agreements, e-commerce transactions, or personal data), at least one of the following should be true:

• Submissions are reversible.
• Data is checked for errors, and the user is given an opportunity to correct them.
• A mechanism is available for confirming and correcting information before final submission.

Reversible — for any view where data can be entered, provide an equivalent view that allows you to edit or even delete an entry, as appropriate (for example, see Django web framework).

Checking data — as covered in 3.3.1, a combination of client-side and server-side validation should be used to detect errors and display helpful messages to the user to allow them to correct their inputs.

Confirm and correct — where appropriate, after filling in a series of form fields to perform a task (such as buying a product), the user should be shown a confirmation screen where they can review their inputs and correct anything that doesn't look right. This pattern is commonly used on e-commerce sites like Amazon.