Can an automated scan prove a school website is accessible?
No. An automated scan can find some accessibility issues, but it cannot establish that every task works for every user. DistrictProof Web scopes automated and human review around selected pages and tasks, records the methods and findings, and defines fixes and retesting with the district and its website vendor.
Test the journeys that matter
Start with the home page, enrollment, calendars, menus, board pages, and contact or service forms. Select representative templates and key tasks instead of treating a single scanner score as the whole picture.
Combine tools with manual review
- Automated checks to identify machine-detectable issues
- Keyboard navigation, focus order, and visible focus review
- Headings, labels, error messages, and link purpose
- Screen-reader checks of agreed pages and tasks
- Captions, transcripts, and embedded tools reviewed within scope
An issue log your vendor can use
Each recorded issue should include the affected page or component, reproduction steps, the relevant WCAG criterion, impact, and practical fix guidance. Retesting should reference the updated version and the outcome.
Work with your existing platform
Keep your website vendor involved. Your scope can separate content changes, shared template fixes, and third-party issues that need vendor follow-up. Direct implementation depends on your CMS, permissions, and the agreed work.
Be clear about coverage
A test describes the pages, states, and methods covered on a particular date. It does not establish the status of every page or third-party system. Read how we record coverage and evidence.
District website accessibility is a task problem
Families visit a district website to do something: enroll a child, find a menu, understand a board decision, locate transportation information, or ask for help. The test plan should follow those tasks through the relevant pages, controls, documents, and third-party handoffs. A page-by-page issue count is useful only when the district can turn it into action.
We organize the scope around representative templates and agreed journeys. That makes it possible to see which barriers affect a shared component, which belong to one content page, and which need another vendor’s response. Your team gets a practical way to coordinate the work without replacing its existing platform.
| District team | Typical responsibility in a scoped project |
|---|---|
| Communications and content owners | Page wording, headings, document links, image descriptions, and content decisions. |
| Technology team | Access, release coordination, platform configuration, and system ownership. |
| Website or CMS vendor | Shared templates, navigation, widgets, and platform-level changes. |
| DistrictProof | Agreed testing, issue documentation, remediation support, and retesting. |
Make the remediation backlog usable
Findings should include a reproducible location and state, the task affected, the observed barrier, technical context, and guidance for resolving it. Repeated issues can be grouped by component. Open dependencies stay visible so the district knows what is waiting for a content owner, a platform change, or an external provider.
The scope also defines the implementation model. Some districts want a test and vendor-ready issue log. Others need support correcting content or templates where access permits. We agree on that division before work starts, along with approval and release responsibilities.
Connect the website and its documents
An accessible navigation path can still end at an unusable PDF. Document work can therefore be linked to the website review without making the two services inseparable. If a page points to several versions of the same form, the content owner should decide which is current before files are replaced.
Use Docs for document remediation, and consider HTML conversion for information better maintained as a page. The final evidence should say exactly which pages, documents, versions, and tasks were reviewed.
One shared navigation fix, several places to verify
A district’s navigation component appears across departmental pages. A vendor corrects its keyboard behavior. Retesting should verify the changed interaction in the agreed contexts and check that focus remains visible and predictable. A resolved issue on one isolated page should not silently stand in for all coverage.
Questions before you start
What determines the price?
Page count, document complexity, source quality, review coverage, and the delivery schedule determine the scope. We confirm these before quoting.
Can we start with a small project?
Yes. Begin by discussing a representative sample or a defined set of documents or website tasks. A focused first scope can help establish the ongoing workflow.
What does the evidence record show?
It identifies the tested file or page version, review date, method, coverage, and outcome. Automated checks, human review, and publication verification are separate states.
Agree on the handoff before work begins
Your quote identifies the included outputs, review method, delivery dates, district inputs, and treatment of later changes. Use the sample evidence report to discuss the record you expect, and the scoping worksheet (plain text) to prepare public examples and project requirements.