Accessibility Was Never Too Expensive. It Was Too Easy to Ignore.
A new ADA deadline, LlamaIndex, and some vibe coding to fix inaccessible documents
On April 24, 2026, a federal rule takes effect that will reshape how public institutions deliver digital content. The Department of Justice’s ADA Title II Digital Accessibility Rule, published in April 2024, establishes the first legally binding technical standard for web and mobile accessibility across state and local government. The standard is WCAG 2.1 Level AA. The scope is broad: every website, every app, every online form, every PDF, every court document, every video, every digital service provided by a covered entity must comply.
The first compliance deadline applies to jurisdictions serving populations of 50,000 or more. That includes most state agencies, public universities, court systems, transit authorities, and municipal governments. Smaller jurisdictions have until April 2027. The penalties are real: up to $75,000 for a first violation, $150,000 for subsequent violations, assessed per instance. A single inaccessible e-filing portal or batch of untagged court forms could generate substantial liability.
This is not new territory in principle. The ADA has been the law since 1990. Section 508 has required federal digital accessibility for decades. WCAG guidelines have existed since 1999. What is new is that the DOJ has, for the first time, specified an enforceable technical standard for state and local government and attached a deadline to it. The DOJ’s compliance guidance outlines the steps covered entities should be taking now. The era of vague obligations and good-faith efforts is ending.
The document problem
Most institutions I talk to understand, at least in broad terms, that their websites need to be accessible. Fewer have reckoned with the document problem. Public institutions produce and host enormous volumes of PDFs, Word documents, slide decks, and scanned forms; court opinions, administrative paperwork, policy documents, research publications, meeting minutes, and budget reports. The overwhelming majority of these documents are inaccessible. They lack tagged headings, meaningful reading order, table structure, alt text for images, and navigable form fields. A screen reader encounters most of them as a wall of undifferentiated text, or worse, as a series of images with no text content at all.
Manual document remediation is expensive. Industry estimates range from $50 to $150 per document, depending on complexity, and a single document can take a trained specialist 10 to 15 hours to complete. For an institution with thousands of documents, the math is prohibitive. This is why, despite decades of legal obligation, most public-facing documents remain inaccessible. The cost of compliance, on a document-by-document basis, has exceeded the institution’s willingness to pay.
The new rule changes that calculus. The penalties for non-compliance now carry dollar amounts, and the DOJ has signaled its intent to enforce. Institutions that have been deferring remediation no longer have that option.
“Just stop using PDFs” is not a solution
A response I have encountered with increasing frequency is the suggestion that institutions should simply move away from PDFs. Use native HTML. Publish in accessible formats from the start. Stop producing PDFs altogether.
This sounds reasonable if you are a legal compliance team or a computer scientist advising from outside the workflow. It does not sound reasonable if you are an educator whose entire field runs on PDFs. Scientific publishing produces formatted PDFs. That is the output. Journals publish PDFs. Preprint servers distribute PDFs. Course reading lists are PDFs. Faculty share PDFs. Students read PDFs. The suggestion that higher education should abandon the format in which virtually all of its scholarly literature is produced and distributed is not a practical recommendation; it is an abstraction offered by people who do not deliver the education.
The same holds across government. Courts produce PDFs. Agencies publish PDFs. Legislative bodies distribute PDFs. The format is embedded in institutional workflows at a level that will not change by April 24, or any time soon. A useful solution has to meet institutions where they are, not where a compliance consultant wishes they were.
A solution that is all LlamaParse and a bit of vibe coding
I built a tool using LlamaParse that converts inaccessible documents to fully accessible, WCAG 2.1 AA-compliant HTML. It handles headings, tables, equations, figures, alt text, reading order, skip navigation, landmark regions, and auto-generated tables of contents. Every output file passes an eight-point accessibility audit at a 100% rate.
I want to be precise about what I actually built, because the honest accounting matters. The tool is 95% LlamaParse and 5% my own work. LlamaParse, developed by LlamaIndex, is an API service that extracts structured content from documents (e.g., text, tables, equations, figures, headings) and returns it as a clean, organized Markdown file. That extraction is the hard part. It is the part that has taken the LlamaIndex team years of hard work to refine, making them the industry leader in this space.
LlamaParse does it well, and it does it at scale. But LlamaParse does not produce accessible HTML. Its output formats are markdown, JSON, and plain text; structured representations of a document’s content, but not WCAG-compliant web documents. That gap between structured markdown and accessible HTML is where my vibe coding comes in. And because LlamaParse handles over 130 file types (e.g., PDFs, Word documents, PowerPoints, Excel files, images, etc.), this approach is not limited to PDF remediation. Virtually any document format an institution produces can be routed through the same pipeline to produce accessible HTML output.
My post-processing pipeline is simple: five Python scripts that convert LlamaParse’s markdown output into accessible HTML. One script handles math equations, routing them through MathJax for screen-reader navigation. One restructures tables with proper headers and captions. One wraps figures with accessible markup. One repairs heading hierarchies and adds navigation IDs. One adds the accessibility scaffolding: skip links, ARIA landmarks, language attributes, and the table of contents. Then an audit script checks the output against WCAG criteria.
I wrote those scripts with Claude as my coding partner. I am not a software engineer, so you might cringe at my vibe-coding efforts. That’s fine. I welcome you to help address this larger problem I am trying to solve. This isn’t about flexing. It’s about solutions.
The cost comparison
The numbers are worth stating plainly.
LlamaParse uses a credit-based pricing model. The free tier includes 10,000 credits per month; at the standard extraction rate of one credit per page, that is 10,000 pages at no cost. Paid tiers start at $50 per month for 40,000 credits. The effective cost per page ranges from roughly $0.001 to $0.003, depending on the extraction mode, well under half a cent in every case.
For context, I built a cost comparison that I keep coming back to: one meeting; four staff members, one hour, salaries averaging $60K annually, costs an organization about $170, and converts zero documents. The same $170 applied to this tool would convert tens of thousands of pages to accessible HTML. And the free tier alone covers 10,000 pages per month before an institution spends anything.
The scripts used to convert markdown to accessible HTML are available on GitHub. A user brings their own LlamaParse API key, free to obtain from LlamaIndex, with a generous free tier. You upload a PDF or a batch of documents, and get back self-contained HTML files that work in any browser with any screen reader. I am in the process of setting up the repository and making it publicly available online, and I will share the link when it is ready.
Not perfect, but effective and sustainable
I want to be honest about limitations. This is not a 100% perfect solution. Edge cases exist. Complex multi-column layouts, heavily designed documents, unusual table structures, and scanned images without OCR will produce imperfect output. Neither an automated system nor a human specialist working at speed can handle every document flawlessly. But, so far, the PDFs, PPTs, and other docs have all passed the accessibility test.
And when I post the accessible HTML files to Canvas, the University of Michigan’s learning management system, all the HTML files (as pages) pass the accessibility test.
But the question is not whether the tool is perfect. The question is whether it is effective, cheap enough to deploy at scale, and sustainable over time. On all three counts, the answer is yes. A tool that correctly converts the vast majority of documents at half a cent per page, achieves a 100% pass rate on accessibility audits, and can be run by anyone with a free API key is a practical response to a problem that has resisted solutions for decades. The remaining edge cases can be identified and addressed through human review at a fraction of the cost of full manual remediation.
Why this matters beyond compliance
I want to be clear that I view this primarily as a civil rights issue, not a compliance issue. Approximately 42.5 million Americans live with a disability that affects their use of digital content. When a court system publishes opinions as inaccessible PDFs, it is not a technical shortcoming; it is an access-to-justice failure. When a university posts research behind inaccessible formatting, it excludes the people that research is meant to serve. The standards to fix this have existed for more than 25 years. The publishers and institutions with the resources to implement them have chosen not to do so.
What has changed is that the cost barrier has collapsed. The argument that accessibility is too expensive to implement at scale no longer holds. A tool built in two days by a non-engineer, powered by an extraction API that costs less than half a cent per page, produces accessible output that passes every audit check. The technology to do this is available now at a price point that makes inaction a choice rather than a constraint.
The April 24 deadline is four weeks away. For institutions still weighing their options, the tool will be freely available and open source. The harder question, why accessible documents were not the default from the beginning, is one that the deadline does not answer.