/* MINDFIRE BLOG */

Recap

Previously in this article series about getting your website WCAG compliant, we discussed the third component of WCAG 2.2, Understandable.

In that section, we went through the importance of ensuring your website is not just accessible, but understandable to anyone who may use it, especially those with disabilities, language limitations, and/or linguistic differences.

This meant ensuring that every aspect of your site can be translated and understood, usually by making certain that all unique words, terms, and other aspects of your site have some form of simplistic explanation, whether that means text definitions or explanatory videos that showcase in simple terms how your product works. Most of all, it means ensuring your site meets the first three components of WCAG 2.2, so that translation tools can understand the HTML and code of your site so that it can correctly translate what it sees to the user.

Today’s topic is the final component of WCAG 2.2, which is Robust. In it, we will learn the importance of ensuring all elements on your site are complete and well identified, ensuring your user interface is described and identifiable, and ensuring that messages and/or logs/histories are properly identified.

Remember, if you haven’t read Part 1-3, please be sure to have a look at them before moving on to this article.

Links to previous articles: Part 1, Part 2, Part 3

Robust

In truth, if you have followed the standards set in the first three components of WCAG 2.2 or parts of this article series, then this final section should be a breeze. You can assume you’re already done with it by just ensuring that you followed the standard of identifying, assigning roles, and labeling absolutely everything.

The reason to do so is that some people rely upon special tools or programs that will help them navigate and/or read the content of a site. For instance, someone who is blind will not be able to see the elements or text on your site, and will be relying on a screen reader or some similar tool to read the site’s content for them. By ensuring everything is properly identified behind the scenes within the actual HTML and code, their tools will be able to help the user find and understand the content thereon.

A more specific example is that same person trying to find a specific piece of content on your website. First, they need to find the location of that content through a search bar. You can help them by identifying that search bar as just that, a search bar (Ex: <input type="search" /> ).

You then bring them to a list or provide a dropdown with possible search results. On that results page, you want to make sure each search result is properly labeled according to what it is. (Ex: Nike identifies all their products with an image and provides ALT text with the title of the product. Another site that includes numerous religious topics has an article about Hope, which is identified right in the element: <div data-testid="web-result-title-1" class="sc-1dcwt4x-0 kKYxlX sc-1w24qwn-1 eWmegC">Hope</div> ).

Finally, you help them identify the specific elements on that page. For instance, if that page about Hope has an image at the top showcasing a scene or picture that translates the message of hope, then you could identify the image via ALT= with a short description of what the image shows. In the article itself, you want to separate the different sections according to what they are, such as a header and then its subsidiary paragraphs (and don’t forget to label those headers as headers).

The whole purpose of all of this is to ensure that as much information is provided as possible both at the front end and behind the scenes. Ensuring everything is properly labeled and identified will help improve the experience substantially.

Parsing

Now, to get into the actual content or requirements of Robust, the first point WCAG makes is that all content which has been introduced through markup languages must be fully and correctly written, including proper start and end tags, that pages are well formed and lack errors which may cause issues for screen readers, that no elements contain duplicate attributes, and that XAML IDs/names remain unique where possible.

Beginning and Ending

This section is pretty straightforward, in that you should always double check that you aren’t making mistakes with your element tags. For example, forgetting to include a > bracket in

at the start of a paragraph. Apparently, WCAG has identified this is a common failing, therefore it is wise to double check that you have properly written all start and end tags.

For example, can you identify everything wrong with the following lines of code?

Example with errors:

<h<strong>Paragraph Header</strong><h1>
<p>This is a paragraph
<p>This is another paragraph</p>
<input title="text box"type=text />

Just getting your attributes correct is likely the most important thing you can do to ensure your site is readable, as any mistakes or errors could confuse a screen reader, even if the element somehow appears correct on the front end.

Good Formula

WCAG also specifies that you should, where possible, only use features and functionality as specified within HTML and XHTML, and use said features and functionality correctly. Evidently, using custom or specialized features and functionality that isn’t defined within HTML can result in screen readers or other accessibility tools/programs getting confused or even stuck. Therefore, it is important to use HTML and XHTML according to how they were intended to be used and within the scope of functionality they were designed with.

If you need to develop functionality outside of the official scope of HTML, then you must include in your unique feature or function compatibility with accessibility tools/apps. This may require extensive testing, including of physical hardware and tools, to ensure your site is still accessible by those with disabilities. Due to the expense of such special development and testing, and the likelihood that something will still be missed, it is again recommended that you try to make standard HTML work for whatever you’re doing without going beyond the scope of what it was designed to do.

You will also want to ensure that you are writing your code in the proper order, as somewhat explained in the previous section. HTML has a system that, while sometimes flexible, should always remain written in its correct format. Screen readers and other tools were designed to read web pages according to how their elements are written, and how the attributes of those elements were set up. Getting things in their correct, canon order will help ensure that no mistakes are made by these tools.

Labels Everywhere

To further hammer home how important this part is, here is yet another section in this article series declaring the importance of including labels, roles, titles, and other means of ensuring every element is identifiable.

Not only is it important to include ALT text and similar attributes to allow for explanations of images, videos, and so forth- but it also important to ensure that elements are identified by what they are. For example, a checkbox should be identified as a checkbox (I.e., input type="checkbox").

WCAG further emphasizes the importance that ALL elements be labeled, even when (from your perspective) the front-end appearance seems well defined and obvious. An example they give of where an issue could arise from not labeling every element, is with a phone number input field. Since phone numbers are typically broken into three parts to identify the area code, the 3-digit prefix, and the four-digit suffix; you might include three separate elements to allow for identification of each individual part. In so doing, though each part is in a sequence that implies a connection, it is still important to include a way to identify all three elements for their individual purpose. For example, you could include ALT text or an area-label in each element that identifies which part of the phone number it is (area code, 3-digit prefix, 4-digit suffix, etc.).

