Taking Accessibility Beyond Compliance

I reference the Web Content Accessibility Guidelines (WCAG) 2.1 Success Criteria in my daily work. Recently, I looked back at how I have applied my interpretation to several success criteria and how I either misinterpreted them or was too aggressive in my interpretation. I’ve since studied the success criteria further and have discussed my interpretations with others in the field.

After the solidification of my understanding, I was still left shaking my head, wanting the guidance up to Level AA to extend beyond that level of compliance, and towards improved accessibility. And in some cases, the existing success criteria simply doesn’t address the issues.

What follows are just a few of the issues I often see where the existing WCAG guidance falls short or does not address and provide guidance on select issues. While some of you may think these foundational issues have been covered ad nauseam, based on The WebAIM Million report that came out earlier this year, it would appear there are plenty of developers, designers and content editors that are either not aware of these issues, or not sure what to do.

Headings

Headings help set the overall theme for a web page or sections within a page. A visible page heading placed prominently near the top of a page lets users know what the page is about. Subheadings help group sections of content within the page. All headings should be descriptive and clear, void of marketese.

Headings (<h1>-<h6> ) provide important semantics which allow assistive technologies to understand the structure of a page, and allow their users to quickly navigate to the different sections of the page they introduce.

WCAG 2.1 success criteria provides the following guidance on headings for compliance:

• 1.3.1 Info and Relationships Level A: ensure that existing visible headings are marked up correctly and that their level reflects their relative order in the heading hierarchy.
• 2.4.6 Headings and Labels Level AA: ensure the quality of the descriptive text of the heading, not the existence of headings.
• 2.4.10 Section Headings Level AAA: ensure that sections of a web page have headings when the page is organized into sections.

So if we work only to be compliant with WCAG 2.1 Level AA, if there is existing text that visually acts as headings, we should mark them up as headings and make sure the heading text is descriptive.

Taking headings from compliant to improved accessibility

Headings need to be marked up using HTML <h1>-<h6> elements to ensure the proper structure of page content. If it looks like a heading, it should be marked up with a heading element. Each page should have one page heading (<h1>), with all subsequent subheadings used to group chunks of related sub-content. Do not skip heading levels in descending order (e.g. <h2>…<h4>).

I feel there’s a lot of room to improve the level of accessibility here. Here’s the thinking I would evangelize for.

• Every page should have a visible page heading, marked up as a <h1> heading element.
• Sections of the page that contain subtopics of the page’s overall topic should be grouped with a subheading (<h2>-<h6>). This touches upon the Level AAA success criteria of 2.4.10 Section Headings, however, I feel that where it makes sense, this level should be strived for by default.
• Heading text should be descriptive of the content; no marketese allowed.

Link Text

Links are the foundation of the web. And yet, one of the more challenging issues around the accessibility of links is the link text itself. Good link text helps individuals understand the purpose of each link so they can decide whether they want to follow it. This is not simply an accessibility issue, but an overall usability issue. And yet, I frequently run across “click here” and “learn more” link text without additional programmatic context.

WCAG 2.1 success criteria provide the following guidance on link text for compliance:

• 2.4.4 Link Purpose (In Context) Level A: the purpose of each link can be determined from the link text alone from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
• 2.4.9 Link Purpose (Link Only) Level AAA: the purpose of each link can be identified solely from its link text, so links can be understood when they are out of context.

In my mind, the Level A success criteria does not go far enough to ensure that a link’s context can be effectively formulated for proper understanding. Here’s an example where the adjacent heading provides the additional link context without any programmatic association.

When an individual with no vision using a screen reader comes across the link without the proper context, they will need to navigate and read the surrounding text, or in this case, navigate to the prior heading to determine the context of this “Learn more” link. If this pattern is repeated multiple times in a page, it can become quite frustrating for the individual using a screen reader. A method used to locate and navigate links in a page is via a links list. The three major screen readers all provide similar features:

• JAWS (Links List): Insert + F7
• NVDA (Elements List): Insert + F7
• Voiceover (macOS) (Rotor): Control + Option + U

VoiceOver for iOS and TalkBack for Android does not provide a similar feature.

It should quickly become apparent the impact this link labeling method has on individuals. Without the context included as part of the link text, no-sighted individuals using a screen reader will have to work to obtain the same context that sighted individuals can obtain with less effort.

Taking link text from compliant to improved accessibility

I believe we need to strive to extend past basic WCAG 2.1 Level AA for compliance. To truly make links accessible, let’s provide the necessary context by default within the link. The simplest method is to add the context to the text within the <a> element. While this is the preferred method, in some situations, this can become visually overwhelming. In those cases, you can simply wrap the contextual text in an <span> element with a CSS class for visually hidden, or “screen reader text.”

