Web Content Accessibility Guidelines Section 3A and 4A

Overview

The Web Content Accessibility Guidelines are an important resource for helping understand how accessibility works in general and especially on the web. In this lesson, you will learn Sections 3 and 4 which focus on how understandable and robust the site is.

Goals

You have the following goals for this lesson:

• Learn what the Web Content Accessibility Guidelines (WCAG) are
• Learn specifically about WCAG 2.2 A, sections 3 and 4
• Examine a web-page with accessibility issues and try to resolve the accessibility problems

Warm up

The concepts of understandability and robustness are both easy and impenetrably difficult to understand. One crucial bit often left out is: understandable to whom? Consider that in computer science there are many programming languages, often using syntax and semantics so poorly designed that the choices are often no better than random words [1,2]. Is such a design understandable? Further, given computer science education often works with children, is it more or less understandable to them?

For robustness, this aspect of WCAG is often misconstrued. When software engineers think robust, they often likely think about scale or industry or users or something similar. This is not what robust means. Robustness is really talking about whether robots, or automation broadly, can connect to your code and obtain information. What kind of information do you think these robots need for accessibility?

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 A Section 3: Focuses on improving accessibility for people with cognitive and learning disabilities by simplifying content and providing clearer instructions.
• WCAG 2.2 A Section 4: Focuses on improving navigation robustness and consistency to help users easily move through content and interact with elements.

Explore

Section 1 and 2 of the Web Content Accessibility Guidelines (WCAG) are focused on the physical aspects of accessibility. Section 1 addresses the senses of the user, ensuring the user can see, hear, or perceive the page in some way. Section 2 focuses on the user's ability to interact and ability to navigate the page. Section 3 and 4 move toward thinking about understandability and robustness. The guidelines you will find here deal with having clear instructions and labels, helping the user if they are dealing with an error, and making sure the page is compatible with various assistive technologies (robustness).

Section 3A: Understandable

The main principle of Section 3 is known as Understandable. To be understood, your content should use clear language, appear and operate in a predictable way, and when possible help users avoid and correct mistakes. Exactly what this means and how it applies is not always clear.

Consider a few examples relevant first to the web and then to computer science broadly. First, with web pages, an image of a well known actor might include their name, a visual description of them, aspects of their life or other things. Which is correct and easy to understand is not always clear, but neither does WCAG require it must be one way or another. Alternative descriptions get especially hard to write as the content becomes more complex. For some applications, like charts and visualization, they are better than nothing and meet the legal requirement, but that is about it.

Consider a different example in the field of computer science education. Every child working in K-12 uses programming languages, of various kinds and styles and these have a wide variety of attributes. These include things like:

But now consider what languages are really used in computer science education. For starters, there are minimal or no standards between languages, although there are within them (e.g., Java and C++ have their own individual standards). Language designers make it up and the rest of us essentially have to accept it. Between languages, there is little or no consistency attempted or in practice, with a few exceptions (e.g., ASCII).

Consider an example where a child is taking a high-school course in data science. Their goal is to compare columns in a spreadsheet and detect whether the average in one column is bigger than another. That is it. Here is one example of what code for that in Python might be:

import seaborn as sns
import statsmodels.api as sm
from statsmodels.formula.api import ols
crashes = sns.load_dataset("car_crashes")
model = ols('ins_losses ~ speeding', data=crashes).fit()
aov_table = sm.stats.anova_lm(model, typ=2)
print(f"model.summary():\n{model.summary()}")
print("\n\n--------")
print(f"aov_table:\n{aov_table}")

The output from this code might be something like this:

