WCAG 2.1 AA for Professors — A Plain English Guide

WCAG stands for Web Content Accessibility Guidelines. It's the standard your Ally score is based on. When your institution says "make your course accessible," they're really saying "make your course comply with WCAG." The full specification is over 100 pages of dense, technical language written by and for web developers. If you've tried to read it, you probably got about two paragraphs in before your eyes glazed over.

That's understandable. You teach biology, or history, or nursing — not front-end web development. So here's what WCAG actually says, translated into terms that make sense for someone who builds courses, not websites.

What WCAG is (and where it came from)

WCAG is published by the W3C (World Wide Web Consortium), the same international organization that maintains the standards behind the web itself. Think of WCAG as the accessibility rulebook for anything that lives on the internet — websites, web applications, and yes, your Canvas course.

The version that matters to you is WCAG 2.1, level AA. That's the version most universities require, the version the ADA references in legal guidance, and the version that Ally checks your content against. There are other versions (2.0, 2.2, and eventually 3.0), but 2.1 AA is the current standard at nearly every institution in the U.S. and Canada.

The entire standard is organized around four principles, sometimes remembered by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Every individual rule — called a "success criterion" — falls under one of these four categories. Let's walk through each one.

Perceivable — "Can everyone see or hear the content?"

This is the big one. Perceivable means that information can't be invisible to any user's senses. If someone can't see an image, there must be a text alternative. If someone can't hear a video, there must be captions. The content has to be available through more than one sensory channel.

For professors, the Perceivable principle covers the issues you'll encounter most often:

• Text alternatives for images (alt text). Every image that conveys meaning needs a written description so screen readers can communicate what the image shows. A photo of a cell dividing in your biology lecture needs alt text. A decorative border does not.
• Captions for video and audio. If you embed a video in your course, it needs captions. If you upload a podcast or audio lecture, it needs a transcript. Auto-generated captions from YouTube or Zoom are a good start but they're often inaccurate — especially with technical terminology — and may need editing.
• Content structure through headings, not just visual formatting. When you bold a line of text and increase the font size, it looks like a heading to sighted readers. But a screen reader doesn't know it's a heading unless you've actually tagged it as one using the heading dropdown in Canvas. Structure needs to be semantic, not just visual.
• Sufficient color contrast. Text must be readable against its background. WCAG specifies a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text (18px bold or 24px regular and above). Light gray text on a white background fails. Dark text on a cream background passes. Most of the time, if you're using Canvas's default styles, you're fine.
• Don't use color alone to convey meaning. If you highlight correct answers in green and wrong answers in red on a study guide, a colorblind student can't tell which is which. Color can reinforce meaning, but it can't be the only signal. Add a label, an icon, or bold text alongside the color.

If your Ally score is low, Perceivable is almost certainly where most of your issues live. This principle accounts for roughly 90% of the flags Ally generates in a typical Canvas course.

Operable — "Can everyone navigate and interact?"

Operable means that every user must be able to navigate your content and use any interactive elements, regardless of how they interact with their computer. Some people don't use a mouse. Some navigate entirely with a keyboard, or with a switch device, or with voice commands.

For a Canvas course, here's what this principle covers:

• Keyboard accessibility. Everything must be operable with a keyboard alone — no mouse required. This mostly applies to interactive content you embed, like third-party tools, simulations, or custom HTML widgets. Standard Canvas pages and quizzes already work with keyboards.
• Skip navigation links. Users who navigate by keyboard need a way to skip past repeated navigation menus to get to the main content. Canvas handles this for you at the LMS level.
• Descriptive page titles. Each page should have a title that describes what it contains. In Canvas, this means giving your pages and assignments meaningful names like "Week 3: Photosynthesis Lab" instead of "Page 1" or "Untitled."
• Visible focus indicators. When a keyboard user tabs through a page, there should be a visible outline showing which element is currently selected. Again, Canvas handles this in its own interface.

For most professors, the Operable principle is largely handled by Canvas itself. Where it becomes relevant is if you embed third-party interactive content — a custom HTML5 simulation, a drag-and-drop activity, or an embedded tool that requires mouse interaction. If you're using those, it's worth checking that they work with keyboard navigation.

