What WCAG 2.2 AA Actually Requires From a Learning Platform

If your learning platform serves the public, a government, a university, or employees in the EU, accessibility has stopped being a nice-to-have. It is now a legal requirement with dates attached, and the deadlines are close enough to matter this year.

This post explains what "accessible" actually means for a learning platform, who has to comply and by when, where these platforms most often break, and the honest difference in cost between building accessibility in from the start and bolting it on after a complaint arrives. It is written for the people making the build-or-buy decision, not for a compliance officer, so we keep the spec-speak to a minimum. One note before we start: this is a practical guide, not legal advice. When money and deadlines are on the line, confirm your specific obligations with counsel.

The short version

The standard almost every law points at is WCAG, the Web Content Accessibility Guidelines, at conformance Level AA. WCAG has three levels: A is the floor, AA is the level regulators actually require, and AAA is a stretch target that is rarely mandated in full.

The current version is WCAG 2.2, published in late 2023. Most laws still name version 2.1 in their text, because the law was written before 2.2 shipped. The good news is that 2.2 is almost a complete superset of 2.1, so a platform built to WCAG 2.2 AA already covers the 2.1 AA that the law asks for, plus a handful of newer criteria that happen to matter a lot for learning products. Building to 2.2 AA is the sensible target. It satisfies today's rules and gets ahead of tomorrow's.

Accessibility is not a feature you add. It is a property of how every screen, form, and interaction is built. That single fact explains most of what follows, including why it is cheap early and expensive late.

Who has to comply, and by when

There is no single global rule. There are several, and more than one can apply to the same platform at once. Here are the ones that catch learning platforms most often.

A few things worth pulling out of that table.

The US public-sector deadline is the one with a countdown. The Department of Justice finalized a rule under ADA Title II that sets hard dates. Larger public entities have until April 2026, smaller ones until April 2027. If you sell to school districts, community colleges, or state universities, your buyers are now on that clock, which means their procurement teams are asking you about it today.

Private companies are not off the hook. In the US, there is no line in the ADA that says "your website must meet WCAG." Instead, courts have repeatedly treated the websites and apps of private businesses as covered by the ADA, and the practical standard they reach for is WCAG AA. The pressure here does not arrive as a deadline. It arrives as a demand letter from a law firm, and edtech is a frequent target because the audience includes students with disabilities.

The EU widened the net in June 2025. Public universities in the EU were already covered. The European Accessibility Act extends accessibility duties to a large slice of private digital services sold to consumers. If your platform sells course access online to people in the EU, do not assume you are outside its reach.

The pattern across all of these is the same standard, WCAG AA, arriving through different doors. Build to it once and you answer every one of them.

WCAG in plain language: the four things it asks

WCAG is organized around four principles. The easy way to remember them is the word POUR: Perceivable, Operable, Understandable, Robust. Stripped of the jargon, they ask four simple questions about every part of your platform.

• Perceivable. Can a person take the content in through more than one sense? A video needs captions for someone who cannot hear it and a transcript for someone using a screen reader. An image that carries meaning needs a text description.
• Operable. Can a person use it without a mouse? Every button, menu, quiz, and video control has to work with a keyboard alone, because many assistive tools speak to the page as if it were a keyboard.
• Understandable. Is it predictable and clear? Labels say what they mean, errors explain how to fix them, and the interface does not rearrange itself in surprising ways.
• Robust. Will it work with assistive technology? The page has to be built so that a screen reader can correctly announce what each control is, what it is called, and what state it is in.

Every specific WCAG rule is just one of these four questions made concrete. When you read a failure report later, you can almost always trace it back to one of them.

Where learning platforms actually break

Generic accessibility advice talks about websites. Learning platforms have their own recurring failure points, because they do things a marketing site never does: they play video, run timed quizzes, embed third-party content, and hold long interactive sessions. These are the spots that fail an audit again and again.

Video and audio lessons with no captions or transcript. This is the single most common failure in e-learning, and it is a clear Level A miss. Auto-generated captions are a start, but they are not accurate enough on their own to count for technical vocabulary, names, or accented speech.

Quiz timers that cannot be adjusted. A fixed countdown that a learner cannot extend or turn off fails a specific WCAG rule about timing. It also quietly discriminates against anyone who uses a screen reader or needs more time, since reading a question through assistive tech simply takes longer. Assessment is where accessibility and fairness meet, and it is worth reading alongside how you design the questions themselves in designing assessments that resist cheating.

Drag-and-drop questions that need a mouse. Matching and ordering questions are popular and are often built in a way that only works by dragging. If there is no keyboard alternative, a whole question type is closed to some learners. WCAG 2.2 added a rule specifically about this, requiring an alternative to dragging.

