/* MINDFIRE BLOG */

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.