AI-Assisted PDF Accessibility Remediator

The problem came from conversations, not a feature list

University staff and faculty, both at my institution and at conferences, described the same challenge: making existing course materials and documents accessible takes time they do not have. Several were concerned about completing remediation ahead of an anticipated April 2027 compliance deadline.

Those conversations gave me a practical engineering problem to work on: reduce repetitive document-remediation work while keeping people responsible for reviewing the result.

Commercial remediation services also raised questions about cost and the handling of sensitive university documents. I wanted to explore an alternative that an institution could operate within its own infrastructure.

The approach: local processing, assisted decisions

The prototype is a locally hosted web application that combines PDF processing with AI-assisted suggestions. Local model inference runs through Ollama rather than requiring a third-party AI inference API.

• Document processing: Workflows incorporate OCR and document tagging to support remediation.
• AI assistance: Local inference supports tasks such as generating proposed alternative text.
• Human review: Review screens let a person inspect document structure and proposed accessibility changes.
• Institution-controlled deployment: The design supports hosting within institution-controlled infrastructure rather than sending documents to an external AI provider for inference.

The intended users are staff and faculty who need help remediating documents, with human judgment remaining part of the workflow.

Engineering decisions and tradeoffs

Control over data, not a blanket security guarantee

Running inference locally avoids the need to send document content to an external AI inference service. That is a useful data-handling boundary, but it does not make a deployment automatically secure. Access controls, storage, logging, retention, and infrastructure configuration still need review.

Why per-token costs matter at university scale

In our comparison, processing an 808-page document through a competing service cost approximately US$13 in tokens alone, or about US$0.01609 per page. That single-document result illustrates how usage-based inference charges can accumulate across a university's document collection.

For an illustrative planning scenario, assume 10,000 courses with 1,500 pages of content per course requiring remediation. That is 15 million pages. Applying the observed rate of US$13 per 808 pages produces an estimated US$241,337 in token charges alone for one processing pass.

• 5,000 courses: 7.5 million pages, approximately US$120,668 in tokens.
• 10,000 courses: 15 million pages, approximately US$241,337 in tokens.
• 15,000 courses: 22.5 million pages, approximately US$362,005 in tokens.

These are scenario estimates, not verified university course counts or a measured average of pages per course. They assume every included page needs processing at the same token cost as the comparison document. Actual charges will vary with document complexity, model pricing, and repeat processing. Separate sections taught by different instructors could add distinct materials; shared or already-accessible documents could reduce the volume.

Local inference removes that external per-token charge, making it a compelling cost-control approach at this scale. It still requires hardware, electricity, maintenance, and operational support. The estimates above represent potential external token charges avoided, not measured net savings or a claim that the two workflows produce equivalent results.

Estimated local deployment costs at UTEP

Our current planning estimate for getting the local system up and running at UTEP is approximately US$10,000 in one-time setup costs, with less than US$1,000 per year in electricity. These are project-team estimates, not measured operating costs or a finalized deployment budget.

Compared with the illustrative 10,000-course scenario above, which estimates US$241,337 in external token charges for one processing pass, the anticipated setup and electricity costs are substantially lower. Local inference also avoids another external per-token charge when documents need to be processed again.

This is not a like-for-like total-cost comparison: the token estimate covers one processing pass, while electricity is an annual expense. Staffing, maintenance, hardware replacement, processing capacity, and output quality still need evaluation before claiming net savings. The 10,000-course scenario is illustrative, not a verified count of UTEP courses.

Sources and estimate assumptions

• Token-cost baseline: The reported comparison run: approximately US$13 for an 808-page document. This is a multi-document observation, not a published vendor benchmark.
• Pages per course: The 1,500-page assumption comes from Instructure's accessibility information and is an assumption/average and not verification of that figure.
• University catalog references: Arizona State University, Northern Arizona University, University of Texas at Austin, University of Texas at El Paso, and University of Texas at Dallas.
• Calculation: Courses × 1,500 pages per course × (US$13 ÷ 808 pages), rounded to the nearest dollar. The 10,000-course scenario is the midpoint of the assumed range, not a measured median across universities.

Assistance instead of automatic compliance claims

OCR, document tags, and generated descriptions can be incomplete or incorrect. Human review is part of the design because producing a processed PDF is not the same as establishing that it is accessible.

Current status and validation still needed

This is a working prototype under development, not a finished compliance service. I have also prepared third-party software licensing and technical documentation for university review and pilot planning.

No measured time savings, remediation accuracy, or compliance results are reported here. A useful pilot would need to evaluate:

• The quality of document structure and alternative-text suggestions across representative PDFs.
• The time required for remediation and human review compared with the existing workflow.
• Accessibility of both the application and its output, including manual checks with assistive technology.
• Data handling, deployment requirements, and operating costs in the intended institutional environment.

Limit: Automated suggestions require human review; accessibility compliance is not guaranteed. Applicable deadlines and requirements must be confirmed by the institution.

What this project shows about my engineering

I started by listening to people describe a difficult, repetitive task, then built a prototype around their constraints: limited time, sensitive documents, and a need to review the results.

The work brings together software development, document processing, local AI integration, and deployment considerations. My goal is a practical tool whose capabilities and limitations are clear to the people using it.

Contact me about the project or view my resume (PDF).