Example (taken from w3.org):

<div role="group" aria-labelledby="groupLabel">
  <input type="number" aria-label="country code">
  <input type="number" aria-label="area code">
  <input type="number" aria-label="subscriber number">
</div>

Example (taken from w3.org):

On a page, a link displays a pop-up box (a div) with additional information. The 'close' element is implemented as a button containing merely the letter 'x'. The property aria-label="close" is used to provide an accessible name to the button.

<div id="box">
   This is a pop-up box.
   <button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>                
</div>

Updates and Notifications

Something that can be commonly overlooked is the importance of including roles and labels within temporary or unique elements meant to relay updates or changes, such as a notification explaining the number of search results available after a user uses a search bar/tool. The most common way to identify such elements is to use the status role (role=”status”) followed by the update/notification’s text. Doing so will allow for assistive technology such as screen readers to be able to identify the purpose of the element and inform the user of its presence in a sensible way.

You can also include special roles that will help users avoid mistakes via more urgent messages, such as a warning indicating that changes cannot be undone. You can do so using either the role of alert (role=”alert”) or you can use the aria attribute of assertive (aria-live=”assertive”). Using these attributes will increase the urgency of the message in the eyes of the screen reader or other assistive technologies.

Example (partially taken from w3.org):

The following example uses role=alert which is equivalent to using aria-live=assertive.

In the example there is an empty error message container element with aria-atomic=true and an aria-live property or alert role present in the DOM on page load. The error container must be present in the DOM on page load for the error message to be spoken by most screen readers. aria-atomic=true is necessary to make Voiceover on iOS read the error messages after more than one invalid submission.

JavaScript is used to test if the inputs are empty on submit and inject error messages into the live region containers if so. Each time a new submit is attempted the previous error messages are removed from the container and new error messages injected.

<script>
function validateForm() {
    let errors = '';

    if (document.getElementById('first').value === '')
        errors += '<p>Please enter your first name.</p>';
​
    if (document.getElementById('last').value === '')
        errors += '<p>Please enter your last name.</p>';
​
    if (document.getElementById('email').value === '')
        errors += '<p>Please enter your email address.</p>';

    document.getElementById('errors').innerHtml = errors;

    return errors === '';
}
</script>
​
<form name="signup" method="post" onsubmit="validateForm();">
    <p id="errors" role="alert" aria-atomic="true"></p>
    <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" value="Submit">
    </p>
</form>

Do note, however, that it is actually in violation of WCAG 2.2 to use the roles of alert and assertive in non-important circumstances. The role of status or similar should be used as much as possible, and these more urgent roles should be reserved for time-sensitive or critical/irreversible circumstances.

Conclusion

With the end of this section comes the end to this article series, meaning that if you have followed the general guidelines explained in all four parts of this article series, then you should now be WCAG 2.2 compliant- congratulations!

Getting WCAG compliant is no small thing, and requires a lot of effort and focus, especially if you are making an existing site compliant. However, it can only serve as a benefit to you and your website, as it will ensure not only that you are within the legal boundaries set by the government, but it will also help bolster your site’s reputation and usability. As stated in part 1, Google and other search engines (via search engine optimization, SEO) will often recommend WCAG compliant sites above other sites which have failed to remain or become compliant. Moreover, ensuring your site is compliant will also allow for more potential customers or users, as now those with disabilities or other challenges that may make traditional usage of computers and web browsers more difficult can now access and use your website without any additional hassle or frustration.

If you are still unsure if you have managed to make your site compliant, you can review the w3.org quick reference guide step by step, which is the same guide we used to create this article series. You can also use the special tool called ANDI which is designed to review your website from within your browser, and identify any weaknesses such as missing attributes.

You can check out ANDI at this link: LINK

Summary

To summarize the entirety of compliance with WCAG 2.2, we’ll simply emphasize the following points:

1. Include ALT text wherever possible.
2. Assign roles wherever possible.
3. Consider how your site may be used by someone who is blind.
4. Consider how your site may be used by someone who is epileptic and/or dyslexic.
5. Consider how your site may be used by someone who speaks a different language than what your site was written in.
6. Consider how someone with no context of your business or industry may come to understand terms, abbreviations, and concepts.
7. Consider how some users may have to use your site in a slower more time restrained manner.
8. Consider how some users may be affected by sound and sudden pop-ups.
9. Consider how some users may not be able to use a mouse or a keyboard, or is reserved to just one or the other. Moreover, consider how some users may require special tools altogether in order to interact with your website.
10. Consider how you can accommodate or assist users with little or no experience using computers.
11. Always ensure that there is some form of help or assistance for users (especially live communication, considering that a Frequently Asked Questions section doesn’t necessarily cover every issue).
12. Consider how someone who has never visited your site before might be able to find exactly what they want or need within three or fewer clicks of a mouse.
13. Finally, consider whether your site is truly Perceivable, Operable, Understandable, and Robust.

Now, we can finally take a deep breath, as all of that is certainly quite a bit to keep in mind at all times while designing a website- even more so if you are having to go back and update a website to reflect every single point of failure which WCAG will take into account.

Luckily for you, Mindfire Tech is here if you require any kind of help or services in getting your website up to spec with the latest accessibility standards. Mindfire is made up of a team of experts with decades of experience in software and website development, and we are ready to tackle any project put before us, including creating websites from scratch or updating websites to become compliant with WCAG. Whatever your tech need is, we are here to help.

If you’re interested, you can reach out to us from our contact-us page: CONTACT-US LINK

You can also follow us on LinkedIn to stay in the loop.