What is the best way to conduct a district-wide edtech accessibility audit for students with disabilities in 2027?

What a district-wide edtech accessibility audit actually is

An edtech accessibility audit is a structured inventory-plus-evaluation exercise that answers three questions: what digital tools do students actually use, can students with disabilities use them independently, and what is the district legally and educationally obligated to do about the gaps. It is not a single scan or a vendor questionnaire. A defensible audit combines four evidence streams — an accurate tool inventory, automated scanning, manual expert testing, and lived-experience testing by assistive technology users — and produces a remediation plan with owners and dates.

The scope is wider than most districts expect. The obvious targets are the learning management system, the student information system's parent and student portals, and the two or three core instructional platforms. The long tail is where audits fail: single-subject licenses bought with building-level funds, teacher-selected free tools, third-party content embedded inside the LMS, PDFs uploaded by staff, district-produced video, the athletics registration site, the food services payment portal, and the parent communication app. In a mid-size district it is common to discover several hundred distinct web properties and applications touching students, with a meaningful fraction never reviewed by anyone in technology or special education.

The legal frame changed materially in the United States when the Department of Justice issued its 2024 rule under Title II of the Americans with Disabilities Act, setting WCAG 2.1 Level AA as the technical standard for web content and mobile apps operated by public entities, including public school districts. Compliance deadlines under that rule fall in April 2026 for public entities with populations of 50,000 or more and April 2027 for smaller entities and special district governments. Section 504 of the Rehabilitation Act and Section 508 obligations for federally funded materials sit alongside it, and the Office for Civil Rights has a long history of resolution agreements with districts over inaccessible websites and instructional technology. By 2027, a district that cannot produce evidence of a systematic audit is in a weak position on both the compliance and the educational-equity side.

The educational stake is larger than the legal one. When a math platform's practice problems are unreadable by a screen reader, a blind student either waits for a paraprofessional to read every item aloud or falls behind. When a video library lacks accurate captions, deaf and hard-of-hearing students get a degraded version of the same lesson, and so do English learners and students in noisy environments. When a quiz platform requires precise drag-and-drop with a mouse, students with motor disabilities are locked out of demonstrating what they know. Accessibility failures in edtech are not cosmetic; they change what a student is able to learn and what the district is able to observe about that learning. That framing matters when you ask a school board for the budget.

There is a second, quieter argument worth making internally. Accessibility work surfaces general quality problems. Tools that fail keyboard navigation usually also have brittle interfaces that frustrate substitutes and new teachers. Platforms without proper heading structure tend to be the ones nobody can navigate on a phone. Districts that run a serious audit routinely end up consolidating overlapping licenses and cutting spend, because the inventory step reveals that four different tools are doing the same job in three different buildings.

The step-by-step process, from inventory through remediation

Start with the inventory, and do not start with a survey. Surveys undercount by wide margins because teachers forget the tools they use weekly and never think to mention embedded third-party content. Pull the real data instead. Single sign-on logs from Google Workspace, Microsoft Entra, ClassLink, or Clever give you actual application usage with counts. Network or DNS logs from the filtering appliance catch tools that bypass SSO. Purchasing and accounts payable records catch paid tools that never appear in either. Rostering integrations reveal what is receiving student data. Merge those four sources, deduplicate, and you have a defensible list. Then add manual entries for the district website, the SIS portals, district-produced PDFs and video, and any custom-built applications.

Next, tier the inventory by student impact rather than alphabetically. A workable tiering: Tier 1 is anything every student or every student in a grade band must use — the LMS, the SIS portal, the district website, the primary reading and math platforms, the state assessment practice environment. Tier 2 is course-required tools used by hundreds of students, or any tool used in a special education or related-services context. Tier 3 is optional, supplemental, or single-classroom. Tier 1 gets the full treatment. Tier 3 gets automated scanning and a vendor documentation check unless a student need escalates it, which happens often — a Tier 3 tool used by one student who relies on a screen reader is functionally Tier 1 for that student's education.

