508 Compliance Testing Software: Digital Accessibility Tools Compared

This is the most useful thing on the page, so it goes first.

Search for 508 compliance testing software and you get two categories wearing the same label. One tests HTML in a browser. The other tests PDF structure in a file. Almost no product does both, and almost no comparison article says so.

The reason is architectural rather than commercial. A web scanner works by loading a page, building the accessibility tree the browser exposes, and comparing what it finds against rule sets like axe-core. A PDF checker works by parsing the document's tag tree, its structure elements and its metadata, then testing them against PDF/UA-1 (ISO 14289-1). Those are different parsers reading different formats against different standards. A tool built for one has no path to the other short of writing a second product.

Section 508 does not care about that boundary. Under the Revised 508 Standards, a PDF your agency publishes is an electronic document and it is in scope exactly like the page it sits on. So a program that buys only a web platform has bought coverage of one half of its obligation while its report shows green. That is the failure mode we see most often: a clean dashboard, a real gap, and nobody looking at the PDFs because the tool that produced the dashboard never opened one.

The fix is not expensive. It is a second tool, and the two that matter cost nothing. What it does require is that somebody on the program owns documents as a separate workstream with its own checks, rather than assuming the platform subscription covered it.

Testing a website for Section 508 means testing against WCAG Level A and AA, because that is what the Revised 508 Standards incorporate. A workable sequence looks like this.

Start with an automated scan for breadth. Run axe DevTools or WAVE across a representative sample of templates rather than every URL. On a database driven site, ten templates usually cover ten thousand pages, and scanning all ten thousand mostly produces the same twelve findings ten thousand times. What you want out of this pass is a list of systematic defects: missing form labels, contrast failures in the design system, images without alternative text, a skipped heading level in the layout.

Then test with a keyboard. Unplug the mouse and complete the three journeys that matter most on your site. Can you reach every control, is the focus indicator visible at every step, does focus get trapped in a modal, does the tab order match the visual order. Automated tools detect very little of this and it is where real users get stuck.

Then test with a screen reader. NVDA on Windows and VoiceOver on macOS are both free. Listen to a form, a data table and an error state. The tool will not tell you that your error message says "invalid input" without saying which field, but a screen reader user will notice in about four seconds.

Then check the documents. This is the step that gets skipped. Export the PDFs a visitor can download from those journeys and run them through PAC or veraPDF, because your web scanner did not look at them.

Then write it down. Section 508 work is procurement work, and procurement runs on documentation. What you produce at the end is an accessibility conformance report, which is a subject of its own covered on our VPAT and accessibility conformance report page.

Different job, different tools, and both of the good ones are free. We have since priced the whole document side of this separately: our PDF accessibility checker comparison covers six tools, including the two below, and separates the ones that formally validate PDF/UA from the ones that only report.

PAC is the desktop checker most document accessibility specialists reach for. It validates against PDF/UA and reports WCAG relevant findings, and its most valuable feature is not the report at all: it is the preview that shows you the document the way assistive technology receives it. Reading order problems that a pass or fail report cannot express become obvious in about ten seconds in that view.

veraPDF is the open source validator, and it is the right choice when you want this in a pipeline rather than on somebody's laptop. It runs headless, it exits with a status your build can act on, and it validates PDF/A as well as PDF/UA. If you generate documents continuously, this is the check that belongs in continuous integration next to your unit tests.

Run both and you will still not be finished, and it is worth being blunt about why. Conformance checking is automated verification of machine checkable conditions. The Matterhorn Protocol, which is the reference model these tools work from, contains a large set of conditions that no software can evaluate, because they are judgments. Whether the alternative text on a chart actually describes the chart. Whether the heading hierarchy reflects the document's real structure. Whether a table's headers describe what the cells contain. A file can pass every automated check and still be unusable, so budget a human pass on anything a regulator or a plaintiff might read. Our guide to testing PDF accessibility covers the five failures specific to generated documents.

Automation is genuinely useful and it is routinely oversold, so it helps to be precise about the boundary.

Automation is reliable for conditions with a machine checkable answer. Does this image have an alt attribute. Does this input have an associated label. Is this contrast ratio below 4.5 to 1. Does the page declare a language. Is there a duplicate id. These are deterministic, and a scanner will find every instance across ten thousand pages faster and more consistently than any human.

