Mindfire Technology

How to Get Your Site WCAG Compliant - Part 4

Wed, 27 Sep 2023 09:00:00 -0600

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:

Include ALT text wherever possible.
Assign roles wherever possible.
Consider how your site may be used by someone who is blind.
Consider how your site may be used by someone who is epileptic and/or dyslexic.
Consider how your site may be used by someone who speaks a different language than what your site was written in.
Consider how someone with no context of your business or industry may come to understand terms, abbreviations, and concepts.
Consider how some users may have to use your site in a slower more time restrained manner.
Consider how some users may be affected by sound and sudden pop-ups.
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.
Consider how you can accommodate or assist users with little or no experience using computers.
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).
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.
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.

How to Get Your Site WCAG Compliant - Part 3

Wed, 20 Sep 2023 09:00:00 -0600

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.

How to Get Your Site WCAG Compliant - Part 2

Wed, 13 Sep 2023 09:00:00 -0600

Recap

In the last part of this article series, we discussed getting your website WCAG 2.2 compliant with the first section of the standards, Perceivable. Within that section, the primary focusses were on content and structure of a website, ensuring that users with disabilities would have access to alternative means of identifying elements and aspects of your website with ease.

If you missed part 1, please do review it before moving on to this article: LINK

In this part 2 of the series, we will be discussing the second section of WCAG 2.2, Operable. This section switches focus to the actual functionality of the website, ensuring that users with disabilities will find the site both navigable and functional for their unique use cases.

Operable

It is important to recognize that users with disabilities may lack the ability to access websites in the same way others do. Imagine, for instance, the renowned physicist Stephen Hawking who was confined to an electric wheelchair due to the condition known as ALS, which caused most of his body to be incapable of moving. His ability to interact with the world around him was greatly limited because of his disease- but thanks to the electronic tools provided to him, he was able to speak to others, move on his own, and interact with computers. Much of this was done through the use of custom external devices such as a small keyboard and display, which allowed him to both use text-to-speech to communicate and to interact with computers and other electronic devices.

Now, imagine if Stephen Hawking or someone in a similar position needed to access your website, but your site was built in such a way that it required the use of a mouse cursor, or had certain elements that had a time-mechanism/timeout, meaning that if a user was a bit too slow to react then they might miss the provided information. These aspects would negatively, if not outright, prevent users with similar disabilities from using your website in a fair and normal manner. Just imagine requiring someone who is completely blind to navigate using a mouse cursor in order to properly use your website, a tool which requires you to see where it is on the display. This extends beyond users with physical/neurological disorders, even to those with mental limitations and so forth.

Many individuals simply need time and tools to adequately use websites, and it is part of WCAG 2.2 compliance to give them the time and resources they need. In this article, we will be discussing ways you or your engineers can make your website more operable and safer for all users.

Keyboard Accessible

As explained with the Stephen Hawking example, many users rely on keyboards or similar tools to access the world around them, or at least, to access computers and the internet. While there are some tools that allow mouse cursors to be used by keyboards or other tools such as joysticks, it is best to simply ensure that your entire website is, minimally, accessible, and usable by a keyboard, as many accessibility tools are based on keyboard functionality. Ensuring this is the case, especially with simple and standardized keys such as arrow keys or function keys, will also allow for unique tools such as specialized keyboards and/or joysticks to have more seamless integration with your site.

The first and most important tactic for compliance is making sure that all interactable objects can be navigated to using a simple key such as TAB. Typically, most websites and applications already allow the use of TAB to move in a sequential manner across their interface, allowing users to reach any section or aspect of a website with just the press of that single button. You can achieve this on your site by ensuring that all interactable images and elements on your website are properly formatted, and as an additional level of insurance you can add the “tabindex=” attribute.

Example (taken from stackoverflow.com):

<div tabindex="1">First</div>
<div tabindex="2">Second</div>

It is easy enough to test if you succeeded by simply ensuring that if you press TAB, you can go through your whole website by moving from one interactable element to the next, and that pressing ENTER allows the users to engage the element.

Form Controls

A bit of a rehash from Perceivable, yet important to elaborate, is the necessity for roles, tags, and other identifiers for all elements on your site. One such method of identifying content is through form controls. w3.org identifies a short list of important HTML elements and roles to keep in mind.