Then run the evaluation itself in layers. Automated scanning with tools built on the axe-core engine, Google Lighthouse, WAVE, or Pa11y catches roughly a quarter to a third of WCAG failures — missing alternative text, insufficient color contrast, missing form labels, improper heading order, missing page language, duplicate IDs. It is cheap, it runs on a schedule, and it is the right first pass across a broad inventory. It is also the source of the most common audit mistake, which is treating a clean automated scan as a passing grade. Automated tools cannot judge whether alternative text is meaningful, whether the reading order makes sense, whether a custom widget announces its state correctly, or whether an error message is actually reachable.

Manual expert testing is layer two. For each Tier 1 platform, walk the core student task flows — log in, find the assignment, read the content, produce a response, submit it, read the feedback — using only a keyboard, then with a screen reader, then at 200 and 400 percent zoom, then with a Windows high contrast theme, then with the operating system's reduced-motion setting on. Use the assistive technology your students actually use, which in most districts means NVDA or JAWS on Windows, VoiceOver on iPadOS and macOS, TalkBack on Android, plus whatever specialized AAC or switch access hardware is in your buildings. Test on the devices students have, not on a technology director's laptop.

Layer three is testing with students and staff who use assistive technology daily. This is the layer districts skip and the layer that produces the findings that matter. A proficient screen reader user will find in ten minutes what a checklist misses in a week, because they know what a well-built interface sounds like. Structure it carefully: get informed consent, compensate adult testers, keep student sessions short and task-based, never frame it as a test of the student, and have a teacher of the visually impaired, a teacher of the deaf, or an assistive technology specialist facilitate. The findings from this layer should carry the most weight in your severity rankings.

Layer four is documentation review. Ask every vendor for a current Accessibility Conformance Report based on the VPAT 2.5 template, and read it critically. Check the date, the version of the product it covers, whether it was produced by a qualified third party or self-attested, and whether the "supports" claims are hedged with remarks that quietly describe failures. A conformance report is a claim, not evidence. Where your own testing contradicts the report, say so in writing to the vendor — that written record is what gives you leverage at renewal and protects the district if a complaint is filed.

Finally, convert findings into a remediation plan that a superintendent can read. Each finding needs a severity, a student-impact statement in plain language, an owner, a target date, and an interim accommodation if the fix is not immediate. Severity should be driven by whether the issue blocks a task entirely, degrades it, or merely annoys — a blocker on a login screen outranks a contrast failure on a marketing page every time. Publish an accessibility statement and a feedback mechanism, and keep them current; both are expected practice and both are the first things an investigator looks for.

Costs, timelines, and what the work realistically takes

Budget honestly, because underfunding this work is what turns an audit into shelf-ware. There are four cost buckets: staff time, tooling, external expertise, and remediation.

Staff time is the largest and least visible. The inventory step alone runs two to six weeks of part-time effort in a district of any size, mostly spent reconciling SSO logs against purchasing records and chasing down who owns a tool nobody remembers buying. Manual testing of one substantial platform's core flows takes a trained tester roughly one to three days depending on how many distinct task paths students use. Multiply that by a Tier 1 list that typically runs eight to twenty platforms and the testing phase alone is a quarter's work for one dedicated person, or a semester spread across a committee.

Tooling costs vary widely by model. Open-source options — axe-core, Pa11y, Lighthouse — are free and can be wired into a scheduled job that crawls your public sites weekly. Commercial monitoring platforms price by page count or domain and can climb quickly if you point them at a large district website plus every subdomain. Screen reader software is a mixed picture: NVDA and VoiceOver and TalkBack cost nothing, JAWS is a paid license, and you need at least one JAWS seat because it remains widely used and behaves differently from NVDA on complex widgets. Budget for the assistive hardware your students use as well, since testing on a simulator is not the same as testing on the device.

External expertise is where districts most often under-invest and then regret it. A third-party accessibility firm doing a genuine expert review of a handful of core platforms is a meaningful engagement, not a small purchase, and the number scales with the number of platforms and the depth of the task flows. The alternative is building internal capacity, which is slower but compounds: send an assistive technology specialist and a web developer through structured training, and consider a professional certification track such as the credentials offered by the International Association of Accessibility Professionals. Many districts land on a hybrid — external experts for the initial baseline on Tier 1 systems, internal staff for ongoing monitoring and for Tier 2 and 3.

