After over a year of the release of WCAG 2.2 what should you be doing as a government service? Ayesha one of our Accessibility Leads answers some key questions you may have for how to implement WCAG 2.2 if you haven't already started.
Overview:
What is WCAG?
Overview of the changes
What are the new guidelines?
Key questions on WCAG 2.2
Looking forward
Useful resources
What is WCAG?
The WCAG (Web Content Accessibility Guidelines) (opens in a new tab) are universal guidelines that are used by public bodies to ensure accessibility is built into digital services. The WCAG guidelines are broken down by levels:
Level A: Must do, basic requirements (legally required for public sector).
Level AA: Must do, removes further significant barriers (legally required for public sector).
Level AAA: Specialised support, most comprehensive.
Meeting the WCAG guidelines is one part of meeting legal accessibility guidelines as a government service (both public and internal users). Check out Piya’s article on government requirements (opens in new tab) from earlier in our accessibility series for details.
You can also see understanding accessibility requirements for public sector bodies (opens in new tab) for a comprehensive breakdown.
Overview of the changes
The latest official version of WCAG 2.2 was published on 5th October 2023. This replaces the previous version, 2.1, which was published in 2018. WCAG 2.2 builds on and is compatible with WCAG 2.1, with added requirements. One success criterion, 4.1.1 Parsing, was removed in WCAG 2.2 as it was deemed redundant. WCAG 2.2 also addresses aspects related to privacy and security in web content.
There are 9 further A, AA and AAA guidelines to be aware of including; focus management, dragging movements, target size, consistent help, redundant entry, and accessible authentication. 6 of the new criteria are A and AA level which are what government services are legally required to meet for WCAG 2.2, bringing the total of A and AA guidelines to 55.
You can see the full details of the changes on the W3 website for the WCAG 2.2 introduction (opens in new tab).
What are the new guidelines?
Level A and AA:
2.4.11 (AA): Focus Not Obscured (Minimum): focus states must not be entirely hidden.
2.5.7 (AA): Dragging Movements: functionality must not rely on dragging. Alternatives such as buttons for left and right should be provided.
2.5.8: Target Size (Minimum) (AA): there can only be one interactive target in a 24px by 24px area.
3.2.6: Consistent Help (A): help mechanisms must appear in the same place on each page.
A graphic of a good example of two screens next to each other, with the help function located in the same top right hand corner on both. 3.3.7: Redundant Entry (A): users must not be required to re-enter the same information, unless essential such as for security purposes. Provide an option to automate the input for the same information twice if required twice.
3.3.8: Accessible Authentication (AA): authentication must not require a cognitive test (exceptions for object recognition or personal content). For example, provide compatibility with a password manager so a user doesn't have to input or transfer information for authentication.
Level AAA:
2.4.12: Focus Not Obscured (Enhanced): focus states must not be hidden at all.
2.4.13: Focus Appearance: focus indicator must meet a contrast ratio of at least 3:1 and at least 2 px in thickness that goes around the item .
3.3.9: Accessible Authentication (Enhanced): authentication must not require a cognitive test, with no exceptions. For example, provide compatibility with a password manager so a user doesn't have to input or transfer information for authentication.
Key questions on WCAG 2.2
Q1: Does meeting WCAG 2.2 ‘break’ my accessibility progress?
A site that meets WCAG 2.2 will also meet 2.1 and 2.0.
Q2: When do I start building and testing for WCAG 2.2?
Testing your service against WCAG 2.2 should be incorporated as soon as possible if you haven't already started.
You should aim to conduct regular accessibility testing (manual, automated and against assistive technologies), so you can maintain an accurate understanding of how compliant your service is and prevent any surprises when it comes to a yearly audit.
Do not rely solely on an annual audit to accessibility test your service, as this is only a snapshot in time and does not reflect ongoing maintenance of accessibility. If it has been at least a year since your service was last audited, or it was audited against WCAG 2.1, you will need to conduct an audit again.
You should also continuously conduct usability testing to ensure your service is meeting the needs of real users, and not just WCAG.
Q3: Do I need to update my Accessibility Statement?
You should reassess your service for WCAG and other legislation compliance every year, and update your accessibility statement to reflect this. As it is over a year since WCAG 2.2 was released, all services should now be testing and updating their accessibility statement to the WCAG 2.2 guidelines.
Q4: When will GDS start monitoring?
The GDS Monitoring Team started testing sites against the new WCAG 2.2 success criteria from 5th October 2024.
Find out more information at changes to the public sector digital accessibility regulations (opens in new tab).
Q5: When will the GOV.UK Design system be updated?
The GOV UK Design System Team have reviewed WCAG 2.2 (opens in new tab) and updated the design system, and included these changes in the latest GOV.UK Frontend v5.0.0 (opens in new tab). They have also provided guidance on how to meet WCAG 2.2, and which components, pages and patterns will be affected.
Q6: How is my accessibility automated testing impacted?
You should continue to use automated tools such as pa11y and aXeCore to support testing in build pipelines. For aXeCore, you can tag which level you want your tests to run against, so make sure you add ‘wcag22’ to cover the new guidelines. Find out more at Axe-core 4.5: First WCAG 2.2 Support and More (opens in new tab). Semi-automated tools such as Wave and aXe can still also be used to pick up some accessibility issues.
Automated/semi-automated tools do not cover all WCAG 2.2 guidelines so it is important to continue to test manually, with assistive technology and with real users.
Looking forward
WCAG 3.0 (opens in new tab) is currently a Working Draft and aims to provide guidance to build for users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. WCAG 3.0 also aims to support a wider range of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices.
Content that conforms to WCAG 2.2 A and AA is expected to meet most of the minimum conformance level of this new standard but, since WCAG 3 includes additional tests and different scoring mechanics, additional work will be needed to reach full conformance.
Ensuring you factor in regular maintenance is paramount to keeping accessibility up to date. And remember, WCAG does not cover every scenario. Test with your users and conduct regular user research.
Useful resources
WCAG 2.2 and what it means for you (Craig Abbott) (opens in new tab)
Obligatory WCAG 2.2 Launch Post (Adrian Roselli (opens in new tab)
What WCAG 2.2 means for UK public sector websites and apps (GDS - YouTube) (opens in new tab)
Testing for WCAG 2.2 (Intopia - YouTube) (opens in a new tab)
WCAG 2.2 Explained: Everything You Need to Know about the Web Content Accessibility Guidelines 2.2 (opens in a new tab)
Contact information
If you have any questions about our accessibility services or you want to find out more about other services we provide at Solirius, please get in touch.
Kommentare