TL;DR

  • WCAG 2.2 AA is the practical target. It is the benchmark the UK public sector guidance points to, and it is a sensible build standard for any learning platform sold into the UK, US or Canada, even where a statute still names an older version.
  • The law differs by country. The UK relies on the Equality Act 2010 plus the public sector accessibility regulations. The US is moving towards a WCAG 2.1 AA requirement for public bodies under ADA Title II (dates now pushed back to 2027 and 2028). Ontario's AODA names WCAG 2.0 AA.
  • For a learning platform, the platform is only half the problem. Course content uploaded by hundreds of staff is usually where accessibility fails.
  • Accessibility is cheapest at design time. Retrofitting a live LMS, proctoring tool or virtual classroom is slower and riskier than building the patterns in from the start.

If you are an EdTech founder, a product owner at a college, or a university IT lead choosing or commissioning a learning platform, this guide explains what the rules require, what WCAG 2.2 changed, and what to put in your build and procurement process. It is general information, not legal advice. Check your own obligations with qualified counsel.

Why accessibility is now a buying criterion, not a nice-to-have

Learning platforms sit in an unusual position. A student who cannot operate the login page, the quiz timer or the video player cannot take part in the course at all. That is why accessibility questions now appear early in tenders from universities and colleges, usually as a request for a conformance statement against WCAG, a VPAT or an equivalent document.

Three pressures are converging:

  1. Regulation. UK public sector bodies must publish accessibility statements, and the US Department of Justice has adopted a technical standard for state and local government web content, which includes public universities and schools.
  2. Procurement. Institutions are expected to ask suppliers for accessibility information. Jisc advises UK education providers to "provide accessibility information for all the third party content and systems you have paid for" and to ask vendors to supply it.
  3. Product quality. Many of the fixes (keyboard operation, clear focus, larger touch targets, sensible error messages) improve the experience for everyone, including students on phones, on poor connections, or studying in a noisy room.

If your platform is sold into institutions, your customers inherit the legal risk and will push it down to you in contracts.

WCAG in plain English

The Web Content Accessibility Guidelines (WCAG) are published by the W3C. They are organised around four principles: content must be perceivable, operable, understandable and robust. Each guideline has testable success criteria at three conformance levels: A, AA and AAA. Laws and procurement documents almost always ask for Level AA.

WCAG 2.2 became a W3C Recommendation on 5 October 2023. According to the W3C, it adds nine success criteria on top of WCAG 2.1, and it removes one (4.1.1 Parsing, now treated as obsolete). Earlier criteria are otherwise essentially unchanged.

What is new in WCAG 2.2

The nine additions, with their levels as listed by the W3C, are:

CriterionLevelWhat it means for a learning platform
2.4.11 Focus Not Obscured (Minimum)AAA sticky header, cookie banner or chat widget must not completely hide the element a keyboard user has focused.
2.4.12 Focus Not Obscured (Enhanced)AAANo part of the focused element is hidden.
2.4.13 Focus AppearanceAAAThe focus indicator must be clearly visible.
2.5.7 Dragging MovementsAADrag-and-drop quiz items and kanban-style boards need a non-drag alternative, such as select and place.
2.5.8 Target Size (Minimum)AASmall buttons and close icons need enough size or spacing to tap reliably.
3.2.6 Consistent HelpAHelp links, chat or contact options appear in the same place across pages.
3.3.7 Redundant EntryADo not make students re-type information they already supplied in the same process.
3.3.8 Accessible Authentication (Minimum)AALogins must not depend on a cognitive test such as remembering a password with no way to paste or use a password manager.
3.3.9 Accessible Authentication (Enhanced)AAAA stricter version of the above.

Six of the nine sit at A or AA, which are the levels most laws and tenders reference: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. Those are the ones to build into your sprint planning first. The University of Leeds makes the same point in its guidance to staff, which refers to six new criteria to satisfy.

Authentication and dragging deserve particular attention in education. Students log in constantly, often on shared or locked-down devices, and many assessment and sequencing activities are built around dragging items into order.

Rules change, and what follows reflects sources checked at the time of writing. Treat it as a map, then confirm the detail for your own situation.

United Kingdom: Equality Act 2010 and the public sector regulations

Two layers apply in the UK.

The Equality Act 2010 is the general anti-discrimination law. In broad terms, education providers and many service providers must avoid discrimination on grounds of disability and must make reasonable adjustments. The duty is generally understood to be anticipatory, meaning you are expected to think ahead about the needs of disabled people rather than waiting for a complaint. The Act does not name WCAG, so conformance to WCAG 2.2 AA is best seen as strong evidence of reasonable effort rather than a legal safe harbour.

