/* MINDFIRE BLOG */

Why Become WCAG Compliant?

It is simply a fact that there are many people in this world who are incapable of performing tasks in the same way most people do, or are challenged in such a way that certain accommodations need to be met to help them reach the same goals as everyone else. Disabilities can greatly limit one’s capacity to reach certain pieces of information or accomplish different tasks, but it is possible to alleviate some of that difficulty by ensuring that your business or organization works to keep your online websites and tools WCAG compliant.

In 1973, the United States Congress passed a bill known as the Rehabilitation Act, which was designed to help people with disabilities reach a similar standard of living as those without the same challenges. In 1998, Congress amended the act with what is known as Section 508, which aimed to make online Federal resources accessible in much the same way. In 1999, WCAG 1.0 was released with a set of specific guidelines that are designed to help make any website or online resource accessible to those with disabilities. WCAG has since been updated/amended to reflect the ever-changing technology around the Internet, and version 3.0 is expected to be released in the next few years.

WCAG defines disabilities that should be accommodated as any visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. There are many tools in existence that can help those with these disabilities according to their specific situation, even just within the typical browser- but it is up to website developers to make their sites and code as compliant as possible to ensure seamless integration with these tools and resources.

Now, before we get into the how, it is important to note that while WCAG and Section 508 compliance may not be legally required for your unique situation, (depending on local state or county laws) or even relevant to your business, it is still a very good idea to ensure your site is compliant; as not only will it accommodate more potential customers and users, but search engines such as Google will actively rank or list websites higher or lower based on accessibility practices. Meaning businesses or organizations will not only be seen as more ethical and easier to access, but may actually profit from meeting WCAG 508 compliance standards.

Perceivable, Operable, Understandable, and Robust

The current version of WCAG is categorized into four primary pieces: Perceivable, Operable, Understandable, and Robust. To help break down WCAG, I have decided to write four different articles that will outline each of these points and describe some of the ways you can ensure your site is compliant. This first article will focus on Perceivable, which is mostly about making sure your site is not only standardized in appearance but is also accessible to those who may not be able to perceive it the same way you can.

The current accepted version of WCAG is 2.1. However, as of writing this article, WCAG 2.2 is currently in the voting process and is expected to be published within the next month or so. That in mind, this article series has been written with WCAG 2.2 compliance as the rule with potential changes to be made as WCAG 2.2 is officially released.

Disclaimer: Most if not all information relayed in this article has been taken from or inspired by the World Wide Web Consortium website w3.org, which maintains news, guides, tips, communities, and other useful resources about WCAG. Examples of code found in this article has been borrowed from various sources including w3.org and other websites and public forums. In regards to these examples, except for those wherein Mindfire is listed as the source, Mindfire does not claim the content as its own and will remove the content upon request by its owner/creator.

Perceivable

Everyone sees the world around them differently, both socially and literally. Even colors are not perceived exactly the same by everyone, nor does everyone understand things the same.

Moreover, some people can’t see at all, are vision impaired, or simply see or understand the world in what is considered an abnormal way. There are also those who are deaf, or hearing impaired, and must rely on visual cues; or may even be both deaf and blind at the same time, requiring additional resources to help them perceive what others take for granted.

This section is designed to help you make your website as perceivable as possible, allowing users with any number of potential visual and auditory challenges access to your site.

While we will get into specifics, the easiest way to go forward with any of these steps when it comes to WCAG is to simply consider how someone with a visual or auditory disability, including learning disorders such as dyslexia (which can make reading extremely difficult), might perceive your website. Someone who is blind will likely need tools that will translate your site’s content into audible sound, or someone who dyslexic may need additional font options which are designed to help them make out words and individual letters.

The purpose of these articles is to help you consider alternative points of view, to take on the perspectives of those who perceive the world around them differently than you.

Alternative Text Meta Data

The most common and effective method of ensuring compliance is giving text alternatives to non-text content such as images, graphs, or videos.

Doing so will provide an alternative set of text to the image itself, allowing for page readers and similar tools to identify what the image or element is without having to see it. I.e., if you have a picture of your company’s employees all together, you can provide alternative text that states: “Company Photo, 2023/06/02,” alongside the names of everyone in the image from left to right. This will allow someone who is blind or otherwise visually impaired to be able to know what the image shows and who is in it.

In HTML, the easiest way to provide such is to add an “alt” description in the line of code which adds the content. For example, with images you simply add alt=text after your image link.

Example:

<img src="img_example.jpg" alt="Image Example" width="500" height="500">

You can also provide meta tags or descriptions to the page or content to help users identify the different elements or content without having to actually see that content. I.e., identifying the home page as a home page, or a blog page as a blog page.

Example (taken from the Mindfire Tech website):

