Posted on by Ian Pouncey in Standards, Testing
Tags: WCAG
In our second post on WCAG 2.1 Level AAA, we discuss how to test against various Level AAA success criteria. You can read about the benefits of Level AAA and when to consider including Level AAA Success Criteria in our first post, Understanding WCAG 2.1 Level AAA, and what to do with your test results in our third post, Triaging WCAG 2.1 Level AAA.
As explained in our Web Content Accessibility Guidelines (WCAG) primer, the guidelines are a set of recommendations for making websites and applications accessible. These guidelines are split into four principles:
These four principles are broken down into twelve guidelines. These are in turn broken down into the individual requirements known as “Success Criteria” or "SC" for short. An example guideline, Guideline 1.1 Text Alternatives, is written as follows:
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
Understanding these principles and guidelines is not essential for testing against WCAG 2.1; in theory the text of each SC provides all of the information you need. However, they give a sense of the intent or spirit of the requirements and this can help understand how to test for them.
Testing Level AAA success criteria can be a challenge. Most tools available for automated or manual testing only cover Level A and Level AA criteria. Here are some suggestions for testing a sample of the Level AAA success criteria.
Some success criteria deal with what WCAG calls time-based content. This is usually audio and video content.
The first is SC SC 1.2.6 Sign Language (Prerecorded) (Level AAA). This can be assessed in the same way as SC 1.2.2 Captions (Prerecorded) (Level A), at least to an extent.
Identify any content that requires captions, then check that there is sign language available as well. What makes this more challenging for most people is checking that the sign language is accurate. I can determine this in spoken English with English captions, but I don't know sign language. A single spoken language may also have many sign language equivalents. English may be signed with American Sign Language (ASL), British Sign Language (BSL), and more.
Minimally check that sign language is available. If possible, confirm with someone proficient in sign language that it is accurate.
SC 1.2.7 Extended Audio Description (Prerecorded) (Level AAA) is related to SC 1.2.5 Audio Description (Prerecorded) (Level AA). Both require a spoken description of visual only content of a video.
The Level AA version only requires sufficient description to a level of detail that fits within existing pauses within the video content. The Level AAA criteria requires that if an extended audio description would be beneficial, for example a more extensive description of dialog, that the video is paused to allow for this description.
Whether or not these extended descriptions fall under the Level AAA SC is a matter of judgement. If you've not watched a video before, play it without looking at the visual content and check:
If these checks fail content may need extended audio description.
There are several success criteria related to the accessibility of content.
SC 1.3.6 Identify Purpose (Level AAA) is in an unfortunate state at the moment. It requires that the purpose of all user interface components, icons, and regions can be programmatically determined.
For some components this is quite straight forward. For example, the 'required' or error state for a form element can be identified with an attribute, aria-required or aria-invalid, in the markup.
Where this SC can't realistically be implemented is with icons and similar page elements. There isn't currently a fully specified and widely supported method of describing an icon of a question mark in a circle as being a 'help' icon. While the Cognitive and Learning Disabilities Accessibility Task Force (COGA) at the W3C is working on such a specification, it is not ready to use at the time of writing.
SC 3.1.3 Unusual Words (Level AAA), SC 3.1.4 Abbreviations (Level AAA), and SC 3.1.6 Pronunciation (Level AAA) can be assessed together. What we are looking for are examples of unusual words, abbreviations, and words that can have more than one meaning depending on their pronunciation.
Unusual words can be a matter of judgement, but look for idioms and jargon within the content and ensure there is a definition for these terms.Abbreviations should be expanded when they are first used within the text.
For pronunciation, look for words that could be ambiguous even within the context of the text. For example, 'desert' can mean an arid region or to abandon. If it is used in a sentence, ensure that it is clear which of these meanings is correct, and if not, there is some method of determining which is correct.
There are several Success Criteria related to the presentation of content that build on Level A or Level AA Success Criteria.
SC 1.4.6 Contrast (Enhanced) (Level AAA) is tested in the same way as SC 1.4.3 Contrast (Minimum) (Level AA), but the threshold for passing is increased.
The minimum contrast for regular text increases from 4.5:1 to 7:1, and for large text it increases from 3:1 to 4.5:1. There is a slight increase in difficulty for testing these ratios because most tools you may use, such as Deque's Axe or TPGi's ARC Toolkit only test to the Level AA requirements. Tenon can be used to find Level AAA issues, but this is often used as part of continuous integration rather than testing individual pages.
If you are comfortable using developer tools, change the styling of text so its size falls below the 18.5px threshold for "large text". If Axe or ARC Toolkit finds text that falls below the 4.5:1 contrast ratio, it must fail the Level AAA requirement as this is the minimum required for all text. You will then need to determine if it should be a minimum of 4.5:1 or 7:1.
The most reliable tool to use is the TPGi's Colour Contrast Analyser when manual testing contrast ratios. It gives pass/fail results for normal and large text against both Level AA and Level AAA SC.
SC 1.4.8 Visual Presentation (Level AAA) combines and extends several other Success Criteria. It has similar requirements to SC 1.4.12 Text Spacing (Level AA) regarding line spacing (leading).
It increases the minimum paragraph spacing (the space following a paragraph) to 1.5 times the line spacing. If the line spacing is 1.5, this means a minimum paragraph spacing of 2.25 (1.5 × 1.5). Note this does not have to be the default presentation of text. The requirement is that there is a mechanism for achieving this:
The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Therefore, anything that can be done in developer tools, found in every modern browser, is considered sufficient (if not exactly usable). If you are using a bookmarklet to increase text spacing for SC 1.4.12 Text Spacing it will give you a high degree of confidence already, but you can modify the applied styles to cover the Level AAA requirements.
This SC also requires that text is not justified which can also be achieved using developer tools.
Finally, text spacing requires that text can be displayed with a line length of no more than 80 characters and that:
"Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window."
Sites that meet SC 1.4.10 Reflow (Level AA) will automatically pass the second clause. They will almost certainly allow for 80 characters or fewer line lengths by either increasing the browser zoom level or by resizing the viewport. On mobile devices or tablets with a fixed viewport width, the screen width is usually fewer than 80 characters will display on a line. The text sizing settings on the device can also be used to reduce the number of characters per line on larger screens.
Current web design and implementation practices mean this success criterion is generally achievable by default. What is really being tested is that nothing is preventing the normal use of the browser. An example of this would be a site with JavaScript used to force a particular display of content, perhaps by scaling content to fit perfectly within a viewport, but by doing so, it overrides any preferences or customisations that have been set by the person using the site.
There are three notable success criteria overlap when it comes to testing interaction.
SC 2.1.3 Keyboard (No Exception) (Level AAA) is an enhancement of SC 2.1.1 Keyboard (Level AA). The Level AA success criterion has an exception for "where the underlying function requires input that depends on the path of the user's movement and not just the endpoints". So a graphics application that uses cursor movement controlled by a pointing device like a mouse, touchpad, or touchscreen to draw shapes on a canvas would have that functionality exempted. The Level AAA success criteria removes that exemption. Usually, meeting Level AA will mean a pass of Level AAA because that type of functionality is rare. The testing requires you to identify any keyboard interactions that only pass SC 2.1.1 because of the exemption.
Functionality that may fail SC 2.5.6 Concurrent Input Mechanisms (Level AAA) is rare. Using the graphics application as an example, this SC would require a line to be drawn using a touchpad and then have the user choose to use a keyboard to continue drawing the line. In this way, concurrent input mechanisms can be used interchangeably.
For regular sites and applications, making all functionality keyboard accessible supports other modes of input automatically. For example, if a button can be activated with a keyboard, it can also be activated using a switch control or voice recognition software. So look for exceptions and attempt to use them in this multi-modal way.
SC 3.2.5 Change on Request (Level AAA) expands on SC 3.2.2 On Input (Level A). The Level AA requirement is that changing the value or setting of a user interface component, such as the value of a <select> element, does not change the page's context. For example it does not take the user to another page on the site, unless the user has been informed of this beforehand.
At Level AAA the requirement removes the option to inform the user of this type of interaction and requires that all changes of context are made explicitly or can be changed so that this is the case. For example, a <select> element that changes the current page would need to have a submit button control that triggers the change in context. This is considered good practice anyway, and I've rarely seen a site or application that passes SC 3.2.2 On Input by informing the user of the behaviour they can expect.
While not exhaustive, I hope this helps with testing some of the more interesting Level AAA SC.
For convenience, we provide links to all twenty-eight WCAG 2.1 Level AAA success criteria:
Find out how we went about meeting WCAG Level AAA on the TetraLogical website, or how assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.
Updated 21 April 2023.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。