WCAG 2.2 is a somewhat delayed update to 2.1 and adds 9 new success criteria on top of the existing ones in 2.1. It is primarily concerned with visual, cognitive and motor skill impairments.
When will WCAG 2.2 be released?
Changes to the new criteria following feedback after the draft stages has been taken into account and a new candidate recommendation was released in Jan 2023. This is now being looked at by the accessibility community for the ability to test, ease of understanding and impact for users. It is likely that the final recommendation will be released in the third quarter of 2023 (updated 25 April 2023).
When will WCAG 2.2 become a legal requirement?
WCAG itself is not a law but a series of guidelines. However it is referenced by other laws and is likely to be made reference to in legal cases.
WCAG is currently referenced in the Public Sector Bodies Accessibility Regulations (and the European equivalent) as the minimum standard to be reached. That 2018 regulation has already been amended (in 2022) to prepare for the new release of the guidelines. The new statement now reads (emphasis mine):
A website or mobile application of a public sector body will be presumed to be in conformity with the accessibility requirement to the extent that the website or mobile application conforms to Level A and AA Success Criteria as set out in the Web Content Accessibility Guidelines recommended by the World Wide Web Consortium, as amended from time to time
As such as soon as the new criteria are published they become enforceable.
Are UK sites expected to be conformant as soon as they are released?
Once the final recommendations are published there is likely to be a 12 month grace period for UK public sector sites to ensure they are compliant. The GOVUK Design System team will need to update their components and release them - they have a goal to do this within 6 months of release. This will give public sector teams an additional 6 months to apply those changes.
UK government sites will being to be monitored for compliance in 2024.
However it would be beneficial for site owners to begin to review their designs now to see where the new criteria might affect them and begin to plan accordingly.
What should I do?
Most of these changes are likely to affect more commercial sites so if you are working on non-governmental clients there is likely to be more work required. However even if you only use government department components there is still work you can do to prepare.
- Don’t rush to make changes. Wait for the final release of the guidelines. But this doesn’t mean you cannot plan.
- If you are responsible for procuring sites or services you should look to have WCAG 2.2 named in the contractual agreement as a requirement so everyone understands what is expected of them.
- If you have a Design System, make sure the design system team are aware of the upcoming changes and have a plan ready.
- Ensure that your own team is using the latest version of the relevant code libraries and that components used are being updated alongside libraries so you can take advantage of the central code updates when they come through.
- Review any components your team have built and check that none of the new criteria affect them. Create a plan to update them if so.
- Some of these changes are purely visual (like Focus Appearance) but others might require reworking of components (Dragging Movements) or even whole journeys (Accessible Authentication and Redundant Entry). Get the whole team involved so everyone knows what the aims of the criteria are and how you will meet them.
Has anything changed in the existing criteria?
Two things have changed - Parsing has been removed (the first time this has happened) and the status of Focus Visible has been upgraded to level A instead of level AA.
4.1.1 Parsing (A) has been removed
There has been a lot of debate around this, but at the moment it looks like it will be removed because any failures caught by it currently are also covered by other criteria. This criteria often causes confusion around what is or is not classed as a failure vs just bad code. Much improved parity between browsers in how they handle poor html means its impact can be anticipated now whereas before it was often a different outcome for different browsers.
For example a duplicate ID might be an issue only if it is being to reference an element for accessibility purposes. Removal of this criteria means the confusion is removed and we can concentrate on the actual impact on the user.
This doesn’t mean you shouldn’t keep checking your HTML validates - it is still one of the simplest ways to check for a bunch of knock-on effects from accessibility to rendering and styling.
As WCAG is mean to be backwards-compatible and this is the first time a criterion has been removed, it’s not sure what effect, if any, this will have on things like the ISO (which is still using WCAG 2.0 as a benchmark).
2.4.7 Focus Visible (A) has been updated
This criterion was rated AA under WCAG 2.1 but has been moved to A under 2.2
What are the new criteria?
2.4.11 Focus Appearance (AA)
This is the most wide-ranging change as it is likely to impact most websites and even challenges some of the more basic styling techniques used for focus indication.
There is already a criterion called Focus Visible, but the requirements for it are quite minimal:
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
There wasn’t any minimum requirements of what that indicator should look like - is a thin border ok? visible to who - someone with good eyesight?
This new criterion looks to pin that indicator down with a series of rules around what the indicator should looks like. It boils down to these rules:
- good contrast (3:1) against other states and adjacent colours
- a size equivalent to a 1px border around the element, or a 4px border on the shortest side of the element
There are however details of this criterion which are causing confusion in the community around how these values are calculated for specific use-cases. Also, how would this impact the standard application of a text-underline on focus? That underline is generally set to just 1px which is below the threshold for passing this criterion and places a lot of sites at risk of failing this straight away.
So at the moment this criterion is marked “At risk” but is unlikely to be changed at this stage so will either be implemented as it is or get pulled before publication. If it gets implemented expect a bit of confusion around how this should be tested and if something passes it or not.
Even if this criterion does not make it into the final release, it is worthwhile revisiting your product’s focus indicators to see if they really are as visible as they could be.
Alistair Campbell, part of the WCAG editorial team, has a good breakdown of the latest version.
Update: 22 March 2023 this looks to have been dropped from AA level to AAA level. This is a disappointing move as it leaves us without a clear definition of what visible actually means at the commonly used compliance levels of A and AA, despite Focus Visible still being a AA criterion.
Understanding Success Criterion 2.4.11: Focus Appearance
2.4.12 Focus Not Obscured (Minimum) (AA)
Still looking at improving how focus is handled in WCAG, this criterion ensures that after you have created a visible indicator, that you don’t then have something obscuring it entirely such as a non-modal dialog, a sticky navigation or cookie banner when it is focussed.
Think of when you tab down a page and the navigation stays fixed to the top of the browser window - we want to ensure the item with focus on the page is not covered by that navigation.
Understanding Success Criterion 2.4.12: Focus Not Obscured (Minimum)
2.4.13 Focus Not Obscured (Enhanced) (AAA)
This is the partner to the above criterion. Being the AAA version this is more strict and requires that no part of the focus indicator is obscured.
Understanding Success Criterion 2.4.13: Focus Not Obscured (Enhanced)
2.5.7 Dragging Movements (AA)
This criterion is designed to help users who have difficulty with precision actions or who have to use non-standard input methods (such as eye-tracking). If an interface component requires a user to use a dragging motion to complete an action, then there must be a way of completing the action without dragging using a single pointer (ie not multi-touch gestures).
An example might be dragging a 3D visualisation of something to see it from all angles. Having arrow buttons would allow a user to be able to accomplish the same.
Another example is being able to drag items in a list to sort them, but also being able to click on an item in the list and have arrows appear to allow the item to be moved up and down.
A partner to this criterion is the existing 2.1.1 Keyboard but it was found there are instances where keyboard equivalence does not always equate to single pointer equivalence so a separate criterion was needed.
For example think of a horizontally scrolling component. It can be swiped (multi-touch) and keyboard can access it (because of focusable items inside it), but users who use a head-pointer will not be able to scroll it. This criteria catches these cases which would otherwise fall outside WCAG.
This new criterion also helps cover off touch experiences more comprehensively - but remember people on mobiles might want to use an external keyboard and those on desktops might zoom in and trigger a mobile view. It’s often best to consider viewport and input modalities as unrelated.
Understanding Success Criterion 2.5.7: Dragging Movements
2.5.8 Target Size (Minimum) (AA)
Target size has been part of design best practice for a long time and is covered currently by WCAG 2.5.5 (AAA) which requires a target of at least 44px by 44px (which is what Apple and Google recommend for their mobile interfaces). This new criterion adds a new minimum requirement at the AA level of 24px by 24px. Because of the AA rating this now comes under many of the legal requirements of various countries.
The same exemptions apply to this criterion as apply to the AAA one:
- the target is inline text within other copy (such as a paragraph) - note stacked links in a list are not exempted
- the target size is essential for communicating information (for example map pins might need to be clustered to convey location)
- browser defaults - like some other criteria, if you don’t alter a browser’s interpretation of a control (such as a calendar widget) then this does not apply
- duplication - if another control which is compliant performs the same action as the non-complaint one means the non-compliant one is exempted as the user has the option to use the other control
But there is an additional one for this new criterion around spacing:
- spacing - a target can be under 24px as long as the space between it and the next target makes up the difference. So a 20px button can be next to another one as long as there is a 4px gap between them. This might seem odd as it makes it possible to make a tiny target, but this criterion is all about accuracy rather than perception - can the user action this target without hitting others by mistake.
Teams should still look to meet the AAA standard where possible (especially where the platform states it in their documentation as Apple and Google do), but this criterion does at least make everyone look to ensure they are doing the minimum.
Understanding Success Criterion 2.5.8: Target Size (Minimum)
3.2.6 Consistent Help (A)
In order to make interfaces more consistent and help users find help when they need it (often a stressful situation), where a site displays certain help features, these should be present in the same place in relation to other content, on each page.
The features this applies to are:
- human contact details - this can be important for certain users who may find it difficult to use other methods of assistance
- human contact details - email, phone number, opening hours
- human contact mechanism - non-automated chat, contact form, social media
- self-help options - FAQs, support pages
- fully-automated contact mechanism - chatbot
Chat interfaces are especially useful as they allow the user to retain the current context whilst interacting with the source of help and allow the user to use their own vocabulary rather than the site’s.
This doesn’t mean the site has to provide these options - just if they are that they are presented consistently.
As the user moves through the site those contact features should be in the same relative visual location so the user knows where to look. If the user changes the screen size then all pages should act in the same way in where the contact options end up.
Understanding Success Criterion 3.2.6: Consistent Help
3.3.7 Accessible Authentication (AA)
This criterion is designed to help users log into sites as smoothly as possible. Having to solve a puzzle, transcribe information (unless you can copy & paste) or remember usernames and passwords can be a real struggle for many users - these are classed as a cognitive function test.
Username and password fields which are marked up correctly (and don’t prevent copy & paste) can allow the browser or password managers to fill in the fields on behalf of the user which would then pass this criterion. Note personal information such as name, email address or phone number are not classed as a cognitive function test (though not allowing those to be auto-filled would fail WCAG 1.3.5 Identify Purpose).
Old-style bank authentication of the style “enter the 4th 6th and 8th characters from your password” would also fail this criteria as it requires transcription and does not support copy & paste or autocomplete.
reCaptcha are exempted because the objects displayed are classed as “familiar” objects (think traffic lights), despite there being obvious issues with many of the source images and names being pulled from the US. Note those old-style Captchas which had a deformed word you had to recognise would fail this because it is not a familiar object and requires transcribing.
This criteria also applies to 2-factor authentication (it’s no good having an accessible first step if you then have to solve a puzzle on your phone) and username and password recovery (an essential part of authentication).
Understanding Success Criterion 3.3.8: Accessible Authentication
3.3.8 Accessible Authentication (No Exception) (AAA)
This is a stricter version of the above. It removes the object exemption (and so the option for reCaptcha).
Understanding Success Criterion 3.3.8: Accessible Authentication (No Exception)
3.3.9 Redundant Entry (A)
On the face of it this is a simple criterion - don’t ask the user the same questions you already have the answers for, or at least tell them what they entered before so they can select it as an option. For example “you said your email address was x would you like to use that?“ rather than “enter your email address“ again.
What we are trying to avoid is the user having to enter the same data they already have and either getting a mismatch or having to use additional effort to enter or recall the data they previously entered.
Note - browser autocomplete is not a sufficient mechanism to pass this criterion.
Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select
However the definition of a process says also can run across different domains. This paragraph from the guidelines could have an impact:
so if a check-out process includes a 3rd party payment provider, that would be in scope
So if the payment provider were to ask for an address which the user had already entered as part of their checkout process, this must be passed through to the provider page.