Remediation cost is the wild card, because most of it is not yours to pay. If a vendor's platform fails, the fix is the vendor's engineering work and your job is contractual pressure. If your own website, your own PDFs, or your own video are the problem, the cost lands squarely on you. Document remediation is frequently the biggest single line item nobody planned for: a district with thousands of untagged PDFs on its site faces either a remediation vendor engagement, an internal tagging effort, or a decision to convert the content to accessible HTML instead. Captioning district-produced video is similar — automatic speech recognition alone does not meet the standard, so budget for human review of machine captions at minimum.

On timelines, a realistic first-cycle plan for a mid-size district runs about a school year. Roughly: four to six weeks for inventory and tiering; four to six weeks to stand up automated scanning and get a baseline; eight to twelve weeks for manual and assistive-technology-user testing on Tier 1; four weeks to write findings, severity rankings, and the remediation plan; then a rolling remediation phase measured in quarters rather than weeks because vendor release cycles are slow. Plan the calendar around the school year — do not schedule student testing sessions in the first three weeks of school, during state testing windows, or in the last two weeks of a term.

After the first cycle, the work should shift from project to process. Automated scans run continuously. Manual spot-checks happen each semester and after any major platform release. The full deep review of a given Tier 1 platform repeats every two to three years or whenever the vendor ships a significant redesign. New tools get reviewed before purchase, not after, which is by far the cheapest point in the lifecycle to catch a problem.

Where districts get this wrong

The most common failure is auditing the district website and calling it an edtech audit. The public website matters, and it is usually the first thing a complaint names, but students spend their instructional day inside the LMS and a handful of platforms behind a login. Automated crawlers cannot reach authenticated content, which is exactly why authenticated content goes unexamined for years. Any audit plan that cannot describe how it tests behind the login wall is incomplete.

The second failure is trusting a VPAT without verification. Conformance reports are self-selected documents, often written by a vendor's marketing or compliance function, sometimes years old, and sometimes describing a product version you are not running. A report that says a criterion is "supported with exceptions" is telling you something important in the remarks column, and the remarks are where the real information lives. Read them. Then test the two or three claims that matter most for your students and see whether they hold.

Third, districts confuse an accessibility scan score with accessibility. A dashboard showing 96 percent compliance is measuring the subset of criteria a machine can check on the pages it could reach. It says nothing about whether a screen reader user can complete an assignment. Publishing that number to a board as evidence of accessibility is a mistake you will have to walk back.

Fourth, remediation plans get written without owners or dates, which means they are wish lists. Every finding needs a name attached and a date, and someone has to review the list on a recurring cadence. Districts that succeed usually put this on an existing governance body — a technology steering committee or an accessibility task force with representation from technology, special education, curriculum, communications, and legal — and give it a standing agenda item.

Fifth, the audit runs entirely inside the technology department. Technology can test, but it cannot decide what accommodations are appropriate, cannot speak to a student's IEP or 504 plan, and cannot change a curriculum adoption. Special education leadership, teachers of students with visual and hearing impairments, assistive technology specialists, and curriculum directors all have to be in the room. Where the audit finds a platform that a specific student cannot use, the response belongs in that student's IEP or 504 process as well as in the vendor conversation.

Sixth, interim accommodations get skipped. Vendor fixes take months. In the meantime, a student still has homework due Friday. Every unresolved blocker needs a documented workaround — an accessible alternative format, an alternate platform for that assignment, staff support, or extended time — communicated to the teachers who need to implement it. "We reported it to the vendor" is not an accommodation.

Seventh, procurement never changes. If the audit does not produce a purchasing gate, the district spends a year fixing problems while buying new ones. The gate does not have to be heavy: require a current conformance report before purchase, require accessibility language in the contract, require a named vendor contact for accessibility issues, and require that a district reviewer run a short task-flow test on a trial account before signing. Districts with strong purchasing consortia can push this upstream — a state or regional consortium demanding real conformance evidence moves vendors far more than a single district can.

Eighth, and most subtly, the audit never touches teacher-created content. A perfectly accessible LMS filled with untagged PDF worksheets, images without descriptions, and uncaptioned screencasts is still an inaccessible course. That is a professional learning problem, not a procurement problem, and it needs its own workstream: templates, training on the accessibility checkers already built into Word, Google Docs, and PowerPoint, a captioning workflow, and a simple rule that anything posted for students meets a short checklist.

