A Section 504 digital accessibility audit tests whether your websites, mobile apps, and digital documents give people with disabilities equal access to your programs. It’s also the record you’ll rely on if a complaint, a compliance review, or a funding question ever puts that access in doubt.
Section 504 of the Rehabilitation Act applies to every program or activity that receives federal financial assistance. In practice, that means health systems, hospitals, colleges and universities, state agencies, and the many nonprofits that rely on federal funding.
For recipients of Department of Health and Human Services (HHS) funding, the duty now has a technical standard and a date. Web content and mobile apps must conform to WCAG 2.1 Level AA by May 11, 2027, for recipients with 15 or more employees, and by May 10, 2028, for smaller recipients. HHS moved those dates back a year in a May 2026 interim final rule, but the underlying duty to provide equal access applies now.
This guide covers what a Section 504 audit measures, how to run one, what the audit report should contain, and what to do with the findings. For the full set of legal requirements, see our guide to Section 504 website compliance.
What a Section 504 audit measures
A general accessibility audit asks whether your content works for people with disabilities. A Section 504 audit asks a narrower question: does your content meet the standard your funding agency applies, across all the content that standard covers?
The standard
The HHS rule requires web content and mobile apps to conform to WCAG 2.1 Level A and Level AA. That’s the version to audit against, even though WCAG 2.2 is newer. Testing to WCAG 2.2 AA is a reasonable internal bar, but report WCAG 2.1 AA conformance separately so the result maps to the rule.
HHS has written a WCAG standard into its Section 504 rule. The Department of Education’s Section 504 regulations don’t name one, so colleges and school districts are measured on whether their digital programs are equally accessible. Most use WCAG 2.1 AA as the benchmark, and public institutions owe it under ADA Title II as well.
Many recipients are covered by more than one law. A public university or state agency that takes federal funds falls under both Section 504 and ADA Title II, whose WCAG 2.1 AA compliance dates moved to April 26, 2027, and April 26, 2028, in a DOJ interim final rule. Section 508 is different. It binds federal agencies, incorporates WCAG 2.0 AA, and doesn’t apply to funding recipients directly. Our comparison of Section 504, the ADA, and Section 508 sets out where the three laws overlap.
What’s in scope
The rule covers the web content and mobile apps a recipient provides or makes available, including those it offers through vendors and other contractual arrangements. That includes documents posted to your site, such as PDFs, forms, and slide decks. If much of your content lives in documents, plan a separate pass. Our guide on how to audit your PDF library covers it.
What’s exempt
Five exceptions in the HHS rule narrow the scope:
- Archived web content, as the rule defines it
- Conventional electronic documents posted before your compliance date, unless they’re still used to apply for, access, or take part in a program
- Content posted by a third party, unless it posts under a contract, license, or other arrangement with you
- Password-protected or otherwise secured documents about a specific person, their property, or their account
- Social media posts published before your compliance date
Record which exception applies to each item you exclude. An exclusion with no stated reason looks like a gap in the audit. Exempt content must still be made accessible to a person who needs it.
How to conduct a Section 504 website audit
A Section 504 audit is a repeatable workflow. It inventories your digital assets, tests them against WCAG 2.1 AA, and turns the results into a plan for fixes.
Inventory and user journeys
First, list every digital touchpoint your organization runs, including websites, mobile apps, patient or student portals, and vendor platforms. Large organizations often have hundreds of these.
Rank these touchpoints by how many people use them and how central they are to your programs. An application form, a patient portal, or a course registration system should come before a rarely visited page.
Next, document user journeys for people with disabilities. Don’t just look at single pages. Think about real tasks, such as filling out a form, booking an appointment, or paying a bill. WCAG conformance applies to complete processes, so a barrier on any step fails the whole task.
Sample and test
You can’t test every page of a large estate by hand. Scan everything automatically, then choose a manual sample that covers each template, each core journey, and each content type, such as video, forms, and documents.
To achieve clear results, use the same rules for every accessibility test. Also, use a standard scale to rate how bad an issue is. Consistency helps you compare results across different teams, properties, and audit cycles. Where you can, include people with disabilities who use assistive technology. They find barriers a checklist misses.
Plan for fixes
Once you have your audit findings, turn them into a backlog. Don’t try to fix everything at once. To create your backlog, rank issues based on how they impede the user, the legal risk, and how hard they are to fix. Give every task a clear owner and deadline. This type of plan makes your progress trackable and documents your effort if a complaint arrives.
What the audit report should include
The audit report is your evidence. A useful one records:
- Scope: The properties, pages, apps, and documents tested, plus any exceptions applied.
- Standard: WCAG 2.1 Level A and AA, named by version.
- Methods: The automated scanners, manual checks, and assistive technology and browser combinations used.
- Findings: Each issue mapped to a WCAG success criterion, with its location, severity, and the user journey it affects.
- Remediation: An owner and target date for each issue.
- Dates: When testing happened and when it will run again.
Treat the report as a dated record of conformance for the content tested, not a certificate. Your content changes every week, so last year’s report says little about your site today.
Automated, manual, and assistive technology testing
No single method finds every barrier. A credible Section 504 audit combines three:
- Automated testing: Scanners check whole sites quickly for issues code can detect, such as missing alt text, empty links, or low color contrast. They can’t judge whether alt text is accurate or whether a process makes sense.
- Manual testing: Experts check what software can’t, such as focus order, error messages, and whether content reads in a logical sequence.
- Assistive technology testing: Testers complete core journeys with screen readers, screen magnifiers, voice input, and keyboard-only navigation.
For a large estate, add monitoring between audits. Automated monitoring across all your properties shows when a new release or a new batch of documents brings back issues the audit fixed. Look for reporting that compliance and legal teams can read, and confirm that testing covers WCAG 2.1 AA, not only newer versions.
After the audit
An audit gives you a baseline. Keeping it takes ownership:
- Name an owner: Give your Section 504 coordinator visibility into audit findings, not just complaints.
- Build in checkpoints: Add accessibility checks to launch cycles, and require sign-off before a new site or app goes live.
- Train by role: Developers, designers, content authors, and managers each need different guidance, tied to the checklists they use every day.
- Fix the source: Correct shared templates, components, and inclusive design patterns, not just individual pages.
- Measure progress: Track open issues by severity, time to fix, and how often fixed issues return.
Sector guidance can help. See our guides to Section 504 in healthcare and patient portals and in higher education.
How Section 504 is enforced
Section 504 is a civil rights law. For HHS recipients, the HHS Office for Civil Rights investigates complaints and conducts compliance reviews, and it doesn’t have to wait for the 2027 date, because the general duty of equal access already applies. Investigations often end in a resolution agreement with required fixes and monitoring. A recipient that won’t comply puts its federal funding at risk, and individuals can also sue. For more, see what happens when Section 504 requirements are violated.
Section 504 audit FAQ
How does a Section 504 website audit differ from a general accessibility audit?
It measures against a defined benchmark, WCAG 2.1 AA for HHS recipients, applies the rule’s scope and exceptions, and produces documentation you can show a regulator. A general audit may use a different WCAG version or level and skip the scoping.
How often should you run a Section 504 audit?
Run a full audit at least once a year, and again after any redesign, platform migration, or major release. Automated monitoring between audits catches regressions as they happen.
Which WCAG version applies, and when?
For HHS recipients, WCAG 2.1 Level AA, by May 11, 2027 (15 or more employees) or May 10, 2028 (fewer than 15). Public entities also owe WCAG 2.1 AA under ADA Title II, by April 26, 2027, or April 26, 2028, depending on the population they serve.
Does Section 504 apply to private companies?
Only when they receive federal financial assistance. A private hospital or university that receives federal funds is covered. A company with no federal financial assistance isn’t, though the ADA may still apply. Our definition of Section 504 explains who counts as a recipient.
What tools does a Section 504 audit need?
You need an automated scanner for site-wide checks, manual testing by trained evaluators, assistive technology such as screen readers, magnifiers, and voice input, and a way to track each finding through to remediation. For large estates, continuous monitoring keeps the baseline from slipping between audits.
To check a single page before you scope a full audit, try the free Section 504 compliance checker. For ongoing monitoring across a large digital estate, see how Siteimprove.ai Accessibility tracks issues, ownership, and remediation progress.