School website accessibility checklist for district teams
Use this checklist to assign work across technology, communications, school offices, and service owners. It is a review aid—not a claim that checking every box proves legal compliance.
Published by ADAReporting · Sources checked September 26, 2026
Establish the test boundary
List each district and school domain, vendor platform, login-protected service, and mobile app. Record the tasks families and staff need to complete and the people who maintain them. A three-page preview or a single-domain report cannot stand in for that inventory.
Choose representative pages from different school templates and real transactions. Include an enrollment journey, an accommodation request, an event/calendar workflow, and a current document used to obtain a service. Repeat critical checks after template or platform changes.
Check pages and shared components
Navigate without a mouse and verify that focus is visible, ordered, and not trapped. Open the menu, expand controls, and return to the page. Check that a screen reader identifies links and buttons by a meaningful name and that headings describe the actual structure.
When an unnamed link appears on many pages, inspect its shared source. An image inside a link with an empty alternative can leave the link unnamed. The correct fix is an appropriate accessible name—not automatically replacing every link’s visible wording.
- Identify the page language and a meaningful page title.
- Review headings, landmarks, labels, instructions, contrast, and zoom/reflow.
- Check focus and announcements after opening menus, dialogs, and dynamic panels.
- Review image descriptions in the context where images are used, not as raw image files.
Test forms and school documents
For each essential form, submit valid and invalid data. Verify instructions, required fields, error identification, recovery, and success feedback. Do not assume that an automated form-label check proves the whole workflow works.
Review current policies, newsletters, applications, board materials, and meal or transportation documents. Start repairs in the editable source, then verify the exported PDF. Inspect reading order, heading hierarchy, table headers, links, and alternatives. OCR may make a scanned document searchable, but does not supply all accessibility structure.
Review media and external systems
Check captions for accuracy and synchronization, meaningful sounds, player controls, and keyboard operation. Determine whether important visual information needs audio description or another appropriate alternative. A caption-file URL alone is not evidence of caption quality.
Ask vendors for evidence tied to the actual product version and configured workflow. Track external enrollment, payment, transportation, and parent-service systems separately. A vendor statement should not replace testing the district’s real user journey.
Close a finding with evidence
Assign an owner, a repair action, and a retest date. Record whether the defect was a shared template, a content entry, or a vendor-controlled component. Keep a before-and-after example plus the task result.
Retest essential paths with keyboard and a screen reader, and publish a clear route for reporting barriers. Keep inaccessible content and unresolved exceptions visible in the project plan rather than declaring success from an empty automated error list.
Primary sources
Related guidance
Turn findings into a repair plan
Start with a small automated preview or review the scope and pricing for a full public-site report. Automated testing is not legal advice or certification of ADA compliance. Manual testing remains necessary.