A decision framework for what to fix, replace, or accommodate

Once findings are ranked, every one lands in a small number of buckets, and the decision usually turns on three variables: how badly it blocks a student, whether the district or the vendor controls the fix, and whether a viable alternative exists.

If the issue blocks a student from completing required work and the district controls the asset — a PDF, a page on your site, a video, a locally built app — fix it now and do not wait for a cycle. These are usually the fastest wins and the ones most fully within your control.

If it blocks a student and a vendor controls the fix, open a formal accessibility ticket in writing, request a remediation commitment with a date, and put an interim accommodation in place immediately. Track vendor responsiveness, because responsiveness is itself a procurement signal. A vendor who ships a fix in a release cycle is a different partner from one who has been promising a roadmap item for three years.

If it blocks a student, the vendor is unresponsive, and a viable alternative exists, plan replacement at the next renewal. Replacement is disruptive and should not be the reflex, but a platform that cannot be used by a class of students is not doing the job the district bought it to do.

If it degrades rather than blocks — extra steps, confusing announcements, poor contrast on a secondary screen — batch it into the next remediation cycle and hold it against the vendor at renewal.

The framework extends naturally to adjacent decisions. Procurement uses the same logic in reverse: before buying, ask whether the tool would produce blockers, whether the vendor has a credible accessibility engineering practice, and whether an alternative clears the bar. Curriculum adoption committees should apply it to instructional materials, since a digital textbook platform is edtech regardless of which department bought it. And it applies to the district's own build decisions — if internal staff are building a portal, the same task-flow testing belongs in the development process rather than at the end.

One adjacent area deserves specific attention by 2027: AI-driven features embedded in existing platforms. Adaptive practice engines, automated feedback, AI tutors, and generated content are arriving inside tools districts already own, often without a separate procurement event. These features frequently ship with new interface patterns — chat panels, streaming responses, dynamic content regions — that are exactly the patterns most likely to break screen reader announcements and keyboard focus. Treat a significant AI feature release as a trigger for re-testing that platform, and ask vendors directly how generated content handles alternative text, reading order, and live-region announcements. The same goes for automated captioning and AI-generated transcripts: useful as a starting point, not sufficient as a finished accessibility feature.

Building the capability so it survives the audit

An audit is an event; accessibility is an operating capability. The districts that hold their gains build four things.

The first is a named owner with real authority. Whether the title is digital accessibility coordinator, ADA coordinator, or an assigned share of an existing role, someone has to own the inventory, the scan results, the vendor relationships, and the calendar. Distributed ownership across a committee with no lead reliably decays within a year.

The second is a procurement gate with teeth, as described above, plus a standard accessibility clause in contracts that requires conformance to the district's stated standard, timely remediation of reported defects, and the right to remedies if the vendor does not deliver. Legal counsel should draft it once and it should appear in every edtech contract thereafter.

The third is professional learning that reaches teachers, not just technologists. Short, practical, recurring: how to write useful alternative text, how to structure a document with real headings, how to caption a screencast, how to check a file before posting it, and why each one matters to a specific student in the building. Tie it to the accessibility checkers already in the tools staff use every day, because adoption follows convenience.

The fourth is a public feedback loop. Publish an accessibility statement that names your standard, describes known limitations, and gives a real contact method with a response commitment. Then actually respond. A district that hears about a broken math platform from a parent in October and fixes it in November is in a fundamentally different position — legally, educationally, and reputationally — than one that hears about it first from a complaint investigator in March.

Measure a few things and report them on a regular cadence: percentage of Tier 1 platforms with a current verified evaluation, count of open blocking findings and their age, percentage of new purchases that cleared the gate, and time-to-response on accessibility feedback. Those four numbers tell a board more than any compliance percentage from a scanning dashboard, and they are honest about where the work stands.

Related questions

How often should a district re-audit its edtech tools?

Run automated scans continuously and review results monthly. Spot-check Tier 1 platforms each semester and after any major vendor release. Repeat full manual and assistive-technology-user testing on core platforms every two to three years, or immediately when a platform ships a significant redesign or new AI features.

Can automated scanning alone satisfy accessibility obligations?

