WCAG 2.2 Compliance for University Websites: A Practical Checklist

TL;DR: University websites must meet WCAG 2.2 Level AA to satisfy Section 504 and the 2024 ADA Title II rule (compliance dates April 2026 for large jurisdictions, April 2027 for smaller ones). This checklist is organized by the things a campus actually publishes: the main marketing site, department and faculty pages, the course catalog, PDFs, lecture video captions, LMS-embedded content, and third-party tools you procure. Each section has concrete checkbox items mapped to specific WCAG success criteria. The hardest areas are decentralized faculty content, PDFs, and vendor platforms — handle those with training, remediation workflows, and VPAT review at procurement.

A university website is one of the largest, most fragmented digital properties any organization operates: a central marketing site, dozens of departmental microsites, thousands of faculty pages, a sprawling course catalog, a learning management system stuffed with documents, archives of lecture video, and a stack of procured third-party tools. Making all of it meet WCAG 2.2 Level AA — the standard that Section 504 and ADA Title II require of higher education — is daunting precisely because the work is spread across so many owners. With the ADA Title II 2024 final rule setting firm deadlines (April 24, 2026 for jurisdictions of 50,000+, April 26, 2027 for smaller ones), “we’ll get to it” is no longer a plan.

This checklist breaks the work down by the kind of content a campus publishes. It is mapped to specific WCAG 2.2 success criteria so you can hand each section to the right team. For a plain-language primer on the standard itself, see what WCAG means for government sites and our general WCAG 2.2 AA checklist. This guide is the higher-education-specific version.

How to Use This Checklist

WCAG 2.2 AA has 56 success criteria. Rather than march through all of them abstractly, this guide groups the most commonly failed criteria under the campus contexts where they actually break. Run each section against the corresponding property. Items reference the WCAG success criterion (e.g. SC 1.4.3) so your developers and content editors can look up the exact requirement.

A note on WCAG 2.2: it added nine new criteria over 2.1. The ones most relevant to universities are SC 2.4.11 Focus Not Obscured, SC 2.5.8 Target Size (Minimum) for mobile/touch, SC 3.3.7 Redundant Entry in multi-step forms (think course registration and applications), and SC 3.3.8 Accessible Authentication in your SSO and student portals. Our WCAG 2.2 vs 2.1 explainer covers all nine.

1. The Main Marketing & Admissions Site

The .edu homepage, admissions, programs, news, and events. Highest visibility, most likely to be tested first by OCR or a complainant.

• Every meaningful image has descriptive alt text; decorative images use alt="" (SC 1.1.1). Seals, leadership photos, and campus maps are meaningful. See fixing missing alt text.
• Color contrast is at least 4.5:1 for normal text and 3:1 for large text (SC 1.4.3). Brand palettes — especially light gray on white and color-on-color CTAs — routinely fail. See color contrast on government sites.
• The site is fully operable by keyboard alone — every link, menu, carousel, and modal (SC 2.1.1), with no keyboard traps (SC 2.1.2). See keyboard accessibility.
• A visible focus indicator is present on all interactive elements (SC 2.4.7) and is not hidden behind sticky headers or chat widgets (SC 2.4.11, new in 2.2).
• Pages have a logical heading structure — one <h1>, properly nested <h2>/<h3> (SC 1.3.1, SC 2.4.6).
• Every page has a descriptive, unique <title> (SC 2.4.2) and a correct lang attribute (SC 3.1.1).
• Text resizes to 200% without loss of content or function (SC 1.4.4) and reflows at 320px width without horizontal scrolling (SC 1.4.10).
• “Skip to main content” link is present and functional (SC 2.4.1).
• Auto-playing carousels and media can be paused, stopped, or hidden (SC 2.2.2).
• Touch targets are at least 24×24 CSS pixels (SC 2.5.8, new in 2.2) — critical for mobile-heavy prospective students.

2. Department & Faculty Pages

This is where decentralization bites. Hundreds of contributors, inconsistent training, legacy templates.

• Links have meaningful text — no bare “click here” or “read more” (SC 2.4.4). Faculty CVs and publication lists are repeat offenders.
• Headings are used for structure, not just to make text big (SC 1.3.1). Editors frequently bold-and-enlarge instead of using heading styles.
• Data tables (office hours, course schedules, grade scales) use real <th> headers, not layout tables (SC 1.3.1).
• Embedded content (Google Maps, YouTube, calendars) is keyboard accessible and has accessible names (SC 4.1.2).
• Contact forms have programmatically associated <label>s and clear error messages (SC 1.3.1, SC 3.3.1, SC 3.3.2).
• No information is conveyed by color alone — e.g. “required fields in red” must also have a text or symbol cue (SC 1.4.1).
• Faculty-uploaded documents follow the PDF checklist below.

Department pages are the strongest argument for governance over heroics. See managing accessibility across decentralized departments.

3. The Course Catalog

Catalogs are dense, table-heavy, frequently auto-generated from a student information system, and often a separate platform.

• Course listing tables have proper header cells and, where multi-dimensional, scope or headers attributes (SC 1.3.1).
• Prerequisites and cross-references are real, descriptive links, not “see above” (SC 2.4.4).
• Catalog search and filter controls are keyboard operable and announce results to screen readers (SC 2.1.1, SC 4.1.3 Status Messages).
• If the catalog is a generated PDF, it must pass the PDF checklist — a tagged, navigable document, not a print export.
• Term/year toggles and expandable sections expose their state (aria-expanded) to assistive technology (SC 4.1.2).
• Color-coded availability (open/closed/waitlisted) includes a text equivalent (SC 1.4.1).

4. PDFs and Documents

