Web Content Accessibility Guidelines (WCAG)

• In terms of accessibility, WCAG is considered the “gold standard” for conformance testing. The goal of WCAG is to provide a single shared standard for digital accessibility that meets the needs of individuals, organizations, and governments worldwide.
• The WCAG guidelines have three levels of success criteria: A, AA, and AAA. The success criteria determine conformance to WCAG. To meet WCAG conformance, the digital product you are testing needs to meet the success criteria for your target level.
• For the current standard (WCAG 2.2), there are 87 success criteria in total, split across each level. It is important to note that each level is progressive, meaning if your accessibility goal is AA, you must pass the success criteria for both A and AA to achieve this level of conformance.
• There are four principles of WCAG—Perceivable, Operable, Understandable, and Robust (POUR).

Perceivable

• Adding text alternatives to all non-decorative images and essential icons.
• Adding captions, transcripts, and audio descriptions to videos.
• Ensuring color is not the only method of conveying meaning.

Operable

• Adding keyboard and touchscreen support to all active elements.
• Ensuring slideshows and videos have all of the necessary controls available.
• Giving users enough time to fill out a form or a method to extend the time.

Understandable

• Writing simply—don’t use a complex word when a simple one will do.
• Ensuring your digital product has predictable navigation.
• Ensuring error messages are clear and easy to resolve.

Robust

• Testing keyboard-only navigation.
• Testing with different screen reader technologies.
• Ensuring all of the content and functionality can be accessed, regardless of device size or orientation.

Accessible Rich Internet Applications (ARIA)

“WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make web content and web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with HTML, JavaScript, and related technologies.” – The WAI group

ARIA modifies incorrect or incomplete code to create a better experience for those using AT by changing, exposing, and augmenting parts of the accessibility tree.

The accessibility tree is created by the browser and based on the standard Document Object Model (DOM) tree. Like the DOM tree, the accessibility tree contains objects representing all the markup elements, attributes, and text nodes. The accessibility tree is also used by platform-specific accessibility APIs to provide a representation that assistive technologies can understand.

The three main features of ARIA are roles, properties, and states/values.

Roles define what an element is or does on the page or app.

<div role="button">Self-destruct</div>

Properties express characteristics or relationships to an object.

<div role="button" aria-describedby="more-info">Self-destruct</div>
 
<div id="more-info">This page will self-destruct in 10 seconds.</div>

States/values define the current conditions or data values associated with the element.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>
 
<div id="more-info">This page will self-destruct in 10 seconds.</div>

While all three elements of ARIA can be used in one line of code, it’s not required. Instead, layer ARIA roles, properties, and states/values until you’ve accomplished your final accessibility goal. Correctly incorporating ARIA into your code base ensures that AT users will have all the information they need to use your website, app, or other digital product successfully and equitably.

When to use ARIA?

1. Use ARIA attributes when the design doesn’t allow for a specific HTML element or the wanted feature/behaviour isn’t available in HTML. When in doubt, use semantic HTML elements.

   Don’t	Do
   <a role="button">Submit</a>	<button>Submit</button>

2. Don’t add unnecessary ARIA to HTML. In most circumstances, HTML elements work well out of the box and do not need additional ARIA added to them. In fact, developers using ARIA often have to add additional code to make the elements functional in the case of interactive elements.

   Don’t	Do
   <h2 role="tab">Heading tab</h2>	<div role="tab"><h2>Heading tab</h2></div>

3. Always support keyboard navigation. All interactive (not disabled) ARIA controls must be keyboard accessible. You can add tabindex= "0" to any element that needs a focus that doesn’t normally receive keyboard focus. Avoid using tab indexes with positive integers whenever possible to prevent potential keyboard focus order issues.

   Don’t	Do
   <span role="button" tabindex="1">Submit</span>	<span role="button" tabindex="0">Submit</span>

4. Don’t hide focusable elements. Don’t add role= "presentation" or aria-hidden= "true" to elements that need to have focus—including elements with a tabindex= "0". When you add these roles/states to elements, it sends a message to the AT that these elements are not important and to skip over them. This can lead to confusion or disrupt users attempting to interact with an element.

   Don’t	Do
   <div aria-hidden="true"><button>Submit</button></>	<div><button>Submit</button></div>

5. Use accessible names for interactive elements. The purpose of an interactive element needs to be conveyed to a user before they know how to interact with it. Ensure that all elements have an accessible name for people using AT devices. Accessible names can be the content surrounded by an element (in the case of an <a>), alternative text, or a label. For each of the following code samples, the accessible name is “Red leather boots.”

   <!-- A plain link with text between the link tags. -->
   <a href="shoes.html">Red leather boots</a>
    
   <!-- A linked image, where the image has alt text. -->
   <a href="shoes.html"><img src="shoes.png" alt="Red leather boots" /></a>
    
   <!-- A checkbox input with a label. -->
   <input type="checkbox" id="shoes" />
   <label for="shoes">Red leather boots</label>

ARIA in HTML

While using HTML elements on their own is best practice, ARIA elements can be added in certain situations. For example, you may pair ARIA with HTML in patterns that need a higher level of AT support because of environmental constraints or as a fall-back method for HTML elements that aren’t fully supported by all browsers.

Of course, there are recommendations for implementing ARIA in HTML. Most importantly: don’t override default HTML roles, reduce redundancy, and be aware of unintended side effects.