What this service covers
- Representative page selection
- Keyboard and screen-reader tasks
- Prioritized issue documentation
- Remediation support and retesting
Start with the task and the source
Start with the journeys families need: enrollment, menus, calendars, board information, and contact or service forms. Include representative templates and interactive states. A single home-page scan cannot describe a complete website or every vendor tool embedded within it.
What needs human attention
Automated tools identify some barriers consistently. Manual keyboard testing can reveal focus problems and unusable controls. Screen-reader review can help check the relationships and meaning conveyed by headings, labels, forms, and interactive components. Record the methods and scope used.
Make the next update easier
A useful issue log supports action. Record the location, reproduction steps, expected behavior, relevant WCAG criterion, and guidance for the team responsible for the fix. Retest the changed version and keep unresolved third-party issues visible for vendor follow-up.
Scope the work before setting the schedule
Agree on the inputs, document versions, accepted formats, complexity, review method, and output before work starts. Flag any required publishing dates, confidential material, or dependencies on a website vendor. A representative sample helps avoid assumptions about the rest of the backlog.
Pricing and next steps
This service is part of DistrictProof Web. Request a fixed quote after a sample review or begin with your public website inventory.
For the regulatory context, read the ADA Title II school district deadline guide. Your district and counsel determine the applicable obligations and exceptions.
Choose a sample that represents the district website
The test plan should include more than a list of popular URLs. Select shared templates and the states people encounter while completing a task: opening navigation, searching for a policy, selecting a calendar date, completing a form, and recovering from an error. Record which third-party systems appear along the way.
Include pages owned by different departments. Enrollment, nutrition, transportation, special programs, and the board office may use different content patterns even within one website. A representative sample helps separate a shared template defect from an issue in one page’s content.
A parent tries to find and complete a service request
The test starts at the district website, moves through navigation, opens the relevant instructions, and reaches the form. A keyboard user must be able to identify focus and operate the controls. A screen-reader review checks the names and relationships needed to understand the task. Any handoff to another provider is recorded as part of the journey.
Write findings that lead to a fix
A useful finding names the affected component, the tested page and state, the steps to reproduce the problem, its practical impact, and the relevant technical criterion. Screenshots can help locate the issue, while text instructions make it reproducible without relying on the screenshot. Group repeated component issues so the vendor can address their shared cause.
Prioritization should explain the barrier and the task affected. A district can then decide what to address first with its website team. A scanner’s numerical score is less useful than knowing that a family cannot reach the enrollment form or identify its required fields.
Separate district, platform, and third-party actions
Content owners can often update headings, link text, descriptions, and instructions. Shared navigation or component behavior may need the CMS vendor. Embedded forms, calendars, or payment services can require another provider. The issue log should identify the likely owner and a next action for each category.
Where direct fixes are included, agree on access, a review environment, approval, and release responsibilities. Where the work is advisory, the handoff should make implementation guidance clear. Neither model should leave the district guessing whether a reported issue has actually been corrected.
Retest the version that families will use
Retesting follows the original reproduction steps on the changed version and records the result. A shared component fix may warrant checks on several representative pages. A redesigned interaction may introduce a different issue, so the scope should account for changed behavior rather than simply removing an item from a list.
For a combined plan, connect website findings with document remediation and ongoing publishing support. The evidence record should make coverage understandable: what was tested, when, by which method, and what remains open.
Frequently asked questions
What do you need to scope the work?
A representative sample, the best available source files, the intended use, and your required publishing schedule. Website projects also need an agreed list of pages, templates, and tasks.
How is this priced?
We review complexity and scope before providing a fixed quote. Page counts alone do not describe the effort required for scans, tables, forms, or interactive components.
Will an automated checker be enough?
A checker can identify some issues, but a human review is needed for meaning, order, descriptions, and use. Evidence should identify both the tools and the manual coverage.
What will we receive?
Your agreement defines the returned files or issue log, review coverage, delivery schedule, and evidence record. Publication verification should reference the live version.