Revisiting our example above with the heading preceding the link, we can associate the link with the heading using the aria-labelledby attribute. As you are using existing text to craft the contextual link text, you will want to consider the quality of phrasing. In the following example, an id has been added to both the heading’s <h2> element and the link itself. Then these ids are both referenced by the aria-labelledby attribute on the link. I encourage you to not only view the code but also test this with your preferred screen reader.

Focus Indication

Speaking of links, by default, browsers provide focus indication for links and other interactive controls. This focus indication is presented as a one pixel dotted or blue border.

WCAG 2.1 provides the following guidance around focus indication.

• 2.4.7 Focus Visible Level AA: all focusable components have a visible focus indication when focused.

The purpose of this success criterion is to help a person know which element has the keyboard focus. The person referenced is partially or completely sighted. However, the key here is “all focusable components have a visible focus indication when focused.” Visible is a relative term. What might pass the success criteria of WCAG may very well still be difficult for people to see. The success criteria provides some examples of default “visible” focus indication, and guides that the default focus indication suffices. Default focus indication, per the success criteria, includes a text field caret and a border around the interactive element.

a caret within the text field

I don’t know about you, but I frequently have difficulty seeing this insertion point in a text field. How is this sufficient for compliance with this success criteria?

a visible border is displayed around the control

Ah yes, that default styling that most designers throw away like the holiday cards from the previous year because they are ugly or don’t support their design. But let me get off designer’s backs for a moment (promise, I’ll return). The default focus indication is not consistent across browsers and is not sufficiently accessible.

As these browser defaults are compliant with Level AA, there seems to be a major gap here regarding visibility.

Taking focus indication from compliant to improved accessibility

The first step is not to remove default browser focus indication (yes designer’s back to you, and including developers, too!). If the default browser focus indication has been removed from the design, and developers have implemented this via the CSS outline:none, or inherit this via an adopted framework, you are preventing everyone from understanding where they are on a page when using a keyboard. If you need further information, view this site dedicated to outline:none.

With the default focus indication intact yet insufficient (but we’re compliant), let’s look at how we might enhance the focus indication. The focus indication should be thick enough and with enough color contrast against whatever background color it resides on.

Abbreviations and Acronyms

Modern-day content and applications are littered with abbreviations or acronyms. Individuals that use a screen reader by default, or for testing will note that they are not announced, spelled out, there is not a widely supported method for spelling out abbreviations or acronyms.

WCAG 2.1 provides the following guidance around abbreviations and acronyms.

• 3.1.4 – Abbreviations Level AAA: provide a mechanism to identify the expanded form or meaning of the abbreviations or acronyms.

The techniques provided by this success criteria guide us to use the <abbr> element, which would wrap around the abbreviation or acronym. The title attribute is then used on the <abbr> element to provide the expanded version.

Simple and straightforward. Except for one problem … this method is not supported by most screen readers, by default. When an individual using a screen reader and using the virtual cursor (reading) comes across the abbreviation or acronym, only the text of the abbreviation or acronym will be announced. Here’s a list of screen readers that offer some level of accommodation using this method.

Taking abbreviations and acronyms from compliant to improved accessibility

Until there is an improved, more widely supported method to address this scenario, Content Editors should simply ensure that the first instance of an abbreviation and acronym is spelled out, followed by the abbreviation or acronym. Developers should then wrap the abbreviation or acronym with an <abbr> element, and the expanded version provided as the value of the <abbr> element’s title attribute. This will comply with the Level AAA success criteria and allow for those individuals using a screen reader that supports methods or settings to obtain the expanded version based on their needs. Lastly, it will future proof abbreviations and acronyms for improvements to come.

Summary

I have to wrap up my article, as I think my mincemeat cookies are ready to come out of the oven. I hope one or more of these topics resonated with you and caused you to rethink your approach to compliant accessibility.

The impetus for this article was my experience with referencing WCAG 2.1 success criteria. Additional inspiration came from a quote from a presentation at the CSUN Assistive Technology Conference by Billy Gregory and Karl Groves. During their presentation, a slide displayed the quote “You will never be compliant when you focus on compliance.” Compliance is good. However, it focuses on rules and laws, not the individuals most impacted by the degree of accessibility we achieve. I suggest not resting on one’s laurels because you are viewed as compliant to WCAG 2.1 Level AA. Default compliance does not necessarily equate to accessibility. However, accessible designs, code and content will always be compliant, while serving the greatest number of people with varying abilities.

"You'll never be compliant when you focus on compliance." #CSUNATC17 #a11y pic.twitter.com/H7jZ7CA77x

— William Emery (@testingsage) March 2, 2017