How to Implement WCAG 2.2 in Assessment Platforms: A Checklist for UK EdTech Leaders

From October 2024, UK public sector accessibility monitoring transitioned to WCAG 2.2 AA, establishing updated expectations for digital services, including assessment platforms used by schools, local authorities, and other organizations. This shift places particular emphasis on six new success criteria, which affect common assessment interactions, login flows, and support patterns. Platforms must also maintain an up‑to‑date accessibility statement reflecting outstanding issues and fixes.

Assessment teams need to understand how these criteria apply in practice. Addressing accessibility issues during development planning keeps launches on schedule and supports smoother procurement. This makes it important to review the interactions that make assessment platforms especially sensitive to accessibility checks.

What Makes Assessment Platforms Sensitive to Accessibility Checks

Assessment platforms involve complex user interactions. These include timed items, item players, drag‑and‑drop exercises, and hotspots. They also incorporate high‑stakes authentication and often require bespoke integrations, such as LTI or OneRoster. While these interactions differentiate the platform, they also increase the likelihood of triggering WCAG 2.2 audit checks.

The Government Digital Service (GDS) sends monitoring reports and typically requests updates after a 12‑week follow‑up before retesting. Platforms that plan remediation as part of their development roadmap avoid last‑minute fixes and mitigate risks to launches and procurement, as outlined in public sector accessibility monitoring guidance.

What Changed in WCAG 2.2

WCAG 2.2 introduces six new success criteria that directly affect how assessment platforms are designed and used. Each criterion addresses common accessibility challenges and guides product teams in creating more inclusive workflows.

Before diving into the new criteria, it is worth understanding what changed from WCAG 2.1 and why these updates were necessary.

WCAG 2.1, released in 2018, primarily focused on enhancing accessibility for mobile users and individuals with low vision or cognitive disabilities. However, as digital services evolved, new interaction patterns, such as drag‑and‑drop assessments, timed items, and multi‑step forms, became more common. These experiences introduced accessibility gaps that WCAG 2.1 did not fully cover.

WCAG 2.2, published by the W3C in October 2023, closes many of those gaps by shifting the emphasis from page‑level accessibility to interaction‑level accessibility. It ensures that every part of a user journey, from logging in to completing a test, remains perceivable, operable, and consistent for all users.

Six New Success Criteria

2.4.11 Focus Not Obscured (AA)

The keyboard focus indicator must remain visible at all times. In assessment platforms, this is critical when navigating item players or option lists. Sticky headers, timers, and floating navigation can obscure the keyboard focus. Platforms must make sure the user’s current position is always visible.

2.5.7 Dragging Movements (AA)

Any drag interaction, like ordering items or matching questions, must have a keyboard or single‑pointer alternative. This ensures that users who cannot perform drag gestures can still complete tasks using a clear, accessible method.

2.5.8 Target Size (Minimum) (AA)

All interactive elements must be at least 24×24 CSS pixels, or provide sufficient spacing. Tiny buttons, small icons, and hotspot areas in timed assessments often fail this test. Ensuring adequate size reduces accidental clicks and supports users with motor impairments.

3.2.6 Consistent Help (A)

Help features, such as “Need help?” links or guidance popovers, must appear consistently in the same location and order throughout a workflow. This prevents confusion and ensures users always know where to find assistance.

3.3.7 Redundant Entry (A)

Platforms should avoid asking users to re‑enter information they have already provided. Candidate IDs, school details, and other registration information should be prefilled. This avoids unnecessary re‑entry and reduces errors.

3.3.8 Accessible Authentication (Minimum) (AA)

Login and verification processes must not rely on cognitive tests. Platforms should support password managers and allow pasting of one‑time codes. They should also provide accessible authentication alternatives, such as passkeys or WebAuthn. This approach ensures all users can log in without barriers.

2.4.13 Focus Appearance (AAA) – Optional

Although AAA, this can further improve the visibility of the focus indicator, helping users track their position more easily.

These criteria provide the foundation for accessible assessment workflows. The next section explains how each one appears in real assessment platforms, with examples and practical patterns product teams can implement.

WCAG 2.1 vs WCAG 2.2: A Quick Comparison

You may be wondering how WCAG 2.2 differs from 2.1. The changes may seem minor on paper, but they have a strong impact in high-interaction environments such as assessments. The table below provides a quick comparison to show where the new version sets higher standards.

Understanding the differences is one thing; applying them in live assessment environments is another. The next section breaks down how each new criterion actually appears in assessment platforms and what patterns teams can adopt to stay compliant.

From Understanding to Action: Implementing WCAG 2.2 in Assessment Platforms

Implementing WCAG 2.2 effectively means translating the guidelines into measurable actions across design, development, and QA. Each criterion should be assigned a clear owner, a defined test method, and a documented step.

