How ITHAKA built an on-demand PDF remediation pipeline on AWS

ITHAKA is a not-for-profit organization dedicated to improving access to knowledge and education. Through its platforms, including JSTOR, one of the most widely used digital libraries in the world, ITHAKA provides millions of researchers, students, and educators access to scholarly content spanning centuries of academic work. That mission depends on making content accessible to every user, regardless of ability.

ITHAKA’s digital corpus includes approximately 156 million pages across 20 million PDFs, with source material dating as far back as 1550. The collection spans 30 years of humanities, arts, and social sciences publishing—born-digital documents, scanned print materials with varying optical character recognition (OCR) quality, and content ranging from single-column journal articles to complex mixed-media layouts. The U.S. Department of Justice (DOJ) revised the title II rule of the Americans with Disabilities Act (ADA) to give state and local government entities until 2027 for populations over 50,000 and 2028 for populations less than 50,000 to meet PDF/Universal Accessibility (PDF/UA) standards. ITHAKA faced a question central to its mission: how do you make 156 million pages accessible—responsibly?

In this post, we describe how ITHAKA and Amazon Web Services (AWS) collaborated to build an on-demand PDF accessibility pipeline that remediates documents when users need them, serving researchers while using nonprofit resources responsibly. For organizations managing a large document collection under accessibility compliance deadlines, this post shows there is an affordable, practical path forward that doesn’t require converting an entire library upfront.

How to remediate at scale

Making knowledge accessible is core to ITHAKA’s mission. The ADA title II revised rule provided a concrete deadline, but ITHAKA’s commitment to accessibility predates the regulation. The question was never whether to remediate, it was how to do it at scale.

Manual PDF remediation typically costs $1–4 per page. For ITHAKA’s 156 million-page corpus, that translates to $156 million–$624 million in upfront remediation costs. Even at the low end, bulk remediation of the full collection wasn’t a responsible use of nonprofit funds, and it was unnecessary.

Most users request a fraction of the corpus at any given time. A user searching JSTOR for a specific journal article doesn’t need all 20 million PDFs remediated; they need the one they’re reading. This usage pattern pointed to a different approach: rather than remediating the entire collection upfront, build an efficient automated process that converts PDFs on demand, based on actual user requests.

On-demand remediation serves users immediately, builds an accessible content library organically based on real demand, and directs resources where they have the most impact. As more users request accessible PDFs, the remediated collection grows, driven by the people who need it most.

The technical challenges compounded the economic ones. ITHAKA’s corpus includes born-digital PDFs with proper structure, scanned documents with partial or no OCR data, and everything in between. A remediation pipeline needed to handle this diversity reliably while integrating with ITHAKA’s existing content delivery infrastructure, security controls, and operational standards.

The starting point: an open source foundation

The Arizona State University (ASU) Artificial Intelligence Cloud Innovation Center (AI CIC), powered by AWS, developed an open source PDF accessibility remediation solution under the MIT License. The solution automates PDF remediation using the Adobe PDF Accessibility Auto-Tag API for structural tagging, Amazon Bedrock for generating image alt text, AWS Step Functions for orchestration, AWS Lambda for serverless processing, and AWS Fargate for containerized workloads. An earlier post on the Public Sector Blog, From inaccessible to inclusive, describes the solution and its initial use at The Ohio State University Libraries.

ITHAKA’s engineering team identified this solution as a strong starting point. Deploying it in production at ITHAKA’s scale, however, required several adaptations:

1. Infrastructure as code (IaC) – Migration from AWS Cloud Development Kit (AWS CDK) to Terraform, ITHAKA’s standard for infrastructure management
2. Event-driven API – Replacing Amazon Simple Storage Service (Amazon S3) object triggers with Amazon EventBridge for programmatic invocation, traceability, and status reporting
3. Security integration – Aligning with ITHAKA’s service control policies (SCPs), network boundaries, and AWS Identity and Access Management (IAM) least-privilege requirements
4. Observability – Integrating with ITHAKA’s existing monitoring and logging tools

In addition, the ITHAKA team adopted PDFix and veraPDF for structural tagging and validation to meet ITHAKA’s specific remediation requirements.

Architecture

The production architecture separates two concerns: the user-facing application flow and the underlying remediation pipeline.

The user experience follows a straightforward flow:

1. A JSTOR user navigates to a content item and chooses Request accessible PDF for an unremediated item or Download accessible PDF for a previously remediated item.
2. If an accessible PDF is available and newer than the source document, the user downloads it immediately.
3. If no accessible version exists, the system triggers the remediation pipeline and optionally notifies the user when processing is complete.

Remediated PDFs are cached and reused. A remediated PDF is only reprocessed if the source PDF is updated or the remediation pipeline has improved, avoiding redundant processing while keeping content current.

The following diagram shows the user-facing flow: a JSTOR application user requests an accessible PDF, the system checks for a cached remediated version, and if none exists, initiates the pipeline and notifies the user upon completion.

Figure 1: Application integration with PDF remediation