<title>Mindfire Technology -  Your Custom Software and AI Development Solution!</title>
<!-- Canonical URL -->
<link rel="canonical" href="https://www.mindfiretechnology.com/">
<!-- Meta -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="Custom software development firm specializing in websites, web applications, cloud migration, mobile apps and business solutions">
<meta name="author" content="Nate Zaugg">

Another useful place to provide a text alternative is with clickable buttons or entry fields, which users may need to use in order to move around the website or access important information. One easy way to do so is to add labels to elements.

Example (taken from w3.org):

<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname"><br>

<input type="checkbox" name="subscribe" id="subscribe">
<label for="subscribe">Subscribe to newsletter</label>

Alternatively, you could provide a label that is hidden from visual users but is visible to screen readers.

Example (taken from w3.org):

<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

Your end goal should be to use as many tools HTML, your coding language, and your CMS provide to give users as many text alternatives as possible so that every piece of your website is described in such a way that any tool or resource will be able to identify what it is and the best way to describe or share it.

Audio/Visual Content Alternatives

Another important method of ensuring users have access to all content on the site is to provide the full or edited text of a video or audio file. I.e., if you have a podcast discussing changes to a service your company provides, you can provide the full discussion (or an edited down version) in the form of text, providing users and screen readers with an alternative method of learning about those changes. Even for users without any disability, this may still prove useful for users who do not wish to watch or listen to a full video/podcast and just want the details.

As a note, in HTML there isn’t an ALT= attribute for video content, but you can still add descriptions that can serve a similar purpose.

Example (taken from stackoverview.com):

<video>
  <source src="my-video-path.mp4" type="video/mp4">
  <p>Description of the video...</p>
</video>

Another sometimes overlooked feature you can include with your videos is to provide text or audio explanations for sections of videos that do not contain any spoken explanations, as to provide users with visual impairments the ability to understand what is occurring or intended by those sections. You can do so with captioning, or in the video description/transcript.

Live Content

For live content, you may need to provide some form of captioning service, known as a CART (Communication Access Realtime Translation). There are many services available to provide such, and some users may already have access to such a tool within their browser or otherwise. However, it is always a good idea to ensure that your site provides its own method of live captioning when needed.

It may also be useful to provide viewable sign-language options, especially with live content (may be easier in some cases than renting or purchasing a tool to provide live captions, especially if your business or organization already has an in-house interpreter). You can find sign language in use with almost every government broadcast, as such is typically required by law and local policy.

Site Structure

WCAG also outlines the necessity for a standardized, formal, and easy to understand structure to your website. You also need to identify in the HTML code itself what each line of code or section is meant to represent or indicate.

Example (taken from w3.org)

<div role="banner"> site logo and name, etc. here </div>
<div role="search"> search functionality here </div>
<div role="navigation"> a list of navigation links here </div>
<div role="form"> a sign-up form here </div>
<div role="main"> the page's main content here </div>
<div role="region"> a sponsor's promotion here </div>
<div role="complementary"> sidebar content here </div>
<div role="contentinfo"> site contact details, copyright information, etc. here </div>

Adding such tags or landmarks will help screen readers and users identify the meaning behind each section of your website.

Sequence

The sequence in which elements or attributes are displayed on your website should also be standardized. w3.org explains one example of how a site might be set up: “A Web page from a museum exhibition contains a navigation bar containing a long list of links. The page also contains an image of one of the pictures from the exhibition, a heading for the picture, and a detailed description of the picture. The links in the navigation bar form a meaningful sequence. The heading, image, and text of the description also form a meaningful sequence. CSS is used to position the elements on the page.” In other words, a typical website experience. The issue can come into play when organizations or businesses attempt to create a “unique” experience with their website, not realizing that some users rely upon standardized website formats.

The need for proper sequence also includes any interactable content as well, in that said content flows in a sequential manner that meets usual standards or expectations, such as with an entry box, the first name goes before last name in order of how the boxes are displayed and interacted with.

It is also important to ensure that your site reflows naturally depending on screen size, type of display, or when used in some form of screen reader. The requirements for such simply state that the site’s content shouldn’t require any additional scrolling, either vertically or horizontally, when adapted or reflowed.

