PDF Remediation Services and Software: What Document Accessibility Remediation Costs Per Page

This is the most useful thing on the page, so it goes first. Accessible.org and Accessiblu both publish a per page number, and the numbers overlap, which makes it tempting to line them up and pick the cheaper one. They are not measuring the same thing.

Accessible.org prices by document complexity. Its three bands, $7.50 to $9.50, $9.50 to $11.50, and $11.50 and up, describe how hard your pages are to fix. A page of plain body text sits at the bottom. A scanned form needing OCR and rebuilt fields sits at the top. The deliverable is the same in every band; what moves is the labour your document demands.

Accessiblu prices by depth of deliverable. Its three tiers, $10, $15 and $18, describe how much you get. Tier 1 is structure only: tags, reading order, language, metadata, bookmarks. Tier 2 adds human written alternative text and screen reader QA. Tier 3 adds an Acrobat accessibility audit and a PDF/UA conformance report. Complexity is handled separately, by quoting forms and infographics individually.

So the comparison people make, "$10 versus $9.50, near enough the same", is wrong in both directions. Accessiblu's $10 tier does not include alternative text, which for an image heavy document is most of the work. Accessible.org's $9.50 does include it, but on a genuinely complex document you will not be paying $9.50. Read against each other properly, the two ladders tell you something the category never says out loud: on a simple text document Accessible.org is likely cheaper, and on a document where you need the conformance report as a deliverable Accessiblu has published a price for something most vendors will not quote at all.

The practical instruction is to normalize before you compare. Take ten representative pages from your actual backlog, specify the deliverable you need in writing, and ask every vendor to price those ten pages against that deliverable. A rate card comparison without that step is guesswork.

A PDF is a description of ink on a page. It knows where every glyph sits and what colour it is. On its own it knows nothing about which glyphs form a heading, which rectangle is a table, or what a photograph shows. A screen reader needs all of that, and remediation is the work of adding it.

Concretely, somebody opens the file and does most of this by hand:

• Tags and structure. Every paragraph, heading, list and table gets a tag that says what it is. Heading levels have to be real and in order, so a visual "big bold line" becomes an H2 that a screen reader can jump to.
• Reading order. Two column layouts, pull quotes, sidebars and captions get placed in the sequence a person would read them, which is frequently not the order they were drawn in.
• Alternative text. Every meaningful image gets a description, and every decorative one gets marked as decorative so it is skipped rather than announced.
• Tables. Header cells get identified as headers and associated with their data cells, so "Q3, Northeast, $412,000" is announced as a labelled value instead of three loose numbers.
• Forms. Every field gets a label, a tooltip and a tab order, and required fields get marked as required.
• Document level metadata. A title, a natural language, and bookmarks on anything long enough to need them.

That list is why the price is per page and why complexity moves it so much. A page of body text might take a few minutes. A page holding a nested financial table with merged header cells, or a scanned form that has to be rebuilt from an image, can take an hour. When a vendor quotes you a band rather than a number, the band is a bet on how many of your pages are the second kind. The practical consequence is that a quote given without seeing a representative sample is not a quote, it is an opening position.

If you want to see where your own documents currently fail before you ask anyone for a number, testing PDF accessibility covers the free checkers and, more usefully, what a clean checker report still does not prove.

Here is the thing the per page model hides, and it is the single most expensive mistake in this category.

Remediation fixes a file. It does not fix the thing that made the file. If your PDFs are authored once by a human, in Word or InDesign, and then published and left alone, remediation is a normal one time project cost and the per page rate is the whole story. Take the published $7.50 to $11.50 band, count your pages, and you have a budget.

But a large share of the PDFs an organization publishes are not authored by hand at all. They are generated by software: monthly statements, invoices, enrolment confirmations, benefit summaries, transcripts, board packets exported from a reporting tool. Those documents are regenerated on a schedule. Remediating them by hand means paying the per page fee again on the next cycle, because the new file is a new file, and nothing you did to last month's copy carries forward.

Put real numbers on it. A 5,000 page annual catalogue of generated documents at $9.50 a page is about $47,500 as a one time project. Regenerate that catalogue quarterly and the same work is roughly $190,000 a year, forever, with no year in which it gets cheaper. Against that, the published software licences in the table above cost $650 to $1,000 per user per year, and fixing the template that produces the documents is a fixed engineering cost that pays out on every future run.

So the decision is not really "which remediation vendor". It is:

• Documents authored by a person, published once: buy remediation, either as a service or as a desktop licence, depending on volume.
• Documents generated by your own software, on a schedule: fix the generator. Remediating the output is a subscription to a problem you can delete.
• Scanned or legacy documents with no source: buy remediation. There is nothing upstream to fix, and OCR plus tagging is genuinely skilled manual work.

Most organizations have all three, which is why the sensible first step is sorting the backlog into those three buckets before requesting a single quote. Vendors will happily price the whole pile at the same per page rate, including the part of it that should never have been remediated.

The two camps in the table price on different axes, and the crossover is easy to compute.

A managed service charges per page and includes the labour, the tooling and the quality check. There is no ramp up and no hiring. At the published $7.50 floor, a hundred page report is $750 and you are done. That is the right shape for a one off backlog, for an organization with no accessibility staff, and for anything where you want a supplier accountable for the result rather than a tool you have to learn.

