Part of NewFormat AB Portal
Web Content Accessibility Guidelines / WCAG focuses on helping
users with disabilities to access digital information and services.
In June 2018 the WCAG 2.1 standard was released.
It wasn’t intended to replace WCAG 2.0 and WCAG 2.0 is still valid.
WCAG 2.1 builds on WCAG 2.0 and continues to improve the lives of the disabled.
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:
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.
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 we take a look below 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.
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;
for instance the Colour Contrast Analyser by The Paciello Group.
In this Success Criterion 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:
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 Success Criterion if the applicable style properties are used.
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 Success Criterion 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 Success Criterion, users need to
be informed of any data that will be lost if and when they are timed out.
This Success Criterion 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.
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”.
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.
As mentioned in the previous section,
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 Success Criterion,
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.
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).
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.”
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.
As a leading vendor of solutions for accessible PDF, CommonLook support WCAG 2.1.
CommonLook PDF Validator and CommonLook PDF currently support
testing against and remediating to the WCAG 2.1AA level.
CommonLook Clarity provide full support for WCAG 2.1AA testing.
In the near future,
CommonLook Office will be supporting WCAG 2.1 for document authors.
 Close Window
|
All content © copyright NewFormat AB. All rights reserved.
All product names, trademarks and registered trademarks
are property of their respective owners.