Link: <a>
Push Button: <button>
Grouping: <fieldset>
Push Button: <input type = “button”, “submit”, or “reset”>
Push Button: <input type = “image”>
Editable Text: <input type = “text”>
Editable Text: <input type = “password”>
Editable Text: <input type = “file”>
Checkbox: <input type = “checkbox”>
Radio: <input type = “radio”>
List Box: <select>
Editable Text: <textarea>

Example (taken from w3.org):

In example 1a, the name is the text inside the link, in this case "Example Site".

<a href="www.example.com">Example Site</a>

Example (taken from w3.org):

This example has a role of "radio button" from the 'type' attribute on the input element. Its name comes from the label element. The state can be "checked" or "unchecked" and comes from the 'checked' attribute. The state can be changed by the user.

<input type="radio" name="color" id="r1" checked="checked"/><label for="r1">Red</label>
<input type="radio" name="color" id="r2" /><label for="r2">Blue</label>
<input type="radio" name="color" id="r3" /><label for="r3">Green</label>

Dead-end Traps

The next important part of WCAG when it comes to keyboards is preventing users from getting trapped when a keyboard is their only interface. This tends to be situations where users need to use a mouse cursor or some other non-keyboard method to exit out or move back out of a section of your website. This is also a common issue with browser plugins which may not provide a way to close or exit the plugin accessible via the keyboard.

Two examples of plugins that provide methods to escape are ANDI, which is a tool for determining if your site meets WCAG compliance, and Honey, a shopping tool.

For ANDI, its method of allowing you to easily exit the plugin without a mouse cursor is through an X or exit button that can be easily reached by the use of TAB, with ENTER allowing the user to close the plugin via that button.

For Honey, while they don’t provide an exit button, they do allow for the ESC key to immediately close the plugin, regardless of where you are in it. ESC is a common method of closing plugins with most browsers. Ensuring your plugin has the ESC functionality, or at least an exit/close button will accomplish WCAG’s requirement.

Shortcuts

The final keyboard related aspect of this section that we’ll discuss is that of shortcuts and how to properly use them on your site.

Now, keyboard related shortcuts to access aspects of your website or to engage elements may at first seem like something that would add accessibility. However, it is crucial to keep in mind that someone who relies on their keyboard to behave in a predictable manner may become frustrated with shortcuts that prevent normal use of their tools: AKA, causing keys such as the normal lettered keys (QWERTY A-Z) to behave as shortcuts.

For example, imagine you change the letter A to cause the website to open/display a certain element or image. If the user who is limited to just a keyboard needs to use the letter A for something else with their computer, now they are stuck.

To solve this, WCAG requires that developers ensure that their site has one of two potential bypass methods: 1. A way to turn off single-key shortcuts or 2. Provide a mechanism to remap shortcuts, especially to two-step shortcuts (I.e., including ALT or CTRL in the shortcut, but not any additional letters, punctuation characters, numbers, or symbol characters).

Time

Another crucial aspect of a website’s accessibility is whether or not users will have an equal chance at accessing aspects of it in a timely manner. What this means is whether someone who cannot interact with a website as quickly as someone else due to physical or mental limitations can still reach the same information or accomplish the same purpose as those without the same limitations.

For example, you may have a session timeout in place for security or performance purposes. However, your set timeout may not be long enough for some users and could cause them frustration or even loss of work by signing them out of the website prematurely. Take the example of someone who needs to use a pointer or tool which can only press one key every five seconds.

To solve this, WCAG recommends you provide tools to help users customize that aspect of your site, such as including the ability to prevent a timeout (Remember Me options, etc.). This extends to any type of timed tool, event, or element of your site, as allowing the user to turn off or customize how much time is available to them will completely solve this issue.

There are some exceptions to this rule, however, such as where timing is the whole point of the website. Examples of this are auctions, where a time limit is in place for users to bid. WCAG also allows you to ignore any timeouts that extend beyond 20 hours.

Where shorter timeouts are required and cannot be customized, you can also offer users the ability to extend the time limit, by providing them a warning 20 seconds in advance of the timeout and then provide (and explain) a simple method to extend the time such as pressing a shortcut like the spacebar (WCAG requires that extension be at least 10 times the original timeout length).

It is also important to let users know that exiting or if a timeout occurs, any information or work they have completed with your website/tool will be deleted. The only exception is if the information or work is saved to the site for a period of at least 20 hours.

Pausing Movement