The remediation pipeline processes each PDF through a series of steps:

1. An EventBridge event initiates the workflow, carrying a tracing identifier and metadata that follows the job through every service.
2. A Lambda function splits the PDF into individual pages for parallel processing.
3. Step Functions orchestrates the remediation tasks: PDFix applies structural tagging (headings, paragraphs, lists, and tables) to each page, and Amazon Bedrock generates alt text descriptions for images and charts.
4. A merge step reassembles the tagged pages into a single remediated PDF with a generated document title.
5. Accessibility validation checks the output against PDF/UA standards using tools such as veraPDF.
6. The remediated PDF and a complete event log are stored in Amazon S3.

The following architecture diagram shows EventBridge initiating the workflow, Lambda splitting the PDF into pages, Step Functions orchestrating PDFix structural tagging and Amazon Bedrock alt text generation, followed by merging, PDF/UA validation, and storage in Amazon S3.

Figure 2: PDF remediation pipeline

Three design decisions shaped the architecture:

• End-to-end tracing – Every remediation job carries a tracing identifier from initiation through completion. EventBridge emits status events at each pipeline stage (splitting, processing, merging, and validation), and an event log aggregator stores the full job history alongside the remediated PDF in Amazon S3. This provides auditability and operational visibility across the entire workflow.
• Modular, swappable processing tools – The pipeline is designed so the remediation tools can be swapped out or chained with additional processors. As an example, the Adobe PDF Accessibility Auto-Tag API was replaced with PDFix and veraPDF without rebuilding the entire pipeline. As new tools become available, including generative AI capabilities, ITHAKA can integrate them to expand how they meet their users’ accessibility needs.
• Heuristic pre-analysis with human fallback – Before processing, the system evaluates what remediation each source PDF requires, reducing unnecessary computation. When automated remediation doesn’t meet accessibility standards, the system signals for human intervention, providing a safety net for documents that require manual attention.

Building and deploying together

In February 2026, ITHAKA engineers and AWS solutions architects held a 2-day build-and-demo workshop to adapt the open source solution for ITHAKA’s environment.

Day one focused on infrastructure and deployment. The team converted the deployment from CDK to Terraform, deployed core services including Lambda functions, the Step Functions state machine, Fargate tasks, S3 buckets, and Amazon Virtual Private Cloud (Amazon VPC) configuration, and tested the pipeline with sample PDFs. The team then replaced the S3 event trigger with an EventBridge based API, adding support for tracing identifiers and status events.

Day two shifted to validation, security, and operations. The team tested the pipeline against diverse PDF types from ITHAKA’s corpus and addressed production requirements: IAM policy hardening, network ingress and egress controls, and integration with ITHAKA’s observability tools.

The workshop surfaced real engineering challenges:

1. ITHAKA’s SCPs restricted S3 bucket policy modifications, conflicting with the solution’s deployment scripts. The team resolved this by adjusting the SCP rules to permit public access blocks without interfering with infrastructure as code (IaC) deployments.
2. Amazon Bedrock model availability required explicit Region configuration to align with ITHAKA’s account constraints.
3. ITHAKA’s engineers used agentic coding tools to accelerate the adaptation work during the workshop.

Following the workshop, ITHAKA and AWS held multiple working sessions through April 2026 to support production deployment, addressing pipeline tuning for ITHAKA’s specific corpus characteristics, deployment refinements, and production readiness validation.

Results

Early results from the pipeline demonstrate the viability of on-demand remediation at scale.

Dane Hillard, associate director of Product Engineering at ITHAKA said, “Our collaborators at AWS were incredibly helpful in understanding what others were already doing in the accessibility remediation space, thinking through how we could adopt and adapt prior work, and in validating approaches we had thought of toward creating something sustainable in support of our accessibility mission.”

The on-demand model means ITHAKA remediates PDFs as users request them. Each remediated document is cached for future users, so the accessible content library grows with actual demand. Over time, the most-requested content is remediated first, directing resources to where they serve the most people.

Looking ahead

ITHAKA plans to extend the pipeline to support remediation at content ingestion, processing new PDFs as they arrive from publishers. Portico, ITHAKA’s digital preservation service, is exploring applying a similar approach to its own corpus.

The modular pipeline architecture positions ITHAKA to adopt emerging generative AI tools as they become available, without rebuilding core infrastructure. As the economics of AI-driven remediation continue to improve, ITHAKA is working toward costs below $0.01 per page at scale.

The underlying solution remains open source. Other institutions—universities, libraries, government agencies, and nonprofits—facing similar accessibility challenges can adapt it for their own environments and content types. The ADA title II compliance deadline applies broadly, and many organizations hold large PDF collections that need remediation. This post demonstrates that there is an affordable, achievable path to compliance, one that meets users where they are, without the upfront cost of remediating an entire collection. The architecture and approach are designed to be replicable.

Get started

• Learn more about AWS Cloud for Higher Education.
• If your organization is working on document accessibility, fill out the AWS Public Sector – Contact Us form.