Yes, Your Course PowerPoints Need to Be Accessible: Document Accessibility Under the ADA Title II Web Rule

When the Department of Justice finalized its ADA Title II web accessibility rule, much of the coverage focused on websites and mobile apps. That framing has lulled a lot of campus teams into a dangerous assumption: that the rule is the web team's problem. It isn't. The rule reaches deep into the file cabinet, and the learning management system.

“Web content” includes your documents

The rule defines web content broadly: text, images, sounds, videos, controls, animations, and conventional electronic documents. That last category explicitly captures PDFs, Microsoft Word files, Excel spreadsheets, and PowerPoint presentations. If a document is made available through a website, an app, or a course platform, it must conform to WCAG 2.1 Level AA by the compliance deadline, April 26, 2027 for most public universities, after the DOJ's April 2026 extension.

For public educational institutions, the rule goes a step further than many expected: password-protected course content is covered. The deck a professor uploads to the LMS for a 30-student seminar is held to the same standard as the university homepage. Textbook platforms, embedded quizzes, linked third-party readings: if it's part of the course, the institution is responsible for its accessibility, even when a vendor built it.

The “preexisting documents” exception won't save the syllabus

The rule does exempt conventional electronic documents created before the compliance date, but only if they are not currently used to apply for, gain access to, or participate in the entity's services or programs. Course materials in an active course are the textbook case of content that fails that test. A deck from 2018 that is still taught from in 2027 is, functionally, current content.

And even genuinely archived material carries an asterisk: if a student with a disability requests it, the institution must promptly provide an accessible version. The exception changes when you must remediate, not whether.

What an accessible PowerPoint actually requires

WCAG was written for web pages, but its success criteria translate directly to slides. The recurring failures, and the criteria they map to, look like this:

• Alternative text (WCAG 1.1.1). Every informative image, chart, and diagram needs a meaningful description; decorative elements should be marked decorative so screen readers skip them. Beware auto-generated junk alt text (“A picture containing text”): it fails the spirit and usually the letter.
• Slide titles (WCAG 2.4.2). Screen reader users navigate decks by title. Every slide needs one, and duplicates defeat navigation.
• Reading order (WCAG 1.3.2). Assistive tech reads shapes in the order they sit in the slide's internal structure, which often has nothing to do with visual layout. Reordering must be done carefully. Sloppy fixes can scramble or even lose content.
• Color contrast (WCAG 1.4.3). Body text needs 4.5:1 against its background; large text needs 3:1. Brand palettes fail this constantly.
• Color as the only signal (WCAG 1.4.1). “The red bars show declining enrollment” excludes colorblind readers unless a second cue exists.
• Tables, links, and language (WCAG 1.3.1, 2.4.4, 3.1.1). Header rows marked, link text descriptive rather than “click here,” and the document language set so screen readers choose the right pronunciation.

Manual remediation doesn't scale, and careless automation is worse

Remediating a single 40-slide deck by hand takes an experienced specialist one to several hours. Multiply by the thousands of decks in a typical department's back-catalog and the math collapses. That pressure is pushing institutions toward automation, which is the right instinct, with two hard requirements.

First, automation must never damage content. The worst possible outcome of remediation is a deck that reads well to a screen reader but lost a text box along the way. Tools should verify that every shape that went in comes out, and should flag genuinely ambiguous slides for a human instead of guessing.

Second, automation must be honest about what it changed and why. Small, provably safe contrast fixes (an achromatic snap to pure black or white, or a small same-hue nudge on a solid background) can be applied automatically as long as they are shown to you and always one click to undo. Anything bigger, or anything the tool isn't confident about, should wait for a human. The line isn't automate-versus-never; it's transparent-and-reversible versus silent.

This is the philosophy behind Accessibro: a free 17-check WCAG 2.1 AA scan of any .pptx, a clear look at what AI will fix and what needs a human before anything runs, AI-applied fixes for the invisible work (alt text, titles, reading order, language), small safe contrast fixes applied automatically and always undoable, human review for anything bigger, and no file retention, because course content is often sensitive or pre-publication. Scan a deck free and see what your back-catalog actually looks like.