If your site is designed or requires some form of moving or changing content, such as flashing symbols, videos, scrolling text, etc., it is important to provide users with the option to pause that element.

Ever been frustrated when the teacher was explaining things too quickly? Or moving through the power point slides faster than you could take notes? Keep in mind that for that teacher, things are moving at a rate they are comfortable with, perhaps even slower than they want it to be going. Now, consider content on your website that you have designed to automatically move or scroll, and note that for you it may be doing so at an acceptable rate, but may not be so for others. This could include auto-playing videos or animations.

To solve this, simply add a tool or method to pause or stop movement or scrolling of any content or elements on your page. This will allow users to access and understand the information being provided at a rate which is comfortable for them. If you want to be more accessible, add not only a way to pause the information but also a way to adjust the speed at which it moves or scrolls.

Example (taken from w3.org):

In this example CSS and JavaScript are used to visually present some text in a scrolling format. A link is included to pause the scrolling movement.

This implementation will display the full text and omit the link when Javascript or CSS are unsupported or inactive.

The following code is an amended version of webSemantic's Accessible Scroller (as at July 2008).

The XHTML component:

<div id="scroller">
<p id="tag">This text will scroll and a Pause/Scroll link will be present 
when Javascript and CSS are supported and active.</p>
</div>

The CSS component:

