WAI-ARIA and WCAG 2.0

Introduction

As discussed in the introduction post of this series WAI-ARIA and WCAG are two of the most important specifications pertaining to Accessibility, if not the most, and therefore we will cover the principles and ideas behind both in detail throughout this post.

WAI-ARIA

ARIA is a set of tools and guidelines that we can use to provide a more accessible experience in dynamic applications and sites. This is primarily done via HTML attributes and in necessary cases, these are updated via javascript.

Aria comes with a set of rules that are simple and if followed, will really help you in the quest for a more accessible experience for all users!

Rule 1

If you can use a native element or attribute with the semantics and behaviour you require, instead of re-purposing an element and adding an aria role, state or property to make it accessible, then do so.

Rule 2

Do not change native semantics, unless you really have to.

For example: A developer wants to build a heading that's a tab.

<!-- Do not do this: -->
<h2 role="tab">heading tab</h2>     

<!-- Do this: -->
<div role="tab">
    <h2>heading tab</h2>
</div>

Rule 3

All interactive ARIA elements must be useable with the keyboard.

If you create a widget that a user can click, tap, drag, drop, slide or scroll:

A user must also be able to navigate the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.

Rule 4

Do not use role="presentation" or aria-hidden="true" on a visible focusable element.

Using either of these on a visible focusable element will result in some users focusing on nothing.

<!-- Do not do this: -->
<button role="presentation">press me</button>

<!-- Do not do this: -->
<button aria-hidden="true">press me</button>

<!-- You could do this: -->
<button aria-hidden="true" hidden>press me</button>

Rule 5

All interactive elements must have an accessible name.

<!-- Do not do this: -->
<form action="/path/to/action" method="POST">
    ...
    Enter your name: <input type="text" placeholder="Enter your name" />
    ...
</form>

<!-- Do this: -->
<form action="/path/to/action" method="POST">
    ...
    <label>
        Enter your name:
        <input type="text" placeholder="Enter your name" />
    </label>
    ...
</form>

Lastly, I will add an addendum rule which is merely a comment in the ARIA introduction docs but I think deserves a place in the rules list:

Rule 6

Avoid ARIA wherever possible but if you must use it, no ARIA is better than bad ARIA.

"Functionally, ARIA roles, states, and properties are analogous to a CSS for assistive technologies. For screen reader users, ARIA controls the rendering of their non-visual experience. Incorrect ARIA misrepresents visual experiences, with potentially devastating effects on their corresponding non-visual experiences." - WAI-ARIA Authoring Practices - No ARIA is better than bad aria

WCAG

WCAG is very, very important to understand at the core, as it provides a basis for many of the worlds countries accessibility legislation. In the introduction article for this series, I linked a map showing the countries using WCAG as that basis and what WCAG versions they use for the legal basis.

At its core though, WCAG boils down to 4 primary principles, these are collectively known as the POUR principles.

Perceivable

• Provide text alternatives for non-text content.
• Provide captions and other alternatives for multimedia.
• Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
• Make it easier for users to see and hear content.

This section is quite self explanatory but also has a few areas which some people get stuck on at times, lets take a look at some simple things we can do to help with user perception and how that relates to context.

Firstly we will look at images:

    <!-- Do not do this: -->
    <img src="https://my-awesome-site.com/girl.png" />

    <!-- Do this if the image is only for decoration: -->
    <img src="https://my-awesome-site.com/girl.png" alt="" />

    <!-- Do this if the image provides meaning: -->
    <img src="https://my-awesome-site.com/girl.png" alt="a blonde girl in a white dress sitting on green grass under a blue sky" />

    <!-- You can also this if the image provides meaning and you would like to provide the text for sighted users also, this is also a great thing to do: -->
    <figure>
        <img src="https://my-awesome-site.com/girl.png" alt="" />
        <figcaption>
            A blonde girl in a white dress sitting on green grass under a blue sky
        </figcaption>
    </figure>

Next we can look at audio and video which should always preferably come with transcriptions, this can be provided through Audio descriptions and Web Video Text Tracks, among other things. Here is an article by WebAIM about transcripts in different multimedia such as video and audio and another on Web Video Text Tracks which allow us to provide closed captioning on videos for example.

This principle also includes topics like using appropriate font-sizing and colour contrast, so user can read sufficiently. We will learn more about topics like this in the design article that comes next.

Clearly we are only scratching the surface here but hopefully this gives you a good idea of the aims of this principle.

Operable

• Make all functionality available from a keyboard.
• Give users enough time to read and use content.
• Do not use content that causes seizures.
• Help users navigate and find content.

Not everyone uses a mouse to navigate around. Some may use a keyboard or a virtual keyboard. Others may use their voice via tools like Dragon Naturally Speaking, or a form of switch.

