Do accessibility overlay widgets work on an LMS?

“The widget’s been on since last spring, so we should be covered.”

That gets said with real relief, and I understand why. Somebody signs a purchase order, a developer pastes one line of JavaScript into the theme, an icon appears on every course page, and a problem the institution has avoided for years looks closed in an afternoon. Then a student who uses a screen reader complains about the gradebook, or a letter arrives from a firm that files a lot of these.

Buying an overlay is a reasonable mistake made by people acting in good faith. The marketing is confident, the price is low against a real audit, and nobody on the purchasing side has a way to test the claim. Accessibility is a precondition rather than a phase, which is why the shortcut tempts: the real work has no end date and the widget has a checkout button.

In short: No. Accessibility overlay widgets edit the page in the browser instead of fixing the code underneath, and they routinely conflict with the screen reader a student has already tuned to their own needs. What gets you to WCAG 2.2 AA is the markup and the uploaded documents.

How an overlay widget works

The category includes accessiBe, UserWay, EqualWeb and Accessibility.works, plus smaller entrants. AudioEye sells into the same market with a meaningfully different model, and I’ll come back to it.

The mechanism is the same across the category. You add one script tag site-wide, and on page load it reads the page as the browser assembled it and changes what it finds: raising contrast, generating alt text, adding ARIA labels to controls that lack them, binding a few keyboard shortcuts.

A coalition of disabled accessibility professionals has documented marketing from several of these products claiming WCAG 2.1 AA or ADA compliance outright, worth pausing on (more on that coalition below). Compliance isn’t a property a third-party script can assert on your behalf. Same shape as the FERPA question in the first piece in this series: a vendor sells you something supporting a defensible posture, and your institution still reaches the conclusion in writing.

Why an overlay cannot fix an LMS

Think about paint. A coat of paint changes what a room looks like, and there is nothing wrong with paint. It will not widen a doorway, and it will not put a stud behind drywall that never had one. The overlay works on the finished surface of the page. Accessibility is decided in the framing.

The trouble isn’t that the widget does nothing. It’s that it works on the layer above the one that failed. A div styled to look like a button is still not a button when a script paints a label onto it. A heading structure that jumps from level two to level five stays broken after ARIA goes over the top, and heading navigation is how most screen-reader users move through a long page. Injected ARIA also produces double announcements, contradictory roles, and accessible names that disagree with the visible text, and a screen reader believes the ARIA over the page.

Then there is a complaint that runs through disabled users’ testimony but rarely reaches procurement. A blind student arrives already carrying assistive technology, often NVDA, JAWS or VoiceOver, tuned over years to their own speech rate and verbosity. The overlay assumes that student has nothing and starts reformatting the page live to help. Picture wearing hearing aids fitted to your own audiogram at a restaurant, and the room responds by turning every ceiling speaker up. The intent is kind. The equipment you brought is now fighting the room.

Some failures are out of reach for any script running in the page. Auto-generated alt text comes from a model with no idea why the image was put in the lesson, so a diagram carrying the point of a module gets described as “chart,” which looks like the box was ticked. Captions need transcript data that exists nowhere on the page, tagged PDFs are a separate format the script never touches, and a keyboard trap is a focus bug that no page rewriting frees a student from.

None of this is a fringe position. The Overlay Fact Sheet is a public statement signed by a coalition of disabled accessibility professionals and the organizations they work in, saying plainly that overlays do not deliver compliance and can cause harm. Before a renewal, ask your vendor for a specific case where their widget held up as a defence in an actual complaint. A marketing claim of compliance doesn’t count, and if they can’t name one, that’s the answer.

Where automated accessibility tooling earns its budget

There is a category next door to this one, and conflating the two is how good tools get dismissed with the bad ones.

Automated scanners find problems and hand them to a human. A monitoring service built on axe-core, or your own build pipeline running the same engine on every deploy, flags a missing label, a contrast failure, an empty link. It fixes nothing by itself, and that is the feature: the output is a work queue for whoever owns the theme, and the change lands in source control where it stays fixed. Automated testing catches well under half of real WCAG failures, so it’s the floor of a program rather than one, and most institutions haven’t built the floor.

AudioEye sits in between, pairing automated detection with human remediation and ongoing monitoring, a different offer from a script claiming to be the fix. Its client-side injection layer still deserves hard questions at purchase, since fixes applied in the browser rather than in source carry the same conflict risk as anything else rewriting the page under a student’s assistive technology. Ask which fixes land in your code and which land at runtime, in the contract.