Example (taken from w3.org):

  <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="UTF-8">
        <title>CSS: Using media queries and grid CSS to reflow columns</title>
        <style>

        /* Reflow Styling */
        header[role="banner"]       { grid-area: header; }
        main[role="main"]           { grid-area: main; }
        aside[role="complementary"] { grid-area: aside; }
        footer[role="contentinfo"]  { grid-area: footer; }

        .grid,
        .subgrid {
          display: grid;
          grid-template-columns: minmax(0, 1fr);
        }

        .grid {
          grid-template-areas:
          'header'
          'main'
          'aside'
          'footer';
          width: 100%;
        }

        .subgrid {
          width: calc(100% + 2rem);
          margin: 0 -1rem;
        }

        .grid-item,
        .subgrid-item {
          padding: 1rem;
        }

        @media all and (min-width: 576px) {
          .subgrid {
            grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
            margin-bottom: 1rem;
          }
          .subgrid-item {
            padding-bottom: 0.25rem;
          }
        }

        @media all and (min-width: 992px) { 
          .grid {
            grid-template-areas:
              'header header header'
              'main main aside'
              'footer footer footer';
            grid-template-columns: minmax(0, 1fr) minmax(0, 1fr) minmax(0, 1fr);
          }
        }

        </style>

      </head>

      <body class="grid">

        <header role="banner" class="grid-item">
          ...
        </header>

        <main role="main" class="grid-item">        
          ...
          ...
          <div class="subgrid">
            <div class="subgrid-item">
              ...
            </div>
            <div class="subgrid-item">
              ...
            </div>
          </div>
        </main>

        <aside role="complementary" class="grid-item">
          ...
        </aside>

        <footer role="contentinfo" class="grid-item">
          ...
        </footer>

      </body>
    </html>

You should also ALWAYS ensure that every image contains both a width and a height, not just one or the other. Technically, doing just one will usually work, but it can cause potential issues including increasing the time it takes for the image to load.

Semantics

When dealing with semantics within your text, it is important to ensure that proper elements/attributes are being used to reflect the intended message or emphasis. Some people are under the illusion that simply italicizing or bolding text counts as proper emotion reflecting semantics. However, screen readers and other tools will not necessarily pick up on such emphasis correctly.

Instead, use the existing inline text semantics available within HTML.

Example (taken from w3.org):

For emphasis, use <em>

... What she <em>really</em> meant to say was, &quot;This is not OK, 
 it is <strong>excellent</strong>&quot;! ...

Here is a short list of potential inline text semantics:

<abbr> for abbreviation
<b> for bold
<br> line break
<cite> cited source
<code> format that indicates text is an example of code
<dfn> definition
<em> text emphasis

Color Alternatives

Another aspect of a website that is often overlooked is how accessible it is to those who are colorblind or have difficulty distinguishing between colors and/or shades. The easiest way to avoid making your site difficult for such users is to avoid using color for anything other than aesthetic choices that don’t present any information.

In cases where you must use color to present information, you should provide text alternatives to allow for colorblind users or for screen readers to identify the intended message.

It is also beneficial to be aware of color contrast, and how different colors interact with each other. For colorblind users, certain colors may actually be visible while others are not, and some colors may blend in with other colors. The most common colors to be confused by those with colorblindness are red with green, and blue with yellow.

This is especially important when displaying data in charts or graphs, as while the information stored within may appear obvious to a standard user, someone who has difficulty distinguishing shades or colors may have difficulty identifying what different bars or sections of a graph mean, or to what line of text they connect to. Alongside providing a text alternative, you can also create unique ways to display the information, such as using texture (dotted lines, small shapes, etc.) instead of color to help further distinguish visual information. That being said, providing text for every section and element remains the best way to provide users an alternative method of understanding the data or message implied, as this will allow further accessibility to users who may not be able to see the visual information at all.

In the end, however, the easiest way to avoid causing issues for users with colorblindness from the get-go is to avoid using color to present important information, and to instead rely on plain text wherever possible (not images of text, but actual text).

It can also be helpful to use standardized high contrast symbols or icons to identify elements such as buttons or other indicators to help distinguish them from backgrounds (alongside text).

Text Standards

All displayed text on a site should have a sharp contrast to the background or to other objects, requiring at least a 3:1 ratio (7:1 if possible). The most common place where this would be important is when using colored text on a colored background of a similar color or shade, causing the text to blend in. It may also occur if the text color is greyscale but too light in color, or if the text color doesn’t invert properly when a background theme is changed (switching to dark mode). Regardless, WCAG has specific requirements for all text and how it should be displayed. The following requirements are taken directly from w3.org:

• Line height (line spacing) to at least 1.5 times the font size.

• Spacing following paragraphs to at least 2 times the font size.

• Letter spacing (tracking) to at least 0.12 times the font size.

• Word spacing to at least 0.16 times the font size.

• Foreground and background colors can be selected by the user.

• Width is no more than 80 characters or glyphs (40 if CJK).

• Text is not justified (aligned to both the left and the right margins).

• Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

• Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Customization

Another major help to users is to provide methods of modifying elements on your site or adding unique personalization options. The most common change that should be possible for users is font size modification, either by providing a zoom in tool or allowing for the changing of font size altogether.

Example (taken from codepen.io):

The following example allows the user to modify the font size using a slider.

HTML

