In June 2018 the WCAG 2.1 standard was released. It wasn’t intended to replace WCAG 2.0and WCAG 2.0 is still valid.
The primary focus for WCAG 2.1 was to improve web accessibility for people with disabilities who fit into one (or more) of the following three groups:
- Users with cognitive or learning disabilities
- Users with low vision
- Users with disabilities on mobile devices
WCAG 2.1 builds on WCAG 2.0 and continues to improve the lives of the disabled.
An important thing to note about the two versions is that if a webpage (or, by extension, a PDF) passes at the WCAG 2.1AA level, then it will also pass WCAG 2.0AA.
As we take a look at what’s new in WCAG 2.1 as it relates to PDFs, we will indicate the success criteria (S.C.) and the conformance level – A, AA, or AAA.
Document Creation
Success Criterion 1.4.11 – Non-Text Contrast (AA):
Similar to the contrast checkpoint in 2.0, this checkpoint specifies that graphical elements need to have a contrast ratio of at least 3:1 against adjacent colors unless the “particular presentation of graphics is essential to the information being conveyed”.
If you are not using a good contrast checker already, now you have an even better reason to find one. I’m particularly fond of the Colour Contrast Analyser.
Success Criterion 1.4.12 – Text Spacing (AA):
In this S.C., recommendations are made for content that supports the style properties of line height (line spacing), spaces after paragraphs, letter spacing (tracking) and word spacing, so that when these properties (and only these properties) are set according to the WCAG recommendations, no content or functionality is lost.
Specifically:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
That said, if there are “Human languages and scripts” that do not use one or more of the style properties listed above then files can still conform to this S.C. if the applicable style properties are used.
Success Criterion 2.2.6 – Timeouts (AAA):
This success criterion is generally not applicable to PDF unless there’s JavaScript in a form, for example, that sets a timer. If there is, similar to S.C. 2.2.1 – Timing Adjustable – where users need to be warned that they are running out of time to complete a certain task and are given the functionality to indicate that they need more time, with this S.C., users need to be informed of any data that will be lost if and when they are timed out.
Success Criterion 2.5.2 – Pointer Cancellation (A):
This S.C. is not really going to be applicable to PDFs except when making forms accessible. Basically, it’s saying that when a “single pointer” is used – for example when checking a checkbox in a form by clicking it with the mouse – pressing down on the mouse button shouldn’t “execute the function” (check the box). Rather, the checkbox should become checked when the user lets go of the mouse button (“mouse up”). Also, there has to be a way to “abort the function” (not check the box) or to undo it after it’s been checked. From an authoring standpoint, including a “clear form” button, or using checkboxes that can just as easily be unchecked, takes care of this. There are a couple of other things that are addressed, too, such as the “down-event” (pressing down on the mouse button) being ok to trigger something if the “up-event” (letting go of the mouse button) reverses it or if, for some reason, the functionality of the “down-event” is essential. Generally speaking, though, if you make the “up-event” the trigger then you’ll be in compliance with this success criterion.
Note: There are other instances in a PDF where this might be applicable, such as with links. However, that functionality is implemented by the “user agent” and is not, therefore, a concern of the author or document creator.
Success Criterion 2.5.3 – Label in Name (A):
When creating forms, make sure that the visible label (for the question) matches, as closely as possible, the tooltip that will be read by assistive technologies. Also, make sure that the “name” of the form field matches the question. For example, if the question is “What’s your age?” then the name for the form annotation should be “age.”
Document Remediation
In addition to new authoring considerations, when it comes to PDF remediation there are fewer new success criteria in WCAG 2.1 that we need to address as well.
Success Criterion 2.2.6 – Timeouts (AAA):
As mentioned in the previous section, his success criterion is generally not applicable to PDF unless there’s JavaScript in a form, for example, that sets a timer. If there is, similar to S.C. 2.2.1 – Timing Adjustable – where users need to be warned that they are running out of time to complete a certain task and are given the functionality to indicate that they need more time, with this S.C., users need to be informed of any data that will be lost if and when they are timed out. If the remediator is tasked with adding the JavaScript to form annotations, they need to know this. Also, it might be helpful to include this information in the tooltip so that the user is aware. Generally, though, this should be addressed during document creation.
Success Criterion 2.5.2 – Pointer Cancellation (A):
This success criterion was addressed more thoroughly in the “Creation” section of this article. From a remediator’s perspective, though, in forms, for example, make sure that the Action on a form annotation is set to “mouse up” (and “on blur” for people who aren’t using a mouse to fill out a form).
Success Criterion 2.5.3 – Label in Name (A):
When remediating forms, make sure the tooltips on the form annotations match, as closely as possible, the visible label for the form fields. Similarly, if the remediator is tasked with adding the form annotations themselves, make sure that the field names match the question and aren’t something ambiguous like “Text Field 3.”
Other Success Criteria Not Previously Mentioned
We should also mention that there are, in fact, additional new success criteria in WCAG 2.1 that we have not brought to your attention in this article primarily because they don’t really impact us as document creators or remediators. Some of them are not applicable to PDF or it could be that they are things that are controlled by the functionality of the “user agent” and not the document author or remediator. We just didn’t want you to think we missed them.
What is CommonLook Doing About All of This?
Hopefully this article helps you more clearly weed out what in WCAG 2.1 is relevant to you in your document creation and remediation efforts. As the leaders in PDF accessibility, CommonLook is here to help. In fact, CommonLook’s PDF Validator and PDF remediation software products are currently supporting testing against and remediating to the WCAG 2.1AA level. In the near future, CommonLook Clarity will also be testing against WCAG 2.1AA and CommonLook Office will be supporting WCAG 2.1 for document authors.
Learn more at commonlook.com.
References:
WCAG 2.1 – https://www.w3.org/TR/WCAG21/
WCAG 2.0 – https://www.w3.org/TR/WCAG20/