A per seat licence charges per remediator per year and the page count is then free. At the published $650 a year for axesPDF, the licence pays for itself somewhere under a hundred pages of outsourced work, which sounds decisive until you add the part nobody quotes: remediation is a skill, and a competent remediator takes weeks to become fast and months to become reliable on tables and forms. The licence is cheap. The person is not. So the honest crossover is not "does the licence cost less than the pages", it is "will we be doing this every month for years".

The tie breaker is usually cadence rather than volume. A finance team publishing a 400 page regulatory filing once a year should buy the service. A state agency publishing a hundred documents a month should build the capability, license the software, and outsource only the overflow and the genuinely hard files. PDFix is the one vendor in the table that lets you start on the free Lite edition to find out which of those you are before committing to either.

There is a third camp that barely advertises itself: an SDK or API, which PDFix sells and prices only on request. That is the right shape when remediation has to happen without a person in the loop, inside a pipeline that already handles the documents. It is also the shape closest to the argument in the previous section, because at that point you are automating the fix rather than buying the labour.

Per page rates are only comparable if the scope behind them is. Four vendors quoting "$9 a page" can mean four genuinely different deliverables, which is exactly what the two published ladders demonstrate. The same trap sits one level up in the ADA compliance audit cost for the website those documents hang off, where providers bill per screen, per page type and per raw page and the quotes do not converge. Ask for these in writing:

• The target standard, by name and level. WCAG 2.1 AA, PDF/UA-1, Section 508, or a combination. "Accessible" is not a standard, and a file that satisfies one of these can fail another.
• Whether alternative text is included. This is the single biggest scope variable, and one published ladder charges $5 a page more for it. On an image heavy document it can be most of the work.
• Which checker the deliverable has to pass, and whether a clean report is the acceptance test. It should not be the only one. Automated checkers verify a minority of the requirements, which is the point made at length on our PDF accessibility testing page. Ask whether a human reviews reading order and alt text quality.
• How a page is counted. Blank pages, covers, and pages that are entirely a single image are all counted differently by different suppliers.
• What happens on a revision. If you send version 2 of the same document with three paragraphs changed, do you pay the full per page rate again? Get the answer before the first invoice, not after.
• Who owns the remediated file and the tag structure. Relevant if you later move suppliers or bring the work in house.
• Whether a conformance report is included. If your buyer is a government purchaser, they will ask for one, and it is a separate deliverable with its own price. Our VPAT and ACR guide covers what that document has to contain, and what VPAT services cost covers the going rate for producing one.

One more, and it is the one buyers skip: ask for a sample. Send three pages that represent your worst case, pay for those three if you have to, and judge the supplier on the tag tree they hand back rather than on the proposal.

Remediation spending in the United States is compliance spending, which is why the competition on these keywords is higher than the search volume alone would justify. Three regimes drive it.

ADA Title II covers state and local government, which includes public universities, school districts, transit agencies and county services. The Department of Justice rule sets WCAG 2.1 Level AA as the technical standard for web content and mobile apps, and PDFs published by a covered entity fall inside it. The compliance dates were extended by an Interim Final Rule published on 20 April 2026, to 26 April 2027 for larger entities and 26 April 2028 for entities under 50,000 population and special district governments. A great deal of the advice still circulating online prints April 2026 as the deadline, because it was written before the extension.

Section 508 covers federal agencies and, in practice, anyone selling to them. This is where the Accessibility Conformance Report enters the purchase, because a federal buyer is required to evaluate conformance before it buys, and the ACR is the document it evaluates. It is also why one vendor above can charge a premium tier for producing one.

Title III covers places of public accommodation and has no fixed deadline, only litigation risk, which is why private sector remediation budgets tend to appear after a demand letter rather than before one.

The practical read for a US buyer in 2026: the extension bought public entities a year, and the organizations using that year to fix the systems generating their documents will spend far less than the ones using it to remediate the same documents by hand a second time.

We sell an HTML rendering API, so read this section knowing what we sell. It still contains the recommendation we would give a friend.

If a PDF is produced by your own software from HTML you control, the accessibility of the output is decided by the markup, not by the PDF engine. Real heading elements produce real heading tags. A table with proper th elements and a scope attribute produces an associated header structure. An alt attribute becomes alternative text. A lang on the html element becomes the document language. Get those right once, in a template that is in version control and reviewed like the rest of your code, and every document that template produces from then on arrives structured. That is a fixed cost against an unlimited number of pages, and it is the only version of this problem that gets cheaper over time.

Two honest caveats, because the category oversells this. First, tagged is not the same as conformant. A tagged PDF has structure; a PDF/UA conformant PDF has structure that has been validated against a specific set of conditions, and browser engines do not currently promise the second. Second, this does nothing at all for documents you did not generate: scans, supplier PDFs, twenty year old archives. Those need remediation and there is no clever way around it.

The detail on which engines emit tagged output and which actually target PDF/UA is on accessible PDF generation, the practical HTML side is in producing an accessible PDF from HTML, and if the documents in question are generated from templates by a merge engine rather than rendered from your own pages, the document generation API comparison maps that camp instead.