The public sector accessibility regulations are more specific. GOV.UK states that the technical standard for public sector websites and mobile apps is level AA of WCAG, and the Government Digital Service (GDS) guidance and Jisc's education guidance both refer to WCAG 2.2 AA. Jisc treats colleges and universities as in scope and notes that almost all internal and external content and systems accessed through a browser fall within the regulations. Public bodies must publish an accessibility statement, and Jisc suggests an institution may need more than one, covering for example the website, the virtual learning environment, paid-for third-party systems and any public mobile apps.

Monitoring is carried out by GDS, which reviews a sample of sites and apps. Where problems remain, reports can be passed to the Equality and Human Rights Commission in England, Scotland and Wales, or to the Equality Commission for Northern Ireland, for enforcement.

Two caveats from our research. First, the sources we read agree that WCAG 2.2 AA is the standard in the guidance but do not give a firm date from which it is legally required, and we did not read the regulation text itself, so confirm the exact wording before relying on it. Second, the regulations bind public sector bodies. A private EdTech vendor is not directly the regulated party, but its public-sector customers are, and they will require evidence from you.

For virtual learning environments, Jisc makes a useful distinction: there are two aspects, the platform itself and the content uploaded to it. Because many staff and students can upload content, "the quality can be hard to monitor". It recommends mandatory accessible templates, checklists and training. That advice applies just as well to a custom platform as to an off-the-shelf one.

United States: ADA Title II, with deadlines moved back

In April 2024 the US Department of Justice adopted a rule under Title II of the Americans with Disabilities Act requiring state and local government web content and mobile apps, including those of public educational institutions, to conform to WCAG 2.1 Level AA.

The original compliance dates were 24 April 2026 for entities serving populations of 50,000 or more and 26 April 2027 for smaller entities. In April 2026 the DOJ published an interim final rule extending them by a year. According to Campus Technology and EDUCAUSE, the new dates are:

  • 26 April 2027 for larger public entities, which includes public higher education institutions, and
  • 26 April 2028 for smaller public entities.

The standard itself (WCAG 2.1 AA) was retained. EDUCAUSE also reports that the Department of Health and Human Services extended its parallel Section 504 dates, which reach entities that receive HHS funding, including many colleges and universities. DOJ has said it plans further rulemaking, so expect the detail to keep moving.

Two points for vendors. The Title II rule applies to public entities, so a private EdTech company is not the direct subject. But a public university buying your platform will need it to meet WCAG 2.1 AA by the relevant date, and WCAG 2.2 AA conformance covers the earlier 2.1 criteria as well. The "extension is not an invitation to wait", as one analyst quoted by Campus Technology put it, because procurement cycles run ahead of compliance dates.

The position for private US institutions and private vendors under other parts of the ADA, and under Section 504, is a legal question that depends on the facts. Speak to counsel.

Canada: AODA in Ontario, and a patchwork elsewhere

Canada does not have a single rule covering all learning platforms. Two regimes come up most often.

Ontario (AODA). The Integrated Accessibility Standards Regulation applies to the broader public sector and to educational or training institutions. Per eCampus Ontario's toolkit and Deque's overview, publicly accessible websites must conform with WCAG 2.0 Level AA. Neither source mentions WCAG 2.2. Both are secondary sources and the eCampus page is dated, so confirm the current regulation text.

Federal and other provinces. The Accessible Canada Act covers federally regulated bodies and organisations with 10 or more employees in Canada; education is not named in Deque's summary of its scope. Manitoba and British Columbia have their own laws, which Deque lists as referencing WCAG 2.1 AA.

The practical reading for a vendor: if you build to WCAG 2.2 AA you will meet the Ontario 2.0 AA baseline and the newer provincial 2.1 AA baselines in one go, because the criteria are cumulative.

Where learning platforms usually fail

Accessibility audits of education software tend to find the same patterns. These are engineering observations rather than statistics, and your own audit will tell you which apply.

Video and live classes. Captions, transcripts and audio description for recorded lessons, plus a way for deaf students to follow live sessions. Media players need keyboard-operable controls and visible focus. A virtual classroom also needs accessible chat, breakout controls and screen-reader-friendly participant lists.