What actually gets an LMS to WCAG 2.2 AA

The unglamorous version, ordered by what breaks in course interfaces rather than by criterion number.

Semantic structure, before anything else. Course pages, gradebooks and quiz builders are frequently assembled from generic containers with CSS doing the work headings used to do. Visually it reads as a hierarchy. To a screen reader it is one undifferentiated block. That fix is a theme job, and it moves more students than anything else here.

Keyboard operation and focus. WCAG 2.2 added 2.5.7 Dragging Movements at Level AA: anything requiring a dragging motion needs an equivalent that works with a single pointer action. LMS platforms are full of drag interactions, reordering modules or dropping a file onto an assignment, many with no keyboard path. The same release added 2.4.11 Focus Not Obscured, reproducible in five minutes: tab down a long assignment-settings form on a page with a sticky header and watch the focused field slide underneath it.

Two small new criteria that quietly fail everywhere. 2.5.8 Target Size asks for 24 by 24 CSS pixels on interactive controls, which gradebook widgets and mobile icon rows regularly miss. 3.2.6 Consistent Help asks that support mechanisms appear in a consistent relative order across pages, and LMS platforms often place the help control differently for students than for instructors. Neither is expensive. Both need someone looking.

Quiz timers, a compliance issue and an accommodation issue at once. Criterion 2.2.1 Timing Adjustable predates 2.2 and is the one an LMS most often fails structurally: if a timed assessment can’t be turned off, adjusted or extended within documented exceptions, the platform has locked out students with cognitive and motor disabilities. Your disability services office is probably granting extended time on paper already; whether the platform delivers it per quiz without an administrator improvising is worth asking this week.

Colour and forms, the classics. Gradebook indicators carrying meaning in red, amber and green alone fail 1.4.1 Use of Colour, fixed with a word or shape alongside the hue. Form fields need labels programmatically tied to their inputs rather than placeholder text, errors announced rather than only shown in red, and required fields marked in more than one channel. The W3C’s WCAG 2.2 recommendation is more readable than its reputation suggests.

Are uploaded PDFs covered by LMS accessibility?

This is the gap I find most often. An LMS is a document delivery system wearing a web interface. Syllabi, readings, handouts and lecture slides arrive as uploaded PDFs and Word files, and the accessibility of the shell has no bearing on their contents. A perfectly conformant Canvas instance will serve four hundred untagged PDFs without complaint. Untagged means no heading structure, no defined reading order, no alt text on the figures, and no way for a screen reader to tell a data table from a paragraph. For a blind student the file opens and says almost nothing.

That isn’t a technology gap, it’s a training and procurement gap. The fix is faculty workflow: heading styles applied in Word and a tagged PDF on export, alt text written while the author still knows what the figure was for, and accessible HTML wherever the content never needed to be a document, plus a policy for legacy files, remediate on request within a stated turnaround and high-enrolment courses ahead of it.

Two checkers make this measurable. PAC (the PDF Accessibility Checker) is a free Windows tool for PDF/UA tagging, the closest thing the field has to a standard. Adobe Acrobat Pro’s built-in checker is less strict but already sits on faculty desktops, which counts for more. For a number to take to a dean, run either across thirty files from one department and report the pass rate, the kind of finding a site and content audit exists to produce before a complaint does.

What your LMS already gives you: Moodle, Canvas and Brightspace

Moodle ships an accessibility toolkit in recent core covering font size, contrast and a dyslexia-friendly font, and core keyboard navigation holds up reasonably well. The exposure is everything around core: plugins and custom themes vary enormously, nothing enforces a standard across them, and a site gets assembled from decent parts into something that fails.

Of the three, Canvas is the one I’d point to first. Instructure publishes VPATs (Voluntary Product Accessibility Templates, the standard vendor disclosure format), and Canvas integrates with Ally by Anthology, worth naming as the shape real remediation tooling takes. Ally scores instructor-uploaded content, shows the instructor what’s wrong with their own file, and walks them through fixing it, the inverse of the overlay pattern in every respect that matters.

Brightspace publishes a VPAT too, but leans on its own native tooling rather than Ally, D2L Lumi and an in-platform accessibility checker among them. Different approach, not automatically a worse one, but it means the Ally-versus-overlay contrast above doesn’t transfer directly. Conformance claims and publication dates move, so pull the current VPAT from the vendor rather than citing a level you read in a slide deck, including this one.