Status shown by color alone. A green dot for "complete" and a red one for "overdue" means nothing to a learner who cannot distinguish them. Color can reinforce a status, but it cannot be the only thing carrying it.

Low-contrast text on brand colors. Light gray text, or white text on a pale brand color, routinely fails the contrast ratio the standard requires. This is one of the most frequent findings on any automated scan, and it usually traces back to a design decision made without a contrast check.

Custom components with no name or role. Progress bars, accordions, tab strips, and modal dialogs built from plain page elements often say nothing useful to a screen reader. The learner hears "button" with no idea what it does, or does not hear the control at all. This is the Robust principle failing in practice.

Keyboard traps and invisible focus. If a learner can tab into your custom video player or a pop-up but cannot tab back out, they are stuck. And if the on-screen focus indicator is hidden by the design, a keyboard user cannot tell where they are on the page.

The content inside the content. This one is specific to learning platforms and easy to miss. Your platform can be perfectly accessible while the SCORM package, PDF workbook, or embedded slide deck inside it is not. A screen reader cannot read an untagged PDF or a SCORM module that was authored without accessibility in mind. Your compliance is only as strong as the least accessible thing you serve, and much of that is content, not code.

Login puzzles and tiny tap targets. WCAG 2.2 added rules that hit learning products directly: authentication should not force a person to solve a memory or puzzle test to log in, and interactive targets need to be large enough to hit reliably, which matters for the many learners on phones.

The honest cost: build it in, or bolt it on

Here is the part most vendors will not say plainly. Accessibility is inexpensive when it is part of how the platform is built, and expensive when it is a repair job.

The reason is structural. Accessibility lives inside your components. It is semantic markup, correct labels on every control, sensible focus handling, and captions in your content pipeline. When a team builds those habits in from the first component, the added cost is small and mostly a matter of discipline and testing. The work disappears into the normal cost of building the thing well.

Retrofitting is a different project. By the time a platform is live, the same button component might be reused on forty screens. Fixing it once fixes all forty, which sounds good until you realize you now have to re-test all forty, plus every custom quiz type, every modal, and every page whose focus order was never considered. You are not adding a feature. You are reopening the foundation of a system that is already serving real users, which is exactly the position you never want to negotiate a legal deadline from.

This is the same lesson that shows up in student-data security: the properties you have to bake into the architecture are cheap before launch and costly after. Accessibility and security both fail quietly for the same reason. They are invisible when they work, so they lose every prioritization fight to the feature the customer can see, right up until the day they very publicly do not. If you are weighing a build at all, accessibility belongs in the scope conversation from the start, which is part of what actually drives the price of an e-learning build.

How to check where you stand right now

You do not need a formal audit to get an honest read on your risk. Four passes will surface most of it.

1. Run an automated scan. Free tools like axe, WAVE, or the accessibility check in Lighthouse will flag contrast, missing labels, and structural problems in minutes. Treat the result as a floor, not a verdict. Automated tools reliably catch only about a third to a half of real issues, because a machine cannot judge whether your alt text is meaningful or your focus order makes sense.
2. Put the mouse away. Try to complete a full lesson and a full quiz using only the keyboard: Tab to move, Enter and Space to activate, arrow keys inside menus. If you get stuck, trapped, or lost, so will a keyboard user.
3. Turn on a screen reader. VoiceOver ships with every Mac and NVDA is a free download on Windows. Close your eyes and try to move through one lesson. This is uncomfortable the first time and more informative than any report.
4. Check the content layer separately. Open a representative SCORM module, a course PDF, and a video lesson, and ask whether each one is captioned, tagged, and navigable on its own. Remember that this layer can fail even when the platform around it passes.

If you are buying rather than building, there is a fifth step: ask the vendor for their VPAT, sometimes called an Accessibility Conformance Report. It is a standard document in which a vendor states, criterion by criterion, how well their product meets WCAG. A vendor who cannot produce one, or produces one that claims flawless conformance with no caveats, is telling you something either way.

What "compliant" does and does not buy you

Conformance is worth being clear-eyed about. Meeting WCAG 2.2 AA lowers your legal exposure and, more importantly, opens your platform to the roughly one in six people worldwide who live with a significant disability. That is a large share of any learning audience you were previously turning away at the door.

What conformance does not do is guarantee a good experience. A platform can technically pass every checkpoint and still be awkward to use with assistive technology. The checklist is the floor, not the ceiling. And conformance is not a certificate you earn once and file away. Every new feature, every content upload, and every third-party embed is a fresh chance to break it, which is why the teams who do this well treat accessibility as a standing part of how they build and review, not a one-time cleanup.

The takeaway is the same one that applies to security and to data. The properties that protect your users and your business are decisions you make in the architecture, early, while they are still cheap. Accessibility is one of those decisions. You either build it into the foundation now, or you pay to rebuild the foundation later, on someone else's deadline.