How to Get Your Site WCAG Compliant - Part 3
- By Joseph Pitman
- Software Quality Assurance & Tech Writer
Recap
In the previous part of this article series, we discussed getting your website WCAG 2.2 compliant with the second section of the standards, Operable. Within that section, we focused on how to make your website more usable, especially by those with disabilities, such as the inability to use a mouse and/or keyboard, or if the user is visually impaired, etc. The focus was on ensuring that your site is both understandable by unique tools designed to help disabled users, and relatively easy to navigate/access so that these users would not face any walls or get stuck while using your site.
If you missed part 2, please do review it before moving on to this article. LINK
In this part 3 of the series, we will be discussing the third section of WCAG 2.2, Understandable. In this section we will discuss the need to ensure your website is not just accessible and easy to use, but also that the content thereon makes sense to all potential users.
Understandable
The World Wide Web is indeed just that, worldwide, and is accessible to people of hundreds of languages in numerous countries. Moreover, millions of potential users face disabilities, including mental or educational limitations that may make your website more difficult to understand. Though your site may cater to only a select number of people, and perhaps even just a single language, in order to reach WCAG compliance you must meet some accessibility requirements when it comes to understandability, meaning allowing for different languages and ensuring the content of your site can be understood by most people.
Language
The easiest way to ensure your site is compliant with WCAG 2.2 in terms of language support is ensuring that all content on your website is identified in its native language, i.e., if your page is written in English, then it is tagged as English. Doing so will allow for page readers and translators to identify what language the content is written in and allow for easier translation. This is especially important for braille readers, as some languages contain unique characters, fonts, and accents- which a braille reader may struggle to translate or even read without knowing the source language.
Example (taken from w3.org):
In this example, a document is identified as being written in French.
<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>document écrit en français</title>
</head>
<body>
... document écrit en français ...
</body>
</html>
This includes any changes in language, such as when one section of a page is in English but another is in Spanish. You could do so using a the “lang=” attribute after a blockquote.
Example (taken from w3.org):
In this example, a quotation is identified as being written in German.
<blockquote lang="de">
<p>
Da dachte der Herr daran, ihn aus dem Futter zu schaffen,
aber der Esel merkte, daß kein guter Wind wehte, lief fort
und machte sich auf den Weg nach Bremen: dort, meinte er,
könnte er ja Stadtmusikant werden.
</p>
</blockquote>
You can find a full list of HTML attribute ISO codes to use with lang= here: LINK
To further assist users, WCAG 2.2 also recommends providing pronunciation explanations after all words or phrases that may be difficult and/or in a different language than the page’s native language.
A final note, although more of a reminder as it was covered in a previous part of this article series (in a different context), is that providing sign language alternatives can be extremely useful for those who are more used to reading sign language than written text. WCAG sees the usage of sign language wherever possible as a major benefit and help, even where written text is available.
Definable
In order to ensure that all content is understandable by anyone, including newcomers without much or any context of your business or industry, WCAG 2.2 requires that all content which uses unique or unusual words or phrases have definitions or explanations. An example would be an industry-only term or phrase, used to describe something that is typically only found within that industry (such as the word lean used to describe a production and manufacturing supply chain process). You could provide within that line of text a definition, or a link to a definition or Wikipedia page (perhaps a link within the word itself).
Alongside allowing the uninitiated to understand the meaning, it also helps those of a different language understand the meaning or context of the content, as the term or phrase could mean something entirely different than expected in a different language, or it might not be translatable at all through technology. Providing a definition or description which is translatable and in its native plain language will make translating and understanding far easier.
This extends also to abbreviations, as while an abbreviation may make sense within your industry/business, it may make absolutely no sense to an outsider or in a different language. For instance, C.o.C for Code of Conduct does not make sense at all in Chinese: 行为守则 Xíngwéi shǒuzé (from Google Translate). The simplest way to meet compliance is to just include, at least once, the full term or statement outside of abbreviation right after or before the abbreviation. Example: Centers for Disease Control and Prevention (CDC).
It is also useful for screen readers and other tools if definitions are tagged as a definition in HTML using the “dfn” attribute.
Example (taken from w3schools.com):
<p><dfn>HTML</dfn> is the standard markup language for creating web pages.</p>
Reading Level
In order to reach WCAG 2.2 compliance, all content on your website is required to be written in language that is understandable at a lower secondary education level, as defined by the United States Government (which is defined by NCES as a 7th to 9th grade education).
Obviously, this could be difficult if your industry/business deals with complicated or advanced topics; in such cases you should include simplified alternatives to the primary content. This could be done through summaries that simply provide an overview, through visual content such as images or videos, through commonly used symbols, or even through interactive content that helps the user understand the intention/purpose.
It is also important to keep in mind the previous section of Definable, as often the most complicated part of any content is unique or unusual words and terminology.
Predictability and Consistency
As discussed in a previous part of this article series, all elements should be focusable via a keyboard key (TAB), especially interactable content. WCAG further elaborates that this should never be removed for any reason, especially aesthetic reasons.
To the point of this section, WCAG requires that all interactable and focusable content does not automatically change, submit, or apply. For instance, a form should have a submit or save button that is required to be used before the content within the form is indeed submitted or saved. It should also be possible to reverse/edit content submitted by the user. This especially includes when a user “tabs” to an element, as they may of simply meant to select it and not engage it.
Users should also be made aware of when their actions will result in a change, such as moving to a different page or section of content. WCAG also recommends that such changes, even in the forms of links, rarely if ever move the user to an entirely different browser tab. The fewer steps a user must perform to both get to content and return to previous content, the better.
You can also further help users predict how to use your website by ensuring consistency throughout the navigable aspects of your site. AKA, the search bar should be identified identically and found at the same location on every relevant page. Also, links should be written as the actual title of the page or content they link to, rather than something less or completely unrelated, and should remain consistent in how they progress (I.e., if a page has a Continue to Page 2 link, then the link on page 2 should progress to Continue to Page 3 and so on).
Your end goal should be to ensure that your website remains predictable and consistent, so that users with unique needs or limitations will be able to accurately and easily navigate and utilize your website without frustration.
Mistake Correction
Mistakes are inevitable in even the best-case scenarios, and much more likely with users who either have disabilities (and may be using unusual or special equipment), and/or don’t fully understand the system they are using. For example, older men and women who didn’t grow up using the internet may struggle and make mistakes as they attempt to use your website. Similarly, someone with ALS using a specially made button activated pointer may on occasion miss the intended target, depending on how the device functions.
When these mistakes happen, it is important and required by WCAG to ensure that the user is properly informed of the mistake and how to fix it or get help (and help should be available).
One example of where this may be necessary is with fillable forms, where a user should be alerted to mistakes or missing information. I.e., if they forgot to put in an email, which may be required in order for the user to receive a response, then an error should occur which prevents them from continuing onward and informs them of the missing email and which box the email should be written in.
Example (taken from w3.org):
The aria-invalid attribute is used on required fields that have no input. A message above the form conveys that form submission has failed due to this.
A portion of the JavaScript code and the HTML form markup follow:
<code>
<script>
...
...
let first = document.getElementById('first');
if (first.value === '') {
first.setAttribute('aria-invalid', 'true');
first.classList.add('failed');
}
let last = document.getElementById('last');
if (last.value === '') {
last.setAttribute('aria-invalid', 'true');
last.classList.add('failed');
}
let email = document.getElementById('first');
if (email.value === '') {
email.setAttribute('aria-invalid', 'true');
email.classList.add('failed');
}
...
...
</script>
<style type="text/css">
label.failed {
border: red thin solid;
}
</style>
<form name="signup" id="signup" method="post" action="#">
<p>
<label for="first">First Name (required)</label><br>
<input type="text" name="first" id="first">
</p>
<p>
<label for="last">Last Name (required)</label><br>
<input type="text" name="last" id="last">
</p>
<p>
<label for="email">Email (required)</label><br>
<input type="text" name="email" id="email">
</p>
<p>
<input type="submit" name="button" id="button" value="Submit">
</p>
</form>
</code>
WCAG also recommends that you provide as much information in the form of instructions to help users understand what they are supposed to do and in what order. You can also provide tags, titles, and descriptions inside the HTML code to provide further context, especially when users are using screen readers or are using a translator tool.
Example (taken from w3.org):
Sample form field using aria-describedby to associate instructions with form fields while there is a form label.
<form>
<label for="fname">First name</label>
<input aria-describedby="int2" autocomplete="given-name" id="fname" type="text">
<p id="int2">Your first name is sometimes called your "given name".</p>
</form>
As mentioned earlier, you should also ensure that all content is reversible and/or editable, as to allow users an opportunity to repair mistakes (including the mistake of performing an action itself, aka submitting a form they didn’t mean to). This is required by WCAG whenever any legal or financial decision/action is involved, as to allow the user to fix mistakes or back out of the decision if it was made as a mistake (as an OR option as to prevent fraud, allowing for multiple methods of confirmation before a purchase/contract is made instead of allowing for a cancel after the fact will also count as compliance, though it is still recommended that users be allowed to cancel requests/orders).
Help and Support
A good way to prevent mistakes from being made or from causing problems is to allow for as much on-demand help as possible. The easiest way to do this is to provide “help links” which will provide further steps and context (preferably without bringing them to entirely new page, aka using a drop-down help bar). You can also provide a page with commonly asked questions, which should be updated regularly as new issues are reported by users.
A preferable help method for many, however, is to provide some form of real time response from real support agents, as issues presented by users may be unique and even time sensitive, requiring someone with access to and understanding of your system/website. This at best could be video or voice calls, and minimally email responses (a good in-between that is popular on many websites is live chat boxes which combine real human support agents and artificial intelligence agents, switching based on complexity and need).
Conclusion
The emphasis with this section has been on ensuring that anyone, regardless of education, physical state, mental state, and/or language has the potential to fully utilize and understand your website and its content. Not only does this help you meet WCAG compliance, but it also broadens the reach of your website, allowing you to find more potential customers or visitors.
In part 4 we will discuss the fourth and final section of WCAG, Robust. Stay tuned via our LinkedIn or this blog itself for that section. For more information, be sure to visit w3.org for all the latest news and recommendations in regards to WCAG.
When that article is posted, a link will be posted here.
You can also follow us on LinkedIn to stay in the loop.