body {font:1em verdana,sans-serif; color:#000; margin:0}

/* position:relative and overflow:hidden are required */
#scroller { position:relative; overflow:hidden; width:15em; border:1px solid #008080; }

/* add formatting for the scrolling text */
#tag { margin:2px 0; }

/* #testP must also contain all text-sizing properties of #tag  */
#testP { visibility:hidden; position:absolute; white-space:nowrap; } 

/* used as a page top marker and to limit width */
#top { width:350px; margin:auto; }

The JavaScript component:

var speed=50        // speed of scroller
var step=3          // smoothness of movement
var StartActionText= "Scroll"  // Text for start link
var StopActionText = "Pause"   // Text for stop link

var x, scroll, divW, sText=""

function onclickIE(idAttr,handler,call){
  if ((document.all)&&(document.getElementById)){idAttr[handler]="Javascript:"+call}
}

function addLink(id,call,txt){
  var e=document.createElement('a')
  e.setAttribute('href',call)
  var linktext=document.createTextNode(txt)
  e.appendChild(linktext)
  document.getElementById(id).appendChild(e)
}

function getElementStyle() {
    var elem = document.getElementById('scroller');
    if (elem.currentStyle) {
        return elem.currentStyle.overflow;
    } else if (window.getComputedStyle) {
        var compStyle = window.getComputedStyle(elem, '');
        return compStyle.getPropertyValue("overflow");
    }
    return "";
}

function addControls(){
// test for CSS support first 
// test for the overlow property value set in style element or external file
if (getElementStyle()=="hidden") {
  var f=document.createElement('div');
  f.setAttribute('id','controls');
  document.getElementById('scroller').parentNode.appendChild(f);
  addLink('controls','Javascript:clickAction(0)',StopActionText);
  onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction(0)');
  document.getElementById('controls').style.display='block';
  }
}

function stopScroller(){clearTimeout(scroll)}

function setAction(callvalue,txt){
  var c=document.getElementById('controls')
  c.childNodes[0].setAttribute('href','Javascript:clickAction('+callvalue+')')
  onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction

('+callvalue+')')
  c.childNodes[0].firstChild.nodeValue=txt
}

function clickAction(no){
  switch(no) {
    case 0:
      stopScroller();
      setAction(1,StartActionText);
      break;
    case 1:
      startScroller();
      setAction(0,StopActionText);
  }
}

function startScroller(){
  document.getElementById('tag').style.whiteSpace='nowrap'
  var p=document.createElement('p')
  p.id='testP'
  p.style.fontSize='25%' //fix for mozilla. multiply by 4 before using
  x-=step
  if (document.getElementById('tag').className) p.className=document.getElementById

('tag').className
  p.appendChild(document.createTextNode(sText))
  document.body.appendChild(p)
  pw=p.offsetWidth
  document.body.removeChild(p)
  if (x<(pw*4)*-1){x=divW}
  document.getElementById('tag').style.left=x+'px'
  scroll=setTimeout('startScroller()',speed)
}

function initScroller(){
  if (document.getElementById && document.createElement && document.body.appendChild) {
    addControls();
    divW=document.getElementById('scroller').offsetWidth;
    x=divW;
    document.getElementById('tag').style.position='relative';
    document.getElementById('tag').style.left=divW+'px';
    var ss=document.getElementById('tag').childNodes;
    for (i=0;i<ss.length;i++) {sText+=ss[i].nodeValue+" "};
    scroll=setTimeout('startScroller()',speed);
  }
}

function addLoadEvent(func) {
  if (!document.getElementById | !document.getElementsByTagName) return
  var oldonload = window.onload
  if (typeof window.onload != 'function') {
    window.onload = func;
  } else {
    window.onload = function() {
      oldonload()
      func()
    }
  }
}

addLoadEvent(initScroller)

Seizure Warning

Epilepsy and other similar conditions can be life threatening, and a quick way to cause someone with such a condition to face serious medical problems is to have flashing or blinking lights on your website. While such elements may be decorative or demanding of attention, they are typically unnecessary and could prove dangerous or even fatal for some individuals.

WCAG requires that “web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.” This includes flashing within any animations or videos displayed on the website.

It is recommended that any flashing or blinking (regardless of meeting the threshold) should be preceded by a warning of some kind to warn at-risk users before they reach that content, and provide them an alternative method of reaching the desired content or to disable the dangerous element. However, it is best to avoid having such elements in the first place.

Easy Navigation

Websites that please the eyes and accomplish their purpose quickly will sell products, while websites that annoy and frustrate do not. This is a rule of marketing, where brand loyalty is the priority. One quick way to lose customers is to make your website feel more like a maze than a streamlined and easy experience.

For WCAG and making accommodations for those with disabilities, this is even more of a concern and focus, as websites that are difficult to navigate even for the average user are going to be just that much more difficult for someone with physical or mental limitations. Instead of a potential customer, you may just find a bad review and one less site visit each month… or, even worse, an accessibility lawsuit.

To help avoid these frustrations, WCAG has outlined numerous things that can and need to be done to ensure a website is easy to navigate for anyone.

Bypasses

An easy way to make any website more appealing and easy to use is to add bypass links or elements to allow users to skip unnecessary or redundant information, and instead reach what they came for right away. Some sites like to encourage users to explore other aspects first, like grocery stores putting restrooms near the back to force customers to explore the entire store first. However, not only is this annoying but may even cause problems for users with disabilities, as it adds extra steps to a process that may already be challenging for them.

Most websites have a specific purpose in mind, and for those sites an easy way to meet compliance is to simply add a link front and center that allows users to reach that purpose immediately. This is, of course, if the primary purpose isn’t on that first front page- which may be the best course to take if possible.

For broader use websites, it may be best to provide as many simple navigation tools as possible right at the start of the website, such as a table of contents with clickable links, a search bar, or other well described and accessible buttons/links displayed in a sequential and easy to find location.

The easier it is for users to find what they came for, the better it will be for both their experience and for your reviews. This, of course, doesn’t just apply to businesses trying to build loyalty, but any website that intends to deliver a message or offer a service. The sooner people can accomplish what they came for, the happier they’ll be for it.

Link Context

WCAG requires that any and all links on your website contain clear descriptions or titles explaining what the link is and where it will take you. This doesn’t just mean including an ALT description in the link itself, but also a visible description detailing what that link’s purpose is. If the link itself is self-descriptive, this does count, but adding additional context may be beneficial and will also help you keep the link’s text length down.

Example (taken from w3.org):

      <a href="routes.html">
        Current routes at Boulders Climbing Gym
        </a>

Multiple Pathways

WCAG requires that, unless specifically intended otherwise, all web pages can be accessed by multiple links or paths. That means providing not just a link on the homepage, but also in a table of contents section or a site map. You can also provide additional links on related pages to allow the user to easily go to that page if needed.

The idea is that for users who are limited in how they can interact with a site, the less steps you require them to go through to get to a certain page, the better. By providing more than one link to every page, you reduce the potential number of steps as they will no longer have to go back as far or search around as much for the intended page.

Headings and Labels

As was discussed in the first part of this article series, site structure is crucial for helping those with disabilities navigate a website. It is thus further important to emphasize providing headings, titles, and descriptions not just in ALT text within the code, but also on the site itself.

WCAG requires that most if not all content on a site be adequately titled or labeled, and not just within the code but also in actuality as to allow users to quickly identify what it is they’re accessing and/or where their intended content is. It’s a continuing theme of ensuring users can find what they are looking for as quickly and with as few steps as possible, and then be able to understand that content as clearly as possible.

Content Focus

Typically, when a user uses their keyboard to interact with a site, if they select an element or section of text using TAB or similar, it should outline the element with a visible bar or similar outline. WCAG requires that such functionality exists as to allow users to more easily identify selected content.

This can also include providing some form of highlighting function, where instead of an outline it highlights the selected content.

Example (taken from w3.org):

In this example, mouse and keyboard focus indicators have been applied to the link elements. CSS has been used to apply a background color when the link elements receive focus.

<ul id="mainnav">
  <li class="page_item">Home</li>
  <li class="page_item"><a href="/services">Services</a></li>
  <li class="page_item"><a href="/projects">Projects</a></li>
  <li class="page_item"><a href="/demos">Demos</a></li>
  <li class="page_item"><a href="/about-us">About us</a></li>
  <li class="page_item"><a href="/contact-us">Contact us</a></li>
  <li class="page_item"><a href="/links">Links</a></li>
</ul>

Here is the CSS that changes the background color for the above elements when they receive mouse or keyboard focus:

#mainnav a:hover, #mainnav a:active, #mainnav a:focus {
  background-color: #DCFFFF;
  color:#000066;
}