The point is, you can never know which of these is being used by your users. Even with the best analytics it can be hard to know definitively, thus, your content should be accessible to all of these and more. This is easy if you follow semantic, simple, well thought out structures and more importantly, stick to them. Remember that most of the problems caused for users of these technologies come from us as developers and designers, not the platforms or operating systems. Some things you can easily implement to help with this principles essence would be:

Implement skip links, this is a super simple change that will dramatically help users navigate your site and bypass unnecessary and unwanted areas of content.

Use links that mean something, for example:

    <!-- Do not do this: -->
    <a href="https://my-awesome-site.com">here</a>

    <!-- Do this: -->
    <a href="https://my-awesome-site.com">my blog where I tell you about me</a>

This may be a convoluted example but you should get the general idea.

Provide a correct document structure, for example:

    <!-- Do not do this: -->
    ...
    <div class="header">
        <h1>My site title</h1>
    </div>
    <div class="content">
        <h4>Some section title</h4>
        <p>Some long paragraph of content.</p>
        <h6>Some subtitle</h6>
        <p>Some long paragraph of content.</p>
    </div>
    ...

    <!-- Do this: -->

    ...
    <header>
        <h1>My site title</h1>
    </header>
    <section>
        <h2>Some section title</h2>
        <p>Some long paragraph of content.</p>
        <h3>Some subtitle</h3>
        <p>Some long paragraph of content.</p>
    </section>
    ...

See how we use semantic markup to give meaning to our elements and provide headings in order rather than just because they may look or fit how you think they should?

These elements have meaning and also help users using assistive technology to navigate the page easier. This means less code and a far better experience for all. This can be extrapolated as far as you like, either way, the point is, semantics and structure matter.

Understandable

• Make text readable and understandable.
• Make content appear and operate in predictable ways.
• Help users avoid and correct mistakes.

Does the code you are writing match what the user sees and provide the correct semantic for non visual users, for example:

    <!-- Do not do this: -->
    <p>Lorem ipsum dolor sit amet, <span class="some-bold-class">consectetur adipiscing</span> elit. Sed iaculis purus vitae felis cursus.</p>

    <!-- Do this: -->
    <p>Lorem ipsum dolor sit amet, <strong>consectetur adipiscing</strong> elit. Sed iaculis purus vitae felis cursus.</p>

Using semantic markup like this, we can provide the styles we want and provide meaning to the content we are putting out into the world. Semantic markup will be a topic we cover in the development article later in the series.

Another thing to take into consideration is, are you using jargon or slang in the text you are writing? Remember that not everyone visiting your site may be a native speaker and so simple language is a core accessibility principle and thus, for example:

    <!-- Do not do this: -->
    <p>CPP: In the event of a vehicular collision, a company assigned representative will seek to ascertain the extent and cause of damages to property belonging to all parties involved. Once our representative obtains information that allows us to understand the causality, we may or may not assign appropriate monetary compensation. The resulting decision may occasion one of the following options: the claim is not approved and is assigned a rejected status, the status of the claim is ambiguous and will require additional information before further processing can occur, the claim is partially approved and reduced payment is assigned and issued, or claim is fully approved and total claim payment is assigned and issued.</p>

    <!-- Do this: -->
    <p>
        Claims Processing Procedure (CPP): If you have a car accident, our agent will investigate. Findings will determine any claim payment. This could result in:
    </p>
    <ul>
      <li>Approved claim - full payment</li>
      <li>Partially approved claim - reduced payment</li>
      <li>Undetermined claim - more information needed</li>
      <li>Rejected claim - no payment</li>
    </ul>

Credit to the WAI Writing Tips page for the example.

We are still conveying all the information required but unlike before, it is now more digestible and understandable to a wider audience of user.

Another consideration towards this principle would be images, video and audio, all of which we discussed previously. In the case of this principle it is about ensuring you are marking up the code for these items correctly as we have seen. In tandem with this, make sure the text content you use in the alt, figcaption or text tracks are as simple and understandable as possible.

Theres a lot of different things to consider in this principle, far more than the examples I have given but I hope this is a good foundation for your continued consideration in your projects and studies on the principles.

Robust

• Maximise compatibility with current and future user tools.

Primarily for this principle boils down to the question: Am I providing a similar appearance and behaviour across browsers, devices and operating systems, device sizes, etc?

Conclusion

That was a whole lot of information to take in but if you can understand, take on board and begin using these principles from ARIA and WCAG, you will have a great basis going forward.

I highly recommend that you go and check out the following resources to continue your learnings on these topics:

• Using ARIA
• ARIA authoring practices
• WCAG 2.1 Specification
• Understanding WCAG 2.1
• ARIA techniques for WCAG 2.0

See you in the next one!

Comments

[kamaladenalhomsi]

coming from 2021, still a great series to read.
Thank you so much! this is actually not only about accessibility, it's also about building high quality web apps.

[LaurentDev]

Great article, useful examples. This series has all I was looking for regarding accessibility.

[James Robb]

Thanks for the kind words, I hope you learned a lot and continue digging deeper!