Platform	Native controls in core	Vendor disclosure	Course-content checking	What stays with the institution
Moodle	Font size, contrast, dyslexia-friendly font toggle; keyboard nav in core	No VPAT, open source	No native equivalent; third-party plugins vary	Plugin and theme choices, since nothing enforces a standard across them
Canvas	Core UI accessibility, publisher documents VPATs and ACRs	VPAT/ACR published	Ally by Anthology integration, scores and guides fixes on instructor-uploaded content	LTI-integrated third-party tools (courseware, proctoring) outside Instructure’s control
Brightspace	Core UI accessibility, native captioning and checker add-ons (D2L Lumi, Accessibility+)	VPAT published	Native tooling, not Ally	Same LTI gap as Canvas; verify native tooling covers what Ally would have caught

As of 2026-08-24. Conformance levels and product names change; confirm each vendor’s current VPAT before citing a specific claim.

All three share the same gap. Native accessibility covers the shell and core authoring tools, not instructor-uploaded content, and not the third-party tools bolted on through LTI (the standard that plugs external publisher courseware and proctoring software into an LMS), where a compliant Canvas instance still hands a student an inaccessible experience. Lockdown browsers used for timed testing have documented conflicts with screen readers, hard to discover at exam time.

Ally reports; enforcement stays yours. Buying it without a remediation workflow, named owners and a deadline buys a dashboard measuring a problem nobody is assigned to solve.

Does a CDN or edge layer help with accessibility? Mostly no

This is the piece in the series where the network layer has little to offer, and I’d rather say so than manufacture a use case. Cloudflare Workers can serve pre-tagged assets quickly, and that’s the end of the list: edge compute doesn’t fix semantic markup or focus order, because those live in the application.

Page speed does matter to disabled users, worth being precise about why. Slow loads and layout shift fall heaviest on people with cognitive and attention-related disabilities, and on switch-control users who queue input and wait through a page moving under them. That’s a usability argument supported by accessibility research; 2.2.1 Timing Adjustable, by contrast, governs session and quiz timers, and has nothing to do with page-load time.

What the law actually asks for

Ontario, under AODA. The Integrated Accessibility Standards Regulation requires WCAG 2.0 Level AA, excluding success criteria 1.2.4 and 1.2.5. Designated public-sector organizations, school boards and public colleges among them, are obligated regardless of size. Private and non-profit organizations with 50 or more employees hit the same bar on a deadline that passed 1 January 2021. Ontario’s legal floor is two versions behind current practice, so a board can be compliant today and still fail criteria a student meets on a phone. I keep a Canadian accessibility deadline lookup for sorting out which dates apply.

United States, under ADA Title II. The DOJ rule requires WCAG 2.1 Level AA for state and local government web and mobile content, covering public districts, colleges and universities, with compliance dates tiered by population size. Those dates have moved since the rule first published, so pull them from ada.gov directly rather than from this paragraph or any planning memo written earlier, the deadline that matters is whichever one is current the day you check.

Section 504, where federal money is involved. Institutions administering federal financial aid or running federal grant-funded programs are reached by Section 504 of the Rehabilitation Act, not Section 508, which governs federal agencies’ own technology and their direct contractors. Both reference WCAG 2.0 AA as a baseline following a 2018 refresh; whether that’s moved since is worth confirming against the standard directly.

Common questions

We already paid for a year of the widget. Should we rip it out today?
Not today necessarily, but stop counting it as a control. Read the contract for what it claims on your behalf, since some agreements assert compliance in your name, then test the site with a real screen reader, widget on and widget off. If pages get worse, that settles the renewal.

Does the widget at least help with a lawsuit?
The documented pattern runs the other way. What helps is a dated remediation plan with named owners and evidence of progress, because that is what demonstrates good faith when somebody asks.

Who should own this in a district?
Somebody with a budget line. In practice it lands with IT, the teaching and learning centre, or disability services, and fails when split across all three with no owner. The arrangement that works gives each group one clear piece: IT the platform and theme, the teaching centre faculty training, disability services the escalation path when a student reports a barrier.

Where to start on Monday

Open your own LMS, turn on the screen reader already built into your operating system, and try to reach the gradebook from the course home page using only the keyboard. Then open the three most recently uploaded PDFs in an active course and check whether they are tagged. Neither needs a consultant and both take an afternoon.

I keep an accessibility statement on my own site, mostly because publishing one means having to keep it true. Anyone can check it, including the student who was going to email you anyway.