Automation cannot evaluate meaning. An image with alt="image1.jpg" passes the alt attribute check and fails the user completely. A page where every heading is styled with a div and CSS passes a contrast check and gives a screen reader user no structure to navigate. A form that announces an error without identifying the field passes label checks and still blocks the submission. These are the failures that generate complaints, and they need a person.

The number worth carrying into a budget conversation is that automated testing addresses a minority of WCAG success criteria, and vendors differ on the exact share. Treat any claim of full automated compliance with suspicion, including from the vendors in the table above. What automation actually buys you is scale and regression protection: it stops the twelve systematic defects from coming back after the next release, which frees your expensive human testing for the judgment calls. That is a real return, and it is not the same as compliance.

Buyers often search for a reporting tool when what they need is a specific document, so it is worth separating the two.

For a federal buyer evaluating your product, the deliverable is an Accessibility Conformance Report, produced by completing a VPAT. That is a written self assessment covering each applicable success criterion with a conformance level and explanatory remarks. No scanning tool produces one for you. Scanners produce evidence that goes into it.

For an agency assessing its own site, the deliverable is usually an accessibility plan or a remediation backlog with owners and dates, plus periodic monitoring to show the trend is going the right way. This is where the enterprise platforms earn their keep: crawling at scale, tracking issue counts over time, and assigning findings to teams. It is also why they will not print a price, because what they are really selling is scoped to your site size and your services needs.

For an engineering team, the deliverable is a build that fails when accessibility regresses. That is axe in CI for the web layer and veraPDF for the document layer, and it costs a developer afternoon rather than a subscription.

Being clear about which of these three you actually need will save you more money than any comparison of the rates in the table.

Four of the nine tools we approached publish nothing: UserWay, AudioEye, Siteimprove and Level Access. Level Access does not have a pricing page at all, and AudioEye names three plan tiers without attaching a number to any of them. This is worth understanding rather than resenting, because it tells you what you are being sold.

Published self serve pricing is what a product does when the product is the whole purchase and one customer looks much like another. accessiBe publishes because accessWidget is a script you install, and traffic volume is a fair proxy for cost to serve, which is why the tiers are set from Similarweb data rather than from anything you tell them.

Quote only pricing is what a product does when a meaningful share of the value is services: audits, manual testing, expert hours, legal support, training. Those scale with your site's complexity and your risk appetite, not with your traffic, and a rate card would misrepresent the deal in both directions. That is a defensible reason to hide a number. It is still a cost to you, because it means you cannot shortlist on price and every evaluation starts with a sales call.

The practical move is to fix the scope before you call anyone. Decide how many templates are in scope, whether you need manual expert testing or only automated monitoring, how many documents are involved and who will remediate them, and whether you need an ACR at the end. Vendors quote wildly different numbers for the same website depending on which of those you say yes to. If the document half of that scope is what you are trying to size, our PDF remediation services comparison has the per page rates, including the four vendors there that do publish them.

We sell an HTML rendering API, so read this section knowing what we sell. The recommendation in it still holds if you buy nothing from us.

If the PDFs in your Section 508 scope were typed by a person in Word and uploaded once, testing and remediation is the right shape of spend. You have a finite backlog, you fix it, you are done, and the per page rates on our remediation page are the market. Budget for the web pages separately, because no scanner subscription and no ADA compliance audit cost we could find includes documents in the quoted price.

If the PDFs are produced by your software, that model is a subscription you did not intend to buy. A benefits statement generated monthly, a report exported on demand, an invoice per transaction: every regeneration produces a fresh file with the same structural defect, and remediation is charged again each time. Testing them harder does not help. It only tells you faster that the same template failed again.

The leverage is upstream. Documents generated from semantic HTML with tagging enabled inherit their structure from the markup, so headings, lists, tables and alternative text survive into the PDF tag tree. Set the document title in metadata for WCAG 2.4.2 and declare the language, and a large share of the machine checkable conditions are satisfied at render time, on every file, forever, without anybody opening a remediation tool. Fix the template once and the whole catalogue comes out right.

That does not remove the need for judgment. Somebody still has to write alternative text that means something. But it changes the unit of work from files to templates, and there are always far fewer templates.