WCAG 2.2 for education software

Education software is now where much of FE happens. Learners enrol, check timetables, submit work, read feedback and ask for support through online systems. Staff record attendance, plan support and write reviews in them. If that software is hard to use with a screen reader, a keyboard, a magnifier or a tired brain, disabled learners and staff are shut out of things everyone else takes for granted.

This guide explains what WCAG 2.2 is, what changed from 2.1, how the UK rules apply, and how to test and buy education software that works for disabled people. It is aimed at digital, IT and procurement teams, and at inclusion leads who want to ask the right questions.

What is WCAG 2.2 and why does it matter in education?

The Web Content Accessibility Guidelines (WCAG) are the international standard for accessible web content, published by the World Wide Web Consortium (W3C). WCAG 2.2 is the current version. It became a W3C Recommendation in October 2023, and the latest edition is dated 12 December 2024.

WCAG is organised around four principles. Content must be:

• Perceivable: people can see, hear or otherwise perceive it, for example through text alternatives and captions
• Operable: people can use it with a keyboard, switch, voice or touch, with enough time
• Understandable: content and behaviour are clear and predictable, and errors are easy to fix
• Robust: it works with assistive technologies such as screen readers

Each guideline has testable success criteria at three levels: A, AA and AAA. Level AA is the usual target. For a short definition, see WCAG.

What is new in WCAG 2.2?

WCAG 2.2 adds nine success criteria and removes one. Everything else from WCAG 2.1 is essentially unchanged, so software that meets 2.2 also meets 2.1, apart from the removed criterion 4.1.1 Parsing, which W3C now treats as obsolete.

For FE, three of these stand out.

Accessible Authentication. Sign-in is the front door. A learner who cannot remember a complex password, or cannot copy a code because of dyslexia, may never get in. Allowing password managers and paste, offering single sign-on and avoiding puzzle-style checks all help.

Redundant Entry. Support request forms often ask for the same details again and again. Each repetition is a barrier for learners with fatigue, motor impairments or processing difficulties.

Consistent Help. Learners who need support most are least likely to hunt for it. A help link in the same place on every page is a simple fix.

What do the UK rules require?

Two sets of rules matter.

The Equality Act 2010 applies to all FE providers, as education providers and as employers. The duty to make reasonable adjustments in section 20 includes providing information in an accessible format where that is reasonable. Inaccessible software can put disabled learners and staff at a substantial disadvantage. For FE institutions, the duty is anticipatory: you should plan for disabled learners generally, not wait for each one to complain.

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply to websites and mobile apps of public sector bodies. Regulation 4 sets out exemptions, including schools and nurseries except for content relating to essential online administrative functions, and non-governmental organisations unless they provide essential public services or services for disabled people. GOV.UK guidance says covered websites and apps should meet WCAG 2.2 AA and publish an accessibility statement explaining how accessible they are, including any known issues.

The GOV.UK guidance also notes:

• intranets and extranets are covered, and older content needs to be made accessible when updated
• mobile apps for a defined group, such as employees or students, are not covered by the mobile app requirements
• content from third parties that you neither pay for, develop nor control is exempt

Whether the regulations apply to your organisation, and to which systems, is worth confirming with your own advisers. Many FE colleges publish accessibility statements on the basis that they do. Independent training providers are less likely to be covered, but the Equality Act still applies to them.

Does WCAG 2.2 AA make software accessible to everyone?

No. It is a strong baseline, not a guarantee. W3C itself notes that the guidelines do not address every user need, especially for people with cognitive and learning disabilities. Education software serves many learners with learning difficulties, autism, ADHD, acquired brain injury and mental health conditions. Beyond WCAG, look for:

• plain language, with a low reading age for learner-facing text
• clear, predictable layouts with one main task per screen
• the option to save and return, without time limits
• easy-read versions of important content, such as support plans
• error messages that say how to fix the problem
• no unnecessary animation, and respect for reduced motion settings
• works on mobile phones, which many learners use as their main device

Our guide to accessible teaching materials covers similar principles for documents and resources.

How should you test education software for accessibility?

Combine automated checks, manual checks and testing with disabled people.

1. Automated tools. Run a checker on key pages. These catch issues such as missing labels and low contrast quickly, but many WCAG criteria need human judgement, so automated tools alone cannot show conformance.
2. Keyboard only. Put the mouse away and complete the main tasks: sign in, find information, fill in a form, submit. Can you see where the focus is? Is it ever hidden?
3. Zoom and reflow. Zoom to 400% and check content reflows without horizontal scrolling.
4. Screen reader. Test the main tasks with at least one screen reader on desktop and one on mobile.
5. Cognitive walkthrough. Ask: is it clear what to do next? Are instructions plain? Is help always in the same place?
6. Disabled users. Ask learners and staff with different access needs to try the main tasks. Their findings are often the most valuable.

Focus on journeys, not pages. A learner asking for support needs every step to work: sign in, find the form, complete it, submit it and see what happens next.

What should you ask suppliers?

Accessibility is far cheaper to get right before you buy. Ask every supplier of learner-facing or staff-facing software:

• Which version and level of WCAG do you conform to, for which parts of the product?
• How was that tested, by whom, and when?
• Can we see your accessibility statement, including known issues and dates for fixes?
• Did disabled people take part in testing?
• How do you handle accessibility bugs reported by users, and how quickly?
• Do sign-in methods meet 3.3.8 Accessible Authentication, and do you support single sign-on?
• Is every drag-and-drop action available without dragging?
• Are learner-facing documents, such as plans or letters, produced in accessible formats?

Then test the answers yourself during a trial. Our guide to choosing learner support software covers the wider procurement process, and the accessible materials checklist is useful for documents the software produces.

Fictional example. A college trials two support request systems. Both suppliers say they meet WCAG 2.2 AA. In a keyboard test, the first system’s chat widget covers the submit button on smaller screens, so the focused button is hidden. In a session with three learners, one with dyslexia struggles with the second system’s sign-in because it blocks pasting a password. The college asks both suppliers for fix dates before deciding, and writes the fixes into the contract.

How does Inclusion Studio support this process?

Inclusion Studio is learner support software being built for FE colleges and apprenticeship providers in England, currently pre-pilot with a prototype using fictional learners. It targets WCAG 2.2 AA, and its accessibility features page describes the approach, including larger text and reduced motion settings in the prototype. Full assistive technology testing is still to come, so no conformance is claimed; our accessibility statement will set out what has been tested, any known issues and how to report a problem.