In this example, the :focus pseudo-class is used to change the style applied to input fields when they receive focus by changing the background color.

<html>
  <head>
    <style type="text/css">
      input.text:focus {
        background-color: #7FFF00; 
        color: #000;
      }
      input[type=checkbox]:focus + label, input[type=radio]:focus + label {
        background-color: #1E2EB8; 
        color: #FFF;
      }
    </style>
  </head>
  <body>
    <form method="post" action="form.php">
      <p><label for="fname">Name: </label>
        <input class="text" type="text" name="fname" id="fname" />
      </p>
      <p>
        <input type="radio" name="sex" value="male" id="sm" /> <label for="sm">Male</label><br />
        <input type="radio" name="sex" value="female" id="sf" /> <label for="sf">Female</label>
      <p>
    </form>
  </body>
</html>

If using a highlight or color background to focus on an element, it is also important to ensure that users with color blindness or similar difficulties are still able to tell the difference between the content and the highlight/focus.

It is also important that anything which is focused in on via the keyboard is brought into full view. WCAG implies that you should have some way of ensuring what has been focused on can be viewed in its entirety by the user, regardless of screen size or device type.

Breadcrumbs

Another typical way to help users more easily navigate a website is to provide what is known as breadcrumbs, which help a user to identify where they currently are within a website’s structure.

The most common way of showing this is having a sequential set of page buttons at the top of the page in a navigation bar. I.e., if you were several pages deep into a website, it may look something like this:

Home > Community > Blogs > Summer 2023 > Blog #43

The user would then be able to click or interact with any of those links to return to that page (such as “Blogs,” or if they wanted to go all the way back to the start, “Home”).

Example (taken from w3.org):

In this example a h2 element, a nav element with an aria-label attribute, and an unordered list are used to provide semantics. The markup would be styled using CSS to display the breadcrumb trail horizontally.

HTML for this example

  <nav aria-label="Breadcrumbs"> 
    <h2>You are here:</h2> 
    <ul>
      <li><a href="/">Acme Company</a> &#8594;</li> 
      <li><a href="/electronics/">Electronics</a> &#8594;</li>
      <li><a href="/electronics/computers/">Computers</a> &#8594;</li>
      <li>Laptops</li>
    </ul> 
  </nav>

CSS for this example

  nav, h2, ul, ul li{ display: inline;}
  nav > h2{ font-size: 1em; } 
  ul { padding-left: 0em; }

Pointers

In contrast to keystrokes to interact with a website, a user may instead use just a pointer or cursor to interact with your site. They may be using a special tool, a mouse, or even the keyboard’s arrow keys to point to different elements of your site. It is important, therefore, to ensure that your site can be navigated entirely by a pointer.

Some WCAG rules for such are that users do not have to perform any multi-point gestures to interact with the site unless the purpose of the site requires such. In other words, unless it’s intended for a specific purpose, a user should only need to point and “click” once to fully interact with all elements on your site.