Understandable — "Can everyone follow it?"

Understandable means the content and interface are clear and predictable. People shouldn't have to guess what a link does or how to navigate between sections.

• Language of the page is set. The HTML of your page should declare what language it's written in (e.g., English) so that screen readers know how to pronounce the words. If the language tag says English but your content is in Spanish, the screen reader will try to pronounce Spanish words with English phonetics — and the result is incomprehensible. In Canvas, the language is typically set at the course level and you don't need to do anything.
• Consistent navigation. Navigation elements should appear in the same place and work the same way across pages. Canvas's course menu handles this for you.
• Error identification in forms. If a student fills out a quiz or a form and makes an error, the error should be clearly identified in text (not just highlighted in red). Canvas quizzes handle this natively.
• Clear link text. Links should describe where they go. "Click here" and "read more" tell a screen reader user nothing. "Read the lab safety guidelines" tells them exactly what they'll get. This one is on you — Canvas can't fix your link text for you.

For most professors, the Understandable principle boils down to two things: make sure your course language setting is correct, and write descriptive link text instead of "click here."

Robust — "Does it work across assistive technologies?"

Robust means the content is built with clean, valid code that assistive technologies can reliably interpret. This is the most technical of the four principles and, for professors, the least relevant to your daily work.

• Valid HTML markup. The code behind your pages should follow web standards so that screen readers and other tools can parse it correctly.
• ARIA attributes used correctly. ARIA (Accessible Rich Internet Applications) is a set of code-level attributes that help screen readers understand complex interface components. If you don't know what ARIA is, you almost certainly don't need to worry about it.

For Canvas courses, the Robust principle is mostly handled by the LMS itself. Canvas generates the HTML. Canvas manages the ARIA attributes. Unless you're writing raw HTML in the Canvas editor (which most professors are not), this principle is largely taken care of for you.

What this means for your Canvas course specifically

Here's the practical takeaway: of those four principles, Perceivable is where you should focus your attention. That's where roughly 90% of Ally flags originate. The specific issues that affect most professors are:

1. Alt text on images. Every meaningful image needs a description.
2. Heading structure. Use actual heading tags, not bold text. Keep them in order (H2, then H3, then H4).
3. Tagged PDFs. Uploaded PDFs need an internal tag structure so screen readers can navigate them. Untagged PDFs score zero in Ally.
4. Color contrast. Make sure text is readable. Avoid light-colored text on light backgrounds.
5. Captions on videos. Any video content needs synchronized captions.

The Operable, Understandable, and Robust principles are important in the broader web, but in a Canvas course, the LMS handles most of those requirements for you. Your job is primarily Perceivable.

The difference between A, AA, and AAA

You may have noticed that WCAG comes with different conformance levels. Here's what they mean:

• Level A is the bare minimum. These are the most basic accessibility requirements — things like providing alt text for images and making sure content is available without relying on a single sense. If you fail Level A, your content has fundamental barriers.
• Level AA is the standard. This is what most institutions require, what Ally checks against, and what legal guidance references. It includes everything in Level A plus additional requirements like sufficient color contrast and more robust heading structure. This is your target.
• Level AAA is aspirational. It includes things like sign language interpretation for all video content and enhanced contrast ratios. Very few organizations aim for full AAA compliance, and the W3C itself acknowledges that AAA conformance across an entire site isn't always feasible. Don't worry about it.

When your institution says "WCAG 2.1 AA compliance," they're asking for Level A plus Level AA. That's the standard Ally measures and the standard FixAllyScore helps you meet.

The bottom line

WCAG sounds intimidating because it was written for web developers. But for a Canvas course, it boils down to a surprisingly short list: describe your images, structure your headings, tag your PDFs, make sure your text is readable, and caption your videos. That's the vast majority of what WCAG 2.1 AA requires of you as an instructor.

You don't need to read the 100-page spec. You don't need to learn HTML. You just need to fix the things Ally is flagging — and most of those things are faster to fix than you think.

If tagged PDFs are what's dragging your score down, FixAllyScore can handle those in seconds. It tags your documents to PDF/UA standards, generates alt text for embedded images, and runs entirely on your machine. The rest — headings, alt text in Canvas, link text — you can fix by hand in an afternoon.