Dep. Variable: ins_losses R-squared: 0.004 Model: OLS Adj. R-squared: -0.016 Method: Least Squares F-statistic: 0.2139 Date: Wed, 22 Nov 2023 Prob (F-statistic): 0.646 Time: 09:53:12 Log-Likelihood: -235.58 No. Observations: 51 AIC: 475.2 Df Residuals: 49 BIC: 479.0 Df Model: 1 Covariance Type: nonrobust 
============================================================================== 
coef std err t P>|t| [0.025 0.975] 
------------------------------------------------------------------------------ 
Intercept 138.5491 9.444 14.670 0.000 119.570 157.528 
speeding -0.8115 1.755 -0.463 0.646 -4.337 2.714 
============================================================================== 
Omnibus: 0.544 Durbin-Watson: 2.412 Prob(Omnibus): 0.762 Jarque-Bera (JB): 0.412 Skew: 0.215 Prob(JB): 0.814 Kurtosis: 2.904 Cond. No. 14.9 
============================================================================== 
Notes: [1] Standard Errors assume that the covariance matrix of the errors is correctly specified. 
-------- aov_table: sum_sq df F PR(>F) speeding 134.050346 1.0 0.213907 0.645769 Residual 30707.101952 49.0 NaN NaN 

The question might be: Is this understandable and to whom? While the code is our own, the example is not hypothetical. Without naming names, High-school courses for data science really do exist and use languages like Python or R. Not all of the code is quite as ugly as the above example, but in our experience evidence on its understandability is often grossly exaggerated.

Consider another example. In this case, LEGO (tm) robotics for Spike (tm) uses the Python programming language for controlling the robot. The first example, at the time of this writing, that is generated in the SPIKE toolkit generates the following code:

from hub import light_matrix
import runloop

async def main():
    # write your code here
    await light_matrix.write("Hi!")

runloop.run(main())

This code is theoretically much simpler than the data science code. In this case, the words, like light_matrix.write are arguably easier to understand. However, the code also uses asynchronous functions, an event loop, and a special keyword called await, which is related to the computer science concept of coroutines. Again, the question becomes, is this understandable and to whom? No doubt many humans can learn many things, but WCAG is asking the community to think it through. The crucial point to remember is that while WCAG talks about tags and rules, do not miss the forest for the trees. If a tool is built on a mess, all the tags in the world will only provide a bandaid.

The point is not to declare the above good or bad, but to ask the community to begin the process of re-thinking our decisions from the perspective of standards, evidence, and from the WCAG perspective of understandability. From the perspective of the writers of this material, understandable code should say what it does [2]. The terms should in another way of saying it, imply what the code accomplishes. Simple words, like repeat, make more sense, than weird words like for, while, or foreach, to humans [1]. In data science, what words make sense is a complicated question. In robotics, standard terms across robotic companies could help or many other things.

This highlights in detail a major issue in WCAG. It forces you to think instead of telling you what to do. Consider this from the perspective of what the regulations actually say:

Breaking these down further in the context of web pages gives us some insight. These will be discussed next.

3.1.1 Language of Page is an example of a guideline where conforming to the guideline is meant more for assistive technology and other tools rather than users directly. Assistive technologies such as screen readers can change voices for different languages or dialects, so setting the language correctly can help users understand the content better.

These guidelines also seem to suggest that content is easier to understand if navigation is relatively consistent. Guidelines 3.2.1 and 3.3.2 suggest that navigating a page or inputting something should not alter the context of the page.

3.3.1 Error Identification is an example in which the criteria of WCAG might be simple, but when you think about them in practice, there is no guidance on implementation and the criteria might feel open-ended.

Look at 3.3.1 Error Identification more closely. Say you have an online form that requests a user to put an address in, but they forgot to input it and press the submit button. Consider the type of error information you could provide to the user. For example, text could appear that says ‘There was a problem.’ You could argue that this text satisfies the criterion, because when the user encounters an error, they are provided text that informs them of the error. However, one could reasonably argue that while this text may technically meet WCAG requirements, it falls short of the spirit of good accessibility. This highlights the limitations of WCAG, it can guide you, but only to a certain extent.