This includes moving elements or objects on a site, in that a click and hold should be enough. You should also keep in mind users who cannot hold down a mouse button, and therefore need the capability for them to interact in an alternative manner such as hovering over the content for an extended period of time of time (some tools of this sort have built in functionality to have hovering actions simulate clicks, but keeping the possibility of this feature not existing with their user’s tools should be considered).

An entirely different alternative that could be helpful is providing interactable arrows to move objects rather than requiring users to drag objects, since such tasks may prove difficult depending on available tools and how much physical movement a user is able to perform.

Users should also be able to easily cancel or abort a task, such as when dragging and dropping an element they should be able to stop or undo the action. I.e., if a user lets go of the element before it has been placed in the intended field or location, it should reset rather than get marked as if they had successfully placed it. The important part of this last note is keeping in mind users who may only have access to a pointer or cursor and aren’t able to use hotkeys such as CTRL-Z to undo or ESC to cancel. A simple undo or X button may be enough, but it’s best to provide multiple options if possible.

Motion Actuation

Some apps or devices include features such as shaking the device to undo or tilting the device to rotate the display. While useful to many people, some users with certain disabilities may be unable to perform those actions. WCAG requires that users have alternatives to these motion features, and also that they have the ability to turn off these features all together.

For example, imagine a user who has tremors or shakes uncontrollably. If your site is designed to detect shaking as an undo action, then the user may be faced with their work or actions being undone without their consent or intention. It may even be best to ensure these features are disabled by default, but can be toggled by the user if desired (in the least, you should make sure that a user can reach the settings to disable the feature before the feature applies- just imagine being stuck at the homepage and unable to change the setting because every time you shake or move it sends you back to the beginning).

Size Matters

It is important that all interactable elements are both reasonably sized and spaced apart enough that users can easily identify the element and interact with it, despite potential disabilities that may make it difficult.

The example W3C gives is again of someone with tremors, who may become frustrated trying to interact with a button that is either too small or too close to another button, wherein they may interact with the wrong one.

WCAG requires, therefore, that the size of element targets be at least 44 by 44 CSS pixels. The only exception is where the presentation requires being smaller or closer, but in such cases, it is best to provide an alternative method of interacting or reaching the intended content. Otherwise, always keep in mind that while smaller and sleeker looking buttons and tabs may be visually appealing to some, they can be a significant challenge to interact with for others.

Input Device Restrictions

Since there are many unique tools for allowing users to interact with computers and the internet, it is necessary that WCAG require that websites allow for the use of any unique input device. However, they do allow for the one exception of security of a website.

Some devices might be used maliciously or in a way that can exploit the website, and so some developers may feel pressure to prevent unrecognized or unauthorized devices from interacting with their website/application. Or the designer of the service may expect only one kind of interaction such as touch, and therefore blocks any other kind of interaction or tools to prevent unexpected results/actions (i.e., a touch screen kiosk). However, WCAG requires that developers make as many exceptions as possible to allow full accessibility to disabled or physically/mentally limited users.

One particular failure noted by WCAG is that of touchscreen only devices or sites, particularly with kiosks or similar. Users who cannot physically touch the device will need an alternative method of interacting with the service.

Conclusion

There are many aspects of WCAG which are repeated between the different sections, with only minor clarifications or specific use-cases. This implies some emphasis on certain aspects of accessibility- though we have omitted some of these repeats and have added clarification to previous sections.

That in mind, it becomes increasingly important for you and developers to recognize that the purpose of WCAG isn’t to just provide a set of rules to outline how you should build your site, but rather to help impregnate a mentality of recognizing more and more unique situations that you need to prepare your website or application to handle.

Over and over, we have included specific examples of use cases where a particular WCAG rule applies, such as with a user who is colorblind or has difficulty distinguishing between different shades. It is predicted that 1 in 12 men are colorblind, and more who face partial colorblindness or difficulties with contrast. It is very likely that you know one or several people who are colorblind or face a similar visual impairment. It is certain you know people with other disabilities, such as lameness, blindness, missing limbs, mental impairments, and so on.

WCAG becomes easier to understand as we take account of the disabilities and impairments those around us, and consider how they might be challenged with our websites and applications. Such consideration helps it become clear how we can change or build our site to accommodate those complications. It also becomes our responsibility to make our sites as simple and easy to access for them as possible.

In part 3 we will discuss the third section of WCAG, Operable. 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.

Link to Part 3: LINK

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