Most university accessibility offices are fluent in the language of WCAG. Success criteria, conformance levels, A versus AA versus AAA — this is the working vocabulary of the field. What is less clear, and what we get asked about most often, is the specific question: "When do we have to provide an audio alternative, what does WCAG 2.2 actually require us to do, and what satisfies that requirement in practice?"
This post is the answer we wish existed when we started building tools for this audience. It focuses on the parts of WCAG 2.2 that bear on audio alternatives for text content, translates them into concrete office-level practice, and walks through the common failure modes we see in institutions that are doing the work in good faith but missing one of the requirements.
We are not lawyers and this is not legal advice. It is a practitioner's reading of the standard, grounded in the guidance the W3C publishes and the way US and European accessibility frameworks reference it.
What WCAG 2.2 adds, and what it does not
WCAG 2.2 became a W3C Recommendation in October 2023. Most of the attention it got was about the nine new success criteria it introduced, which largely address cognitive, mobility, and low-vision needs. For the audio-alternatives question, WCAG 2.2 did not introduce a new criterion. It inherits the relevant rules from WCAG 2.1 and 2.0, and clarifies their application.
The criterion that matters most for course materials is not about audio per se. It is about perceivability. Specifically, Success Criterion 1.1.1 Non-text Content (Level A) requires that non-text content — images, graphs, complex visuals — has a text alternative. Once content has a text alternative, assistive technology, including text-to-speech, can render it into speech on the user's behalf.
This is the part most institutions get right. A syllabus has alt text on its logos. A lecture slide has alt text on its diagrams. A textbook is shipped as a tagged PDF. Where institutions struggle is not the alt text itself. It is the rest of the chain: whether the text alternatives are any good, whether the document is otherwise structured to support audio rendering, and whether students can actually get a usable audio version when they ask for one.
The criteria that actually govern audio-friendliness of text content
Pulling out the success criteria most relevant to whether a text document — a reading, a syllabus, a course packet — can be rendered as usable audio:
1.3.1 Info and Relationships (Level A). Structural information conveyed visually must be programmatically determinable. For a reading, this means heading styles applied as real headings, lists as real lists, tables as real tables with row and column headers, and paragraphs as real paragraphs. A text-to-speech tool reading a PDF where "headings" are just bold text cannot announce them as headings, which means a listener cannot navigate by section.
1.3.2 Meaningful Sequence (Level A). When content has a specific reading order, that order must be programmatically determinable. For multi-column layouts and sidebars, this is where most PDFs fail. The TTS version reads left-to-right, top-to-bottom, as the text is ordered in the file, which may or may not match the visual reading order a sighted reader would follow. Reading order is the most common audio-quality problem we see in practice.
2.4.6 Headings and Labels (Level AA). Headings and form labels describe topic or purpose. Even when the underlying markup is correct, a section called "Section 3" tells a listener nothing about what they are about to hear. Descriptive headings are a quality issue for sighted readers too — but they become essential when the listener cannot scan the page.
3.1.2 Language of Parts (Level AA). When a passage is in a different natural language from the surrounding text, that language must be identified. For multilingual academic content — a Spanish quotation in an English literature reading, a German philosophical term, a Latin legal phrase — this is what lets a screen reader or TTS engine switch to the right voice and pronunciation rules mid-passage. Without it, the engine mispronounces the foreign passage using English phonetics, and the listener's comprehension drops significantly.
4.1.2 Name, Role, Value (Level A). Interactive components must expose their accessible name and role programmatically. For course materials embedded in a learning management system, this means the LMS controls the TTS experience as much as the document does. An audio player inside Canvas or Moodle that does not expose its play button to assistive technology fails this criterion even if the underlying audio file is fine.
The pattern across all five: WCAG does not require that you provide pre-rendered audio files. It requires that the text content be structured such that students can use their own tools — screen readers, TTS apps, institution-provided readers — to generate speech on demand. Pre-rendered audio files are one way to meet a student's specific accommodation, but they are not what the standard mandates in the first instance.
The distinction between accommodation and general access
This distinction matters for how an accessibility office should think about audio alternatives:
General WCAG conformance — the course materials are structured such that any student with assistive technology can generate a usable audio version on their own. This is what the standard requires across the board, for every student regardless of whether they have a disability accommodation on file.
Specific accommodation — an individual student has an approved accommodation that includes audio versions of course materials, and the institution provides those files directly on a timely basis. This goes beyond WCAG and is typically driven by Section 504, the ADA, the Equality Act, or equivalent national frameworks.
Most accessibility offices provide both. The first is done by auditing documents upstream and working with faculty on document structure. The second is done reactively, through a ticket queue, with a tool that converts documents to audio and delivers files to students. A good office has a fast workflow for the second while investing in the first so the second queue gets shorter over time.
A practical checklist for audio-ready course materials
When we audit institutional documents for audio-readiness, we use a version of the following checklist. This is not a complete WCAG audit — it is specifically focused on whether text content will produce usable audio.
The document contains real, selectable text — not scanned images of text. If scanned, the file has been processed with OCR and saved with a text layer.
Headings use actual heading styles (Heading 1, Heading 2, etc.), not manual bold text. This applies to Word documents, Google Docs, and exported PDFs.
Lists are marked up as lists (bullet or numbered), not as lines that start with hyphens or asterisks.
Tables are used only for tabular data. If a table is being used to lay out the page visually (two columns of paragraphs side by side, for example), the layout is restructured to a single column or proper two-column document settings.
The reading order of the document matches the visual order when the document is viewed in Adobe Acrobat's reading-order tool (or equivalent). Multi-column layouts and floating text boxes are the common failure points.
Alt text exists on meaningful images. Decorative images are marked as decorative so TTS does not read their alt text aloud by mistake.
Passages in languages other than the document's primary language are tagged with the correct language. For Word, this is the Language setting on the selected text. For HTML, this is the lang attribute on the element.
Abbreviations and acronyms that a TTS engine will mispronounce are either spelled out on first use, or added to a pronunciation dictionary in your TTS tool.
Mathematical and scientific notation is either rendered in MathML (which modern TTS can handle) or includes a text alternative that reads naturally when spoken.
The audio-player interface — whether built into the LMS, a browser extension, or a dedicated app — is keyboard-navigable and exposes play/pause/speed controls to assistive technology.
A document that passes this checklist will produce audio that an attentive listener can follow on first play. A document that fails two or three of these will produce audio that requires the listener to have the original document open alongside, which largely defeats the purpose.
Where institutions tend to fail
Across the accessibility offices we work with, three patterns show up repeatedly.
Faculty document discipline is uneven. Some departments produce beautifully structured documents. Others produce PDFs exported from older Word files with manual formatting, no real headings, and two-column layouts chosen for visual reasons. The office knows which departments are which; addressing it is politically harder than it sounds. The highest-leverage intervention is a short document-structuring training offered once per semester, plus a template that departments can use for syllabi and course packets.
The audio-file queue is reactive and untracked. A student emails requesting an audio version of a reading, the office produces it, the file is delivered, and nothing is recorded except the email thread. Two semesters later, another student with a similar accommodation asks for the same file in the same course. Without a tracked library, the work is redone. A simple shared library of audio files, organized by course, pays for itself after one semester.
Vendor evaluation happens once, then never again. An office evaluates a TTS tool, commits to a procurement decision, and runs the same tool for five years while the field moves underneath them. The quality of synthesized voices in 2026 is meaningfully different from 2021. Neural voices, multilingual pronunciation, and document extraction from PDFs have all improved sharply. An annual check-in on whether the current tool is still the right choice is worth the hour of someone's time.
What we recommend for an office starting from scratch
If you are building an accessibility-office workflow for audio alternatives from zero, we would suggest this sequence:
Start with a document-structure audit of the top 20 most-requested courses. This tells you where the upstream quality issues are and where to invest in faculty training.
Pick one TTS tool and commit to it for at least one semester. The cost of context-switching between tools exceeds the benefit of using the best tool for each specific document type, at least until your workflow is mature.
Build a simple audio-file library, organized by course and term, shared with the office. Deduplicate requests. Regenerate files only when the source document changes.
Track metrics you can report on: average turnaround time from request to delivered audio, number of files produced per term, percent of top-50 courses with at least one pre-generated audio file available. These are the numbers that justify continued investment to institutional leadership.
Revisit your tool choice annually. The field moves quickly.
How NaturalTTS fits
We built NaturalTTS with this workflow in mind — document-to-audio as the core use case, with shared-workspace support for small accessibility teams, admin analytics for the reporting part above, and a 21-day EDU Pilot that is designed specifically for offices running a structured evaluation. If you are starting from scratch or revisiting a tool choice, those 21 days are enough time to run a real pilot through a real semester of requests.
If you are evaluating against incumbent vendors, our NaturalTTS vs ReadSpeaker comparison walks through how we line up against the established higher-ed player, and what the tradeoffs look like for a smaller accessibility office that does not need a full enterprise rollout.
WCAG 2.2 does not tell you which tool to buy, and it will not tell you how to run your office. What it does tell you is that the text content students receive from your institution must be structured such that audio alternatives — whether self-generated or office-provided — actually work. Getting the document structure right upstream makes every downstream tool choice better. That is the leverage point, and it is independent of any particular vendor.