WCAG 2.2 and new success criteria

Last October, the long-awaited version 2.2 of WCAG (Web Content Accessibility Guidelines became the official W3C recommendation. Today we will give an overview of what’s new and how it will impact us.

Although WCAG 3.0 (which is promised to cover more user needs, be more flexible in terms of different technologies, tools and content, as well as easier to understand) is also being developed, it will still take years before it will become an official recommendation.

When will WCAG 2.2 become mandatory?

As we have mentioned in previous articles, the European Union digital accessibility standard EN 301 549 is largely based on WCAG 2.1 guidelines. However, the standard is not automatically updated and WCAG version 2.2 is not mandatory for digital environments in the European Union until EN 301 549 is updated.

A renewal is expected in 2025 when accessibility requirements will also apply for the private sector, but it is not yet certain whether WCAG 2.2’s new guidelines will also be transposed.

WCAG 2.2, like its previous versions, includes three levels of compliance: A, AA and AAA. It is recommended to meet at least level AA. In order to meet level AA, all level A and AA requirements must be met.

How does the new version differ from the old one?

WCAG version 2.2 added nine new success criteria and removed one. Indeed, this time one of the success criteria was removed because it was no longer relevant.

WCAG point 4.1.1 Parsing had outlived its time: while in the past, HTML parsing errors could mislead assistive technologies, today they are smarter and there is no need to validate HTML just for accessibility.

However, this does not mean that the HTML could contain duplicate attributes or IDs. Code errors that cause problems for assistive technologies simply need to be reported, for example, under 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value.

New success criteria

Let’s explain the new WCAG 2.2 success criteria that are mandatory to meet level AA.

Success Criterion 2.4.11 says that the element in focus must never be entirely hidden behind another element.

For users who rely on a keyboard or similar assistive technology for navigating the digital environment, it is important that they always see which element they are on. If there is a cookie message at the bottom of the screen, a sticky header at the top, or a chat window popping open in the corner, the focus element may sometimes be hidden underneath.

Moreover, in order to move onto the cookie message or chat window and close it, keyboard user usually has to move to the end of the page, since floating elements are usually last in the code. Going a little off-topic, I would suggest placing the cookie message and chat window in the beginning of the code.

Not all people can use a mouse to drag things from one place to another.

There must be an alternative for dragging (moving, reordering, grouping, etc.) elements which can be done simply by clicking. This applies for touch screens as well as dragging with a mouse.

For example, it must be possible to move the map in different directions not only by dragging your finger, but also by using arrow buttons; it must be possible to move tasks from one column to another through a context menu in addition to dragging them, etc.

Clickable elements must be large enough or far enough from each other to be clicked comfortably.

Success Criterion 2.5.8 says that the size of a clickable area must be at least 24 x 24 pixels. If there is enough free space between the clickable areas, the clickable area may also be smaller.

For example, if clickable icons on are 16 x 16 pixels in size, there must be at least 8 px of free space between them.

Help is easier to find if it is always in the same place. If there is a help mechanism on the website (for example, FAQ, message form, phone number), it must be located in the same place on each page.

If there is no help function on any of the pages, then the requirement is not applicable.

Information that has already been entered by the user must not be requested again during the same session. None of us want to type in the same thing multiple times, especially if entering information is painstaking.

If the user has already entered information (e.g. their e-mail or personal identification code) on the page, the relevant fields must be filled in automatically or the previously entered data must be offered as recommendations.

If re-entry is important, for example, for security reasons (“Repeat password”), it is of course allowed.

For a user who has difficulty reading, calculating or memorizing, it can be difficult to remember their personal identification code or password, perform calculations and solve tests.

The authentication mechanism (including the “Forgot password?” function) must not require a cognitive test (e.g. remembering a username or password by heart, calculation, etc.).

This means, for example, that when filling in the username and password fields, you need to allow copying and pasting text or using a password manager.

CAPTCHAs that require object recognition are still allowed.

How to make your digital environment meet accessibility requirements?

In order to meet accessibility requirements, it is first necessary to identify the gaps. A quick test can be done, for example, using the Google Chrome Lighthouse or WAVE tool. For a detailed and complete audit, it is necessary to manually test the digital environment with various assistive technologies.

If the relevant skills and experience are available, the accessibility audit can be carried out in house. If not, it can be ordered from an external partner. Trinidad Wiseman offers both accessibility audits and trainings.

An accessibility statement must also be created for the digital environment, such as an “Accessibility” subpage on the website or a reference to the application on the download page of the application.

The accessibility statement must contain information on what requirements the environment complies with, whether the compliance is partial or complete, an overview of the environment’s accessibility functions and how to give feedback. An example of a statement is available in the European Commission Implementing Decision (EU) 2018/1523.

Would you like an accessibility audit, consultation or training?

We are happy to help. Contact sales@twn.ee or write directly to our accessibility specialist mari-ell.mets@twn.ee

Originally published at http://blog.twn.ee.