Introducing WCAG 2.2
In case you haven’t heard the news yet, an updated version of the W3C’s Web Content Accessibility Guidelines (WCAG) is now a W3C recommendation. WCAG 2.2 builds on, and is backwards compatible with, version 2.1. In this article, DAISY’s Matt Garrish, considers the new version of WCAG from the publishers’ perspective.
The question everyone has at this point, of course, is how the new version will affect the production of accessible publications. The good news is that WCAG 2.2 does not add any significant new burdens. Unlike WCAG 2.1, which introduced the Reflow success criterion that greatly affected fixed layouts, the new success criteria in 2.2 are not likely to have widespread impacts and do not introduce complex new requirements.
The easiest way to break the new changes in WCAG 2.2 is to look at what each level introduces.
Level A
At Level A – the minimal requirement for claiming WCAG conformance – there are only two new success criteria: Consistent Help and Redundant Entry.
Although I’m wary of ever claiming success criteria can never affect publishers, the truth is it is unlikely either of these will require you to make changes to your production processes. The Consistent Help criterion only applies if help links are repeated across content documents, which is atypical. A more equivalent best practice for publishing would be to provide help in a consistent place across all your publications, but this moves beyond the scope of WCAG. The Redundant Entry criterion applies for multi-page forms (e.g., a checkout process in an ecommerce site), another feature that is decidedly rare to find in EPUBs.
Level AA
Moving on to Level AA – the level that most legislated accessibility requires, and that builds on Level A – there are four new success criteria: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum).
These new success criteria are also likely to have only minimal impacts. The Focus Not Obscured success criterion, for example, requires that you not author content so that focusable elements, like buttons and links, are completely hidden by default. This success criterion ensures that users can perceive what they are interacting with. This problem is more prevalent on the web, however, where sticky headers and footers, dialog boxes, etc. can obscure content. These features are rarely used, or supported, in EPUBs. (Note that users can open content, like a pop-up footnote, that obscures focus; that’s not a failure.)
The Dragging Movements success criterion will also likely only impact a small subset of publishers given that scripted content is not used widely and drag-and-drop content even less so. If you do create this kind of content, however, you will likely need to ensure that there is a single pointer mode of interacting with the content for users who cannot perform drag-and-drop operations. For example, you might need to add a way for users to click a shape and use arrow buttons to move it around.
Given that most reading systems run on mobile devices, the Target Size success criterion should only reinforce best practices for activating controls, links, and similar interactive content. Its aim is to ensure that users do not accidentally activate adjacent targets. To do this, it sets the minimum size for target areas to 24 by 24 pixels. Of note here is that the success criterion does not apply to links found inline in the text but does apply to lists of links. Consequently, common publishing features, such as the tables of contents (when used in the body) and indexes, will need to be verified for compliance, among other lists of links that can occur.
The Accessible Authentication success criterion is another that falls into the bucket of changes that are unlikely to affect publishers. Users typically do not have to authenticate themselves within their EPUBs. If you do require a user to authenticate, however, you cannot require that they pass a cognitive function test such as remembering a password or solving a puzzle. There must be a more accessible alternative or a mechanism to help users with cognitive disabilities perform the test.
That recaps the most significant changes for conformance.
Additional Noteworthy Items
There are three additional success criteria at Level AAA – Focus Not Obscured (Enhanced), Focus Appearance, and Accessible Authentication (Enhanced). I am not going to go into the details of these success criteria in this summary, but you are encouraged to read up on them and meet their requirements whenever possible.
The final change in WCAG 2.2 worth noting is the obsoleting of success criterion 4.1.1 Parsing. This success criterion has always been a source of confusion as it sounded like it required all files to cleanly validate when it was actually targeting a specific problem with HTML. HTML documents, unlike the XHTML documents EPUB uses, are more forgiving about well-formedness errors (broken tags, missing end tags, invalid attributes, etc.). In the past, assistive technologies tried to correct these problems, but how they did it was inconsistent.
Success criterion 4.1.1 was introduced to try and get HTML authors to fix these well-formedness problems to make the user experience more consistent. In the intervening years since the success criterion was introduced, however, the HTML specification has become more robust about how browsers fix errors, so the inconsistency issue no longer exists. Moreover, if you have these kinds of errors in XHTML, the XML parser fails and you get an error page instead of the content. EPUB authors have always had to fix well-formedness errors so all users can read the content, in other words. That’s why the success criterion is being removed; it’s not relevant to either flavour of HTML.
Awkwardly mixed in success criterion 4.1.1 were also some parsing errors that are already covered by other success criteria. Duplicate IDs that affect accessibility, for example, are already caught by multiple other success criteria. There was no need for 4.1.1 to also capture these problems. Consequently, although 4.1.1 is now obsolete, it changes nothing in terms of accessibility requirements for publications.
Timing
At the time of writing WCAG 2.2 was a Proposed Recommendation in W3C, which is the last stage before Recommendation. The last question I’m sure you have is when will WCAG 2.2 become a W3C Recommendation. DAISY has worked with the Accessibility Guidelines Working Group, the maintainers of WCAG, during this final review step to clarify some internationalization requirements for vertical writing, but the exact timeline until WCAG 2.2 becomes a Recommendation is still unknown as there are other issues that need to be worked out. We’re hoping to see it published before the end of year, though.
On the bright side, this means there is still plenty of time to prepare for the changes the new version introduces!
Matt Garrish edits and maintains the DAISY Accessible Pubishing Knowledge Base, a valuable and free resource from The DAISY Consortium. The Knowledge Base is used widely amongst the publishing community, becoming the go-to site for EPUB accessibility information. Our thanks to Matt for this insightful post.