For assessment platforms, the goal is not just compliance, but predictability during audits and procurement reviews.

WCAG 2.2 Implementation Quick Checklist

Design Phase

• Map new criteria (Focus, Dragging, Target Size, Help, Redundant Entry, Authentication) to each page template and interaction type.
• Review component libraries to ensure focus indicators are visible and touch targets meet size requirements before beginning new builds.
• Include accessibility annotations in wireframes to guide developers early.

Development Phase

• Provide keyboard and pointer alternatives for all drag‑and‑drop and ordering interactions.
• Configure UI elements to meet the minimum 24×24 CSS pixel touch targets.
• Apply consistent placement for help links and support icons across workflows.
• Integrate authentication options that support autofill, password managers, and passkeys.

Testing & QA Phase

• Add automated checks for focus visibility, target size, and redundant entry in test suites.
• Conduct manual testing using screen readers and keyboard‑only navigation for timed assessments.
• Record conformance results using the WCAG 2.2 Quick Reference to support documentation.

Governance & Documentation

• Maintain a changelog mapping fixes to WCAG 2.2 criteria for each release.
• Update the accessibility statement quarterly to reflect current issues and planned remediation.
• Align QA outputs with the Accessibility Conformance Report (ACR) or VPAT format for procurement readiness.

This checklist helps teams move from awareness to operational compliance. Following this will reduce friction during audits and improve trust with education authorities and procurement evaluators.

After aligning design, development, and QA with WCAG 2.2, teams should document accessibility to meet UK procurement and public-sector requirements. This is where accessibility statements, VPATs, and ACRs connect the technical work with organisational accountability.

Accessibility Statements, VPATs, and ACRs: How They Fit Together

Under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, every UK public website or app must publish an accessibility statement. The statement explains how the service meets WCAG 2.2 AA standards, notes any existing non‑compliances, and provides a contact for feedback.

A Voluntary Product Accessibility Template (VPAT), developed by the Information Technology Industry Council (ITI), is an internationally recognized format for documenting a product’s accessibility conformance. In the UK, VPATs are typically used to document alignment with WCAG 2.2 and EN 301 549 standards. When completed for a specific product version, the VPAT serves as an Accessibility Conformance Report (ACR), which can be submitted during procurement or referenced in accessibility statements to demonstrate compliance.

While the legal obligation in the UK applies to the accessibility statement, many education technology buyers, especially those working with local authorities or universities, request a current ACR during procurement to validate compliance claims. Together, these documents demonstrate a product’s accessibility maturity:

• Accessibility Statement: Public‑facing declaration required by law.
• VPAT: Template used to evaluate conformance with accessibility standards.
• ACR: The finalized VPAT document, used in tenders and procurement due diligence.

Together, these documents help teams demonstrate accessibility maturity and prepare for both compliance and procurement requirements. Next, it is important to understand the risks of inaction and how to plan realistic timelines for remediation.

Risks of Inaction and Realistic Timelines

Failing to address issues from accessibility monitoring reports can create regulatory risks. The Government Digital Service (GDS) conducts periodic audits and may issue remediation reports requiring fixes within a 12‑week timeframe. If updates are not completed or communicated clearly, the matter could be escalated to UK enforcement bodies, such as the Equality and Human Rights Commission (EHRC) or the Equality Commission for Northern Ireland (ECNI).

Teams should treat the 12 weeks as both a compliance and trust window:

• Log and triage all accessibility issues from the monitoring report.
• Prioritize fixes to critical interaction points: login, assessment player, navigation.
• Update the accessibility statement to show resolved issues and those still in progress.

Even partial progress, if documented clearly, can prevent escalation and build confidence with regulators and procurement reviewers.

Practical Next Steps for Product Leaders

Product and compliance teams can stay ahead of WCAG 2.2 by embedding accessibility into regular product governance. Recommended steps include:

• Run a focused WCAG 2.2 AA audit targeting the six new criteria.
• Prioritize fixes for high‑impact user flows such as assessments, submissions, and logins.
• Update your accessibility statement to reflect new standards and testing outcomes.
• Prepare or refresh an ACR (VPAT) if required for active tenders or renewals.
• Schedule a review cadence to make sure audits and documentation updates align with major product releases.

For more information, review the accessibility regulations guidance.

Treat WCAG 2.2 as Product Value, Not Just Compliance

Meeting WCAG 2.2 AA is a framework for more usable and inclusive assessments. Each improvement, from focus visibility to authentication flow, reduces user frustration, lowers support tickets, and improves testing reliability under pressure.

By maintaining an accurate accessibility statement and a current ACR, product teams show buyers and regulators that accessibility is not a checkbox, but an ongoing commitment. For UK EdTech leaders, this is the moment to make accessibility a design standard. WCAG 2.2 is the new baseline for trust in digital learning experiences.