Quizzes and assessments. Timers are a common problem. Students who use assistive technology often need more time, so the platform should support per-student adjustments, pause options and clear warnings. Drag-and-drop question types need an alternative under WCAG 2.2's dragging criterion. Remote proctoring raises its own questions, since camera, eye-tracking or lock-down browser rules can exclude students with certain disabilities unless an alternative route exists.

Login and account recovery. WCAG 2.2's authentication criterion means no cognitive-function test as the only way in. Allow paste, password managers, passkeys or email links.

Dashboards and charts. Progress dashboards and analytics often rely on colour alone and mouse hover. Provide text equivalents, data tables and sufficient contrast.

Uploaded content. PDFs, slide decks and scanned readings uploaded by staff. This is rarely a code problem; it is a workflow problem. The platform can help by prompting for alt text, flagging untagged PDFs and offering accessible templates.

Third-party plug-ins. LTI tools, embedded video, and chat widgets bring their own accessibility behaviour. A platform that integrates dozens of tools is only as accessible as the weakest one in a student's journey.

A practical build process

You do not need a separate accessibility project. You need accessibility built into the work you already do.

1. Set the target and write it down

State "WCAG 2.2 Level AA" as an acceptance criterion in your definition of done, and record any exceptions with a reason and a plan. This also gives you the raw material for a conformance statement later.

2. Start from an accessible design system

Define colour contrast, focus styles, spacing and target sizes once, in shared components. If every button, modal and form field is accessible by default, individual feature teams do not have to relearn the rules each sprint.

3. Test in layers

  • Automated checks in the build pipeline catch missing labels, contrast failures and invalid ARIA. They find only part of the issues, so do not treat a clean automated report as conformance.
  • Keyboard-only testing of every key flow: log in, enrol, watch a video, submit an assignment, take a timed quiz.
  • Screen reader testing with at least one desktop and one mobile combination.
  • Testing with disabled students and staff, which surfaces problems that scripts and checklists cannot.

4. Plan for content, not just code

Give instructors tools to publish accessible material: heading structure in the editor, alt text prompts, caption upload for video, and warnings before publishing inaccessible files. Pair this with short training and a clear route for students to report barriers.

5. Keep a living accessibility statement

Document what conforms, what does not, and when you plan to fix it. UK public bodies must publish this, and Jisc advises listing the WCAG success criteria that cannot yet be met. A vendor-side equivalent such as a VPAT or conformance report speeds up institutional procurement.

6. Build in a feedback and remediation loop

Barriers will slip through. Make it easy to report them, triage by impact on a student's ability to complete a course, and fix the blocking ones fast.

Procurement checklist for institutions

If you are buying or commissioning a learning platform, ask suppliers:

  • Which WCAG version and level do you conform to, and where is the evidence?
  • Can you provide an accessibility conformance report or VPAT, dated and tied to a specific product version?
  • How do you test: automated, manual, assistive technology, and with disabled users?
  • How does the platform help instructors publish accessible content?
  • What do timed assessments, proctoring and drag-based activities do for students who need adjustments?
  • Which third-party tools are embedded, and what do you know about their accessibility?
  • What is your process and turnaround time for fixing reported barriers?
  • Will accessibility obligations and remediation be written into the contract?

Build, buy or extend?

Off-the-shelf platforms such as Moodle and Canvas have accessibility work behind them, but they still need configuration, theming and content governance, and any custom plug-in you add is your responsibility. A bespoke platform gives you control of the design system and the full student journey, but the accessibility burden lies with whoever builds it. Neither route removes the need for testing.

For a deeper look at the trade-offs, see our guide on custom learning platforms versus Moodle and Canvas, and our overview of integration with LTI and OneRoster, which is where many third-party accessibility surprises begin.

Where Syslabs fits

Syslabs builds custom software for education and other sectors, including learning platforms, virtual classroom tools, admissions systems and assessment workflows. On accessibility projects we typically help teams in three ways: scoping a WCAG 2.2 AA target and an audit plan, building accessible components and flows into the product, and setting up the testing and documentation that institutional buyers ask for. We do not provide legal advice, and we do not claim any particular certification. Scope and cost are set on a consultation once we understand your platform and markets.

Conclusion

Accessibility in EdTech is no longer one team's side project. The UK expects evidence, the US has set dates that institutions are already planning around, and Canadian provinces apply their own rules. Building to WCAG 2.2 AA, testing with real assistive technology, and giving instructors the tools to publish accessible content covers most of what these regimes are trying to achieve, and it makes the product better for every student.

Syslabs can help you scope an accessibility audit or build accessibility into a new or existing learning platform. Book a meeting and the booking page will show the available times in your own time zone.

Sources