<div class="container">
  <input class="none" type="range" min="0" max="10" value="1" id="slider" step="0.125">

  <h1 id="name" class="changeMe name text-primary text-center">Elon Musk</h1>

</div>

CSS

input[type=range] {
  -webkit-appearance: none;
  margin: 10px 0;
  width: 100%;
}
input[type=range]:focus {
  outline: none;
}
input[type=range]::-webkit-slider-runnable-track {
  width: 100%;
  height: 12.8px;
  cursor: pointer;
  animate: 0.2s;
  box-shadow: 0px 0px 0px #000000, 0px 0px 0px #0d0d0d;
  background: #007bff;
  border-radius: 25px;
  border: 0px solid #000101;
}
input[type=range]::-webkit-slider-thumb {
  box-shadow: 0px 0px 0px #000000, 0px 0px 0px #0d0d0d;
  border: 0px solid #000000;
  height: 20px;
  width: 39px;
  border-radius: 7px;
  background: #fff;
  cursor: pointer;
  box-shadow: 0px 0px 5px rgb(143, 143, 143);
  -webkit-appearance: none;
  margin-top: -3.6px;
}
input[type=range]:focus::-webkit-slider-runnable-track {
  background: #007bff;
}

body {
  padding: 30px;
text-transform: capitalize;}

JavaScript

document.getElementById('slider').addEventListener('input', (event) => {
    document.getElementById('name').style.fontSize = `${event.srcElement.value}rem`;
});

Another extremely useful method to improve accessibility is to allow users the ability to choose between different fonts. The primary reason for such is that some fonts are difficult for people to read, and by allowing them to change the font you will beare providing them with an alternative that may be easier for them. A specific example of this is people with dyslexia who have found certain fonts easier to read than others. Ensuring your site is flexible in this way will not only improve the user experience but will also help prevent mistakes or mis-readings that could cause future problems or misunderstandings. It is worth noting, however, that WCAG doesn’t specifically mention the need for this feature, but it does greatly improve accessibility to some users. It may be useful to research specific fonts that have proven useful to people with dyslexia.

This example provides a way to offer specific alternative fonts.

Example (taken from stackoverflow.com):

var fontSelector = document.getElementById('font-selector');

fontSelector.addEventListener('change', (event) => {
    document.body.style.fontFamily = event.target.value;
});

body { font-family: 'Arial'; }

<p> text body </p>

<label for="font-selector">Select Font</label>
<select id="font-selector">
  <option value="Arial">Arial</option>
  <option value="Times">Times</option>
  <option value="Courier">Courier</option>
</select>

Users should also have full control over audio options, and WCAG specifically discourages the use of any auto-playing audio on sites. This may include pop-ups that automatically play a video and may not be dismissible or are impossible to mute, which may cause issues or complications for users with disabilities. The general recommendation is to limit or never use audio on a website in an auto-play method, and to always include a way to control the sound (including the ability to completely mute it). If there is audio on your site, users should have the choice to choose whether or not to listen to it and at what volume.

Content Hover/Focus Interaction

A popular mechanic of most websites is to include some form of interactable content that can be initiated by hovering your mouse cursor over it, or by clicking on it (without leaving the page, aka a drop down). WCAG has specific requirements for these types of content, especially with content that may pop up on the screen and detract or cover the primary content of the page.

The outlined requirements are that all such content should be dismissible without having to move the cursor or focus, and if the content is triggered by hovering the cursor then it should be dismissible by moving the cursor away from it. Also, the content should remain present if interacted with until the user dismisses it or the information is no longer valid.

Conclusion

We live in a society and a world of unique and different people- all facing their own challenges in life. We all live with our own advantages and disadvantages, things that come natural and certain things that require assistance. Compliance with WCAG is one way to provide said assistance to those who face unique challenges that limit or make access to the world around them difficult. By making your site compliant with WCAG, you are providing them with a means to expand their ability to interact. As a business owner, you are opening the door to new customers and clients. As a private citizen just sharing their experiences, you are now sharing those experiences with others in a more complete way. There is no real excuse for most website builders to not at least attempt some level of WCAG compliance, it is simply too beneficial for everyone involved, both user and owner.

The easiest way to ensure your site meets the requirements for WCAG is to start now, and as early as possible in your website development. Make it a policy, a habit to keep accessibility in mind as you design your site, especially when adding new content such as images and videos. Always consider how the arrangement of the website’s elements and features may prove easy for some and more difficult for others, especially when it comes to color and format.

You can also use tools and programs designed to help you identify where you can improve, or where you missed something. A favorite of W3C is a browser plugin called ANDI, which can be used to identify where your website can be improved in terms of accessibility. You can find out more about that program at the following link: LINK

Part 2 of this article series will be on the second piece of WCAG compliance, Operable: LINK

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