Guideline 3.3.1 also states that the error should be described. Perhaps, in the context of your system, you know there is an error, but you do not know the exact problem. Consider how you could present the error. Think about the location of the error, the color used, any icons associated with the error, the timing of when to show the error, and so on. For example, you could place it at the end of the form during validation, or you could detect and present the error immediately as the user is typing. These are all important questions to ask yourself when it comes to designing for accessibility, and it is important to understand that this can vary across different systems.

For computer science, perhaps the most definitive source on errors is the work by Becker et al. [3]. The key to understanding is that error commonality by humans tends to follow exponential decline. Further, in this exponential decline, some errors are dramatically more harmful than others. Finally, even small changes to the error messages can make a big impact. Any designer working with errors should read this source as a starting point for understandability on that topic.

Section 4A: Robust

The main principle of Section 4 is known as Robust. This section is intended to ensure that content maximizes compatibility with different technologies. For the web, this means using semantic HTML elements and specific roles so that assistive technology behaves a certain way when interacting with content.

The bottom line is that when content is so-called robust, it means that various technologies for people with disabilities can connect in. Almost always, this involves a combination of scripts and tags, if in a browser. On desktop and mobile, the situation is different. You need an array of technologies to make something robust.

Given the complexity, the discussion here should be considered preliminary. Robustness is a very complex aspect of accessibility and is extremely technical. If anything, meeting robustness is part of the reason we call this tutorial Technical Accessibility. In essence, technical accessibility means that even our core technologies, like programming languages themselves, are not immune to considerations like understandability. However, it also means that sometimes you just need to get down and dirty with the technology and force it to work with accessibility technologies at a purely nerd level.

Now consider some of the WCAG 4A considerations more directly:

Guideline 4.1.2 Name, Role, Value is an example of a criterion where it is more about how the content interacts with different assistive technologies rather than how a user interacts and understands it. While WCAG states that there should be roles and labels on a component, the standard does not tell you what exactly the correct role is in all situations. As you will see in later sections about the Accessible Rich Internet Applications (ARIA) standard, sometimes how assistive technologies or browsers interact with such information can be inconsistent.

This rule in WCAG is just one in a giant sea of rules, but we highlight it here because it is deeply, crucially, important. The wrong roles cause applications to not be accessible in many cases and for very hard to understand reasons. The core can be hard to understand, so consider an example.

Suppose a component, on any platform, has the role of ‘button’. One might presume, incorrectly, that this is just a flag to the system on what it is. Perhaps a screen reader reads it. When something has a role, it is true that it is a flag to the system. What is less clear, however, is that the systems sent this role often have follow up questions. If an accessibility device is told a button has the focus, it might then send back questions, like, ‘Are you enabled or disabled?’ It might also ask for the color, the text on the button, or other attributes. Other components, especially text fields and text boxes, may ask hundreds of questions on the user's behalf (e.g., the font, the cursor, the colors, bolding).

This simple example highlights why these roles are so crucial and so devastating to people with disabilities if they are missing. If a role is missing, then an accessibility system does not just not know something exists, but it also cannot ask questions automatically. It breaks the question-asking robot that ultimately leads to robustness. This back and forth between systems is the heart of how accessibility works.

This example also highlights why a current trend is accessibility where somehow a Large Language Model will auto-magically fix everything through hand waving AI. AI has a purpose sometimes and may have some benefits for accessibility in some situations. However, resorting to it often completely misses the point. You do not need a large language model to probabilistically guess what might sort of be a correct description when the point is actually the programmatically correct technique of robustness, which requires interactivity in a myriad of automatic and human ways.

On desktop platforms, you can sometimes change code to have complete control of the back and forth described previously. On the web, while it is very powerful for accessibility, the amount of control is quite limited. One way that you can claw back just a little bit of control is through the application of ARIA.

ARIA