No. Automated tools reliably catch only a portion of WCAG failures — roughly a quarter to a third — and cannot evaluate whether alternative text is meaningful, whether custom widgets announce state correctly, or whether a task can actually be completed with a screen reader. Manual and assistive technology user testing are required.

What should a district do when a vendor refuses to remediate?

Document the request and refusal in writing, put a durable accommodation in place for affected students, escalate through the contract and any consortium purchasing relationship, and plan replacement at renewal. Written records of the request and the vendor's response are what protect the district if a complaint is filed.

Who should be on the audit team?

At minimum: technology leadership, an assistive technology specialist, special education leadership, a teacher of the visually impaired or of the deaf and hard of hearing, curriculum, communications for the website and content side, and legal counsel for contract language. Include assistive technology users as testers, compensated where appropriate.

Does the audit cover teacher-created materials?

Yes. Untagged PDFs, uncaptioned screencasts, and images without descriptions inside an otherwise accessible LMS still block students. Handle it as a separate professional learning workstream with templates, training on built-in accessibility checkers, a captioning workflow, and a short pre-posting checklist.

FAQ

What standard should a district audit against in 2027?

WCAG 2.1 Level AA is the technical standard set by the Department of Justice's 2024 Title II rule for public entities' web content and mobile apps, with compliance dates in April 2026 for larger entities and April 2027 for smaller ones. Many districts choose to test against WCAG 2.2 Level AA instead, since it is the current W3C recommendation and is backward compatible — meeting 2.2 AA means meeting 2.1 AA. Auditing to the newer version costs little extra and avoids re-work.

How do we audit tools that sit behind a student login?

Set up dedicated test accounts with realistic student roles and course enrollments, then run task-flow testing manually against them. Most commercial scanning platforms support authenticated scanning with stored credentials, and open-source tools can be scripted against a logged-in session. The important part is choosing the right flows: whatever a student must do to receive, complete, submit, and get feedback on work.

Should students with disabilities be the ones testing?

Include them, carefully. Student testers surface real barriers that checklists miss, but sessions must be short, task-based, voluntary, and facilitated by staff who know the student — a teacher of the visually impaired, a teacher of the deaf, or an assistive technology specialist. Frame it explicitly as testing the software, never the student. Adult assistive technology users, including staff and community members, should carry much of the load and be compensated for it.

What is the difference between a VPAT and an ACR?

The VPAT is the blank template published by the Information Technology Industry Council; the Accessibility Conformance Report is the completed document a vendor produces using it. Districts should ask for a current ACR, check who authored it and when, and read the remarks column rather than only the supports/partially supports labels. Treat it as a vendor claim to verify, not as proof of accessibility.

How do we prioritize when the findings list is enormous?

Sort by student impact first, not by ease of fixing. Blockers on required tasks in Tier 1 platforms come first, especially anything on a login, navigation, or submission path. Then blockers in tools tied to special education or related services. Then degradations in high-traffic tools. Then everything else. Attach an interim accommodation to every blocker that will not be fixed within weeks.

What evidence should we keep for compliance purposes?

Keep the inventory with tiering rationale, dated scan results, manual test reports naming the assistive technology and versions used, vendor ACRs, written correspondence with vendors about defects, the remediation plan with owners and dates, records of interim accommodations provided, and your published accessibility statement and feedback log. The paper trail demonstrating a good-faith systematic process is what matters most.

Sources

• https://www.w3.org/WAI/standards-guidelines/wcag/
• https://www.w3.org/TR/WCAG22/
• https://www.ada.gov/resources/2024-03-08-web-rule/
• https://www.section508.gov/
• https://www2.ed.gov/about/offices/list/ocr/frontpage/faq/rr/policyguidance/index.html
• https://www.itic.org/policy/accessibility/vpat
• https://www.deque.com/axe/
• https://wave.webaim.org/
• https://webaim.org/projects/screenreadersurvey10/
• https://www.accessibilityassociation.org/

Related on PULSE

• Building an edtech procurement gate that vendors actually clear
• WCAG 2.2 AA in plain language for school technology teams
• How to run assistive technology user testing sessions in a school district
• Captioning and transcript workflows for district-produced video
• Remediating a decade of untagged PDFs on a district website
• Writing accessibility clauses into edtech contracts