Course packets, syllabi, forms, policies, reports, accreditation documents. The single largest backlog on most campuses.

• No scanned-image PDFs without OCR — a photo of a page is unreadable to screen readers. Remediate with OCR to a tagged PDF or HTML.
• PDFs are tagged with a correct reading order and document structure (headings, lists, paragraphs).
• Images inside PDFs have alt text; decorative images are marked as artifacts.
• Tables in PDFs are tagged as tables with header rows, not loose text.
• The document has a title set in properties and a specified language.
• Fillable forms have labeled, tab-ordered fields that work with a screen reader.
• Color contrast within the document meets 4.5:1.
• A prioritization rule is in place: remediate actively-used documents first (current syllabi, live forms, financial-aid letters); archive or remediate-on-request for old material.

Full detail in our PDF accessibility guide. Because PDFs are produced continuously by faculty and staff, this is a process problem, not a one-time cleanup.

5. Video & Lecture Captions

Recorded lectures, promotional video, athletics, commencement, MOOC content.

• All prerecorded video with audio has accurate synchronized captions (SC 1.2.2). Auto-captions alone are generally not accurate enough to meet the standard — they must be reviewed and corrected, especially for technical terminology and names.
• Prerecorded video has audio description (or an equivalent) where visual content conveys information not in the audio track — slides, equations, demonstrations (SC 1.2.5).
• Live-streamed events with audio (lectures, town halls) have real-time captions (SC 1.2.4) — CART or automated-plus-monitored, depending on the stakes.
• A transcript is available for audio-only content like podcasts (SC 1.2.1).
• The video player itself is keyboard accessible and its controls have accessible names (SC 2.1.1, SC 4.1.2).
• Captions are not burned-in only when a selectable track is feasible, so users can adjust them.

See video captions and accessibility for caption-quality standards and workflow options.

6. LMS-Embedded Content

Canvas, Blackboard, Moodle, Brightspace. The LMS shell may be accessible; the content inside usually is not. This is the most-cited area in OCR investigations.

• Course documents (PDFs, slide decks, scanned readings) pass the PDF/document checklist. The LMS does not fix them.
• Embedded videos have captions and accessible players (Section 5 above).
• Quizzes and assessments are keyboard and screen-reader operable, including drag-and-drop and timed elements (SC 2.1.1, SC 2.2.1 Timing Adjustable for timed tests as an accommodation).
• Pages built in the LMS rich-text editor use real headings, lists, and link text — the same rules as web pages (SC 1.3.1, SC 2.4.4).
• Math and equations use MathML or accessible rendering, not images of equations without alt text.
• Third-party publisher tools and LTI integrations (Pearson, McGraw-Hill, Cengage, Top Hat) have current VPATs on file — they are procured platforms (see Section 7).
• Color and meaning in course design (e.g. modules color-coded by week) include text equivalents (SC 1.4.1).

Faculty create this content continuously and are not web developers, which is why LMS accessibility depends on training and templates more than on after-the-fact audits.

7. Third-Party Tools & Procured Platforms

Application portals, payment systems, housing, dining, SSO, library databases, event registration, chatbots. Vendor-hosted, but your responsibility under Section 504.

• Every procured platform has a current VPAT / Accessibility Conformance Report reviewed before purchase — not a marketing claim of “ADA compliant.” See VPATs in procurement.
• Contracts include accessibility conformance language and a remediation timeline for defects.
• SSO and student portal authentication doesn’t rely on a cognitive-function test with no accessible alternative (SC 3.3.8 Accessible Authentication, new in 2.2).
• Multi-step flows (applications, registration, payment) don’t force redundant re-entry of information already provided (SC 3.3.7 Redundant Entry, new in 2.2).
• Library databases and e-resources are evaluated for accessibility, with a documented accommodation process for resources that can’t be fixed quickly.
• Embedded vendor widgets (chat, scheduling, forms) are keyboard accessible and don’t trap focus or obscure it (SC 2.1.2, SC 2.4.11).
• An accessibility owner is named in every vendor relationship so defects have someone to escalate to.

The distinction between Section 508 and ADA matters here: a vendor’s Section 508 conformance, documented in a VPAT, is your evidence, but the obligation to provide accessible service is the institution’s.

Don’t Forget the Program-Level Pieces

Beyond individual content, OCR expects institutional infrastructure:

• A published accessibility statement with a way to request accommodations and report barriers. See writing an accessibility statement.
• A designated 504/ADA coordinator with real authority.
• A written, dated remediation plan with priorities and target dates — see building a remediation plan.
• Documented training for content editors and faculty.
• Continuous monitoring, not a single annual scan.

Why a Checklist Run Isn’t the Finish Line

Automated tools reliably catch a meaningful share of WCAG failures — missing alt text, contrast, form labels, heading structure — across thousands of pages in minutes, which is the only realistic way to cover a property this size. But many criteria (caption accuracy, meaningful alt text, logical reading order, “equally effective” access) require human judgment. The right model is automated testing for breadth and regression-catching, manual review for the criteria that need it, as our automated vs. manual testing guide explains.

And because a campus publishes new content every day across hundreds of owners, even a perfect checklist run goes stale within a semester. New PDFs, new faculty pages, new uncaptioned videos accumulate continuously.

WCAG 2.2 AA compliance for a university is less a project than an operating standard maintained across thousands of contributors and dozens of platforms. Running this checklist once gets you a baseline; keeping the score requires watching the site as it changes. Govzu continuously scans your central site, department pages, and catalog against WCAG 2.2 AA, surfacing new failures the day they’re published — so your team fixes regressions before they become a complaint, and your audit baseline doesn’t quietly erode between reviews.