Accessible Rich Internet Applications (ARIA) is a set of attributes added to elements on a page with the intent of making those elements more accessible. ARIA is not a true programming language, and what certain attributes do depends on the browser interpreting it and the assistive technology the user has. ARIA alone will not change functionality or visual appearance; it is up to the technology around the element for ARIA to do anything. A good rule of thumb is that ARIA enhances HTML, but it does not replace it.

The main features of ARIA are roles, properties, and states:

A role tells you what the element is.

<div role="button">Submit</div>

A property describes a characteristic or relationship an element has.

<div role="button" aria-describedby="more-info">Copy Example</div>
<div id="more-info">Use this button to copy the example code into the clipboard to paste into the editor </div>

A state describes the current status or value of an element.

<div role="checkbox" aria-checked="false">Remember Me</div>

For this section, one of the main things to understand is the ARIA role and labels. Guideline 4.1.2 of WCAG states that a user interface component should have a name and role that can be programmatically determined. ARIA is one way to do this, but it can also be dangerous. Take this code for example:

<div role="button">Do the thing</div>

If you opened up a screen reader and went to this element it would tell you that it is a button. The back and forth robustness dance would be. However, whether it actually is a button depends on what you expect a button to do. That is how ARIA can be dangerous. If used incorrectly, ARIA can seriously break accessibility and getting to know when to use it and when not to is important. Using ARIA does not necessarily make the page inherently more accessible. Knowing this, consider an alternate example:

<button>Do the thing</button>

This code no longer has the role attribute, but now the tag being used is a button instead of a div. This is an example of semantic HTML. The official recommendation is that, when possible, use semantic HTML in place of ARIA. This button tag will not only read correctly to a user as a button, but every modern browser adds extra functionality to this element, such as click, keyboard, and touch handlers, so that users can interact with and find this element in a variety of ways. Effectively, semantic HTML gives the robot clues, whereas ARIA gives you more control if you, and only if, you need it.

In addition to an element’s role, which defines its function, it can also have a name to define its purpose. If a name is not directly provided, assistive technology generally tries to generate a name using other information. When it comes to ARIA, there is a priority order in how a name is generated, and it is important to understand this because, if used incorrectly, you can accidentally overwrite names.

Assistive technologies rely on elements having a name to convey meaning and purpose to the user. Without a name a button or link becomes ambiguous and essentially invisible to a screen reader user. An accessible name is a name that can be programmatically determined by an assistive technology such as a screen reader. Because giving an element a name is so essential to it being accessible ARIA provides multiple ways for technologies to determine that name and only one name will be chosen. There is a priority given to these spots to compute the name and the priority for the computation is as follows.

1. aria-labelledby - this attribute points directly to other text on the page as the name of this element
2. aria-label - this attribute is a string that is used as the name
3. Associated element - Some components use native HTML associated with the element as a name for example.
   • Buttons will use the inner text
   • A <label> element in an input field
   • A <legend> elements in a fieldset

To see this priority in action, take this button as an example:

<button
    id="exampleButton"
    aria-labelledby="label1"
    aria-label="Button 1"
    title="My button's tooltip">
    <label id="label1">My Button</span>
    Some Text
</button>

This button has an id, aria-labelledby, aria-label, and title attributes along with a span element inside the button, and inner text. According to the name computation priority the first attribute in priority is the aria-labelledby attribute and this button has that attribute with the value set to ‘label1’. This is a span inside the button with the text ‘My Button’. Once a name is found name computation stops so that when it comes to the accessible name the other attributes are ignored. While this button has inner text and might appear visually to be named something else, ‘My Button’ is what a screen reader can programmatically determine and so a screen reader user would know it as such.

Keep in mind that there is a priority and a good way to find out what name a user will receive is to try using the assistive technology yourself. For example:

<button aria-label="Submit and Check Answers">
    Submit
</button>

