# WCAG 2.1 Level AA

Canonical page: https://districtproof.io/resources/glossary/wcag-2-1-level-aa

The level of the Web Content Accessibility Guidelines specified in the DOJ Title II web rule. It includes Level A and Level AA success criteria.

By [Nilesh Gadekar, Founder](https://districtproof.io/about#founder) · Last reviewed November 4, 2026.

## How to use this term in a district project

Use the standard to define the technical scope of a review. A proposal should identify the content covered and the methods used to assess it. A result for selected pages or document versions does not automatically describe every item on a website. Ask how findings are connected to individual criteria and how the provider records remaining issues.

Illustrative district scenario

### A district example

A district requests a review of enrollment pages and their linked documents. The scope identifies those versions and tasks, while the findings explain relevant barriers and retest outcomes.

## A useful review question

Which content, criteria, methods, and versions does the review actually cover?

## Continue with a practical guide

[Explore the related DistrictProof guide or service](https://districtproof.io/solutions/web), or return to the [full accessibility glossary](https://districtproof.io/resources/glossary). Technical criteria and legal obligations should be checked against the applicable primary references and the agreed review scope.

## Use the standard to frame a testable scope

WCAG 2.1 Level AA refers to the Level A and Level AA success criteria in the W3C Web Content Accessibility Guidelines version 2.1. The DOJ Title II web rule names this technical standard for covered content. For district project planning, the standard reference should lead to specific review tasks and deliverables. A proposal can identify the pages, documents, user journeys and interface states included. This helps the district understand which material has been evaluated and which material remains outside that project, instead of treating a scanner score as a description of the entire website.

## District example: an enrollment journey

Imagine a fictional district reviewing the path from its enrollment homepage to a downloadable instruction pack and an online application. The project identifies each page, linked document and relevant form state. A keyboard user needs to reach and operate the controls. A screen-reader user needs meaningful headings, labels and errors. Someone enlarging text needs the layout to remain usable. The review records findings and corrections against the selected content. The district can then connect its acceptance decision with that actual enrollment journey, while maintaining a separate inventory of other services and documents still requiring attention.

## Combine automated and human methods

Automated tools are useful for identifying machine-detectable problems and repeating checks after changes. Human review examines meaning and interaction in the agreed tasks. The project record should identify the tools, browsers, assistive technology, date and reviewed versions. A screen-reader task might involve finding a heading, understanding a table and recovering from a form error. A keyboard task might involve opening a menu and continuing through the page without losing focus. Keep reproduction steps specific so the website vendor or content owner can address the finding and another reviewer can understand the retest.

## Keep document work connected to the website

A school website contains more than its shared templates. Menus, board packets, notices and program forms can be published as documents with their own structures and update patterns. The document owner needs a source and version process; the website publisher needs a clear handoff. Agree which returned files require publication verification and who checks the public locations. A project can also identify content that would be easier to maintain as a web page. That decision should follow the actual public task, the district’s authoring capacity and its records needs.

## Make the report useful for the next release

A useful report identifies scope, criteria, methods, findings, corrected versions and open actions. It should make clear who owns an unresolved content, platform or third-party issue. After a correction, record the retest outcome rather than simply removing the finding from view. New templates, exports and application releases can introduce changes, so maintenance should have an owner and a review routine. Use the district’s current website and representative files when discussing a quote. The standard helps define the technical review; the evidence record explains the specific work performed and the next publishing responsibilities.