Here, the text that a user can see visually will be Submit, but a screen reader user will hear ‘Submit and Check Answers’, which is different. The screen reader user hears the aria-label because it’s higher in priority than the inner text, and in this case, they differ. This could be confusing to some users, so it is important to approach this with caution.

Citations

1. Timothy Kluthe, Hannah Stabler, Amelia McNamara, Andreas Stefik. 2024. A randomized controlled trial on the nomenclature of scientific computing Computer Science Education, 1-29.
2. Andreas Stefik and Susanna Siebert. 2013. An Empirical Investigation into Programming Language Syntax. ACM Transactions on Computing Education 13, 4, Article 19 (November 2013), 40 pages.
3. Brett A. Becker, Paul Denny, Raymond Pettit, Durell Bouchard, Dennis J. Bouvier, Brian Harrington, Amir Kamil, Amey Karkare, Chris McDonald, Peter-Michael Osera, Janice L. Pearce, and James Prather. 2019. Compiler Error Messages Considered Unhelpful: The Landscape of Text-Based Programming Error Message Research. In 2019 ITiCSE Working Group Reports (ITiCSE-WGR ’19), July 15–17, 2019, Aberdeen, Scotland UK. ACM, New York, NY, USA, 34 pages. https://doi.org/10.1145/3344429.3372508

Engage

In the first part of this lesson you will assess some code that performs a simple task but across several different programming languages. Remember that part of accessibility is just not in the literal sense of can you read and understand the content but how design choices impact your ability to get the intent out of content. The next part of the lesson will give you a small code snippet where some bad ARIA choices will interfere with the ability of a screen reader to reflect the intent of some content.

Directions

Below are five brief code snippets from several programming languages. Each snippet performs the same task (looping from 1 to 10 and outputting if the number is even or odd). As you inspect each code snippet, pay attention to any boilerplate code that is required, how intuitive the syntax feels to you, and how easily you pinpoint the core logic of the code.

Discuss any language constructs that may have helped or hindered your ability to understand the code. The point here is very much so not to think only about code or programming languages. The point instead is to not ignore any aspect of the design. The graphics can matter. The code can matter. The language descriptions can matter. The tags can matter. When doing accessible design, the balance between thinking big picture about what matters, and thinking outside the box a bit, actually matters a great deal.

Java:

public class EvenOdd {
    public static void main(String[] args) {
        for (int i = 1; i <= 10; i++) {
            if (i % 2 == 0) {
                System.out.println(i + " is even");
            } else {
                System.out.println(i + " is odd");
            }
        }
    }
}

C++:

#include 
int main(void) {
    for (int i = 1; i <= 10; i++) {
        if (i % 2 == 0) {
            printf("%d is even\n", i);
        } else {
            printf("%d is odd\n", i);
        }
    }
    return 0;
}

Perl:

use strict;
use warnings;

for my $i (1..10) {
    if ($i % 2 == 0) {
        print "$i is even\n";
    } else {
        print "$i is odd\n";
    }
}

Python:

for i in range(1, 11):
    if i % 2 == 0:
        print(f"{i} is even")
    else:
        print(f"{i} is odd")

Quorum:

integer i = 1
repeat 10 times
    if i mod 2 = 0 
        output i + " is even"
    else
        output i + " is odd"
    end
    i = i + 1
end

For this next section you will look at the HTML of this really small form with only four controls. Do not worry about any actual implementation beyond the controls the user would see but examine these carefully.

<button role="link">Go to Contact</button>

<div onclick="submitForm()">Submit</div>

<input type="checkbox" aria-checked="true" checked>

<div role="slider" aria-valuenow="0" aria-valuemin="0" aria-valuemax="100">Score</div>

Answer these questions about this small form:

• What names and roles do you expect each control to have?
• Is there any control where the actual behavior might mismatch the semantics in the code?
• How might you go about fixing these controls?

Next Tutorial

In the next tutorial, we will discuss WCAG Section 1AA and 2AA, which describes WCAG Section 1AA and 2AA.