Designing for PDF accessibility

Over a couple of weeks, we interviewed around ten customers, many responsible for coordinating accessibility across large organisations.

We learned that responsibility often sat with a central digital or accessibility team, while documents were created across many departments. These teams had to fix documents themselves, coordinate with colleagues or pay external specialists. Identifying problems was only part of the challenge; resolving them across large document libraries was a major bottleneck.

Mapping the customer journey helped us understand the challenges across the document lifecycle, from checking PDFs before publication to addressing issues in existing documents. We also identified foundational problems, such as missing document structure and image descriptions, that could make PDFs difficult to navigate with assistive technology.

This research gave us a broader understanding of the problem and helped us identify opportunities to make both finding and fixing accessibility issues easier.

I led the design of the validation experience, working closely with the product manager, developers and quality engineers.

One key decision was where validation should live. The initial suggestion was to add it to a side panel on the existing PDF page. I was concerned this would make the feature easy to miss and blur two different tasks: checking a new document before publication and reviewing issues in a document already online. After involving the wider UX team, we aligned around a dedicated page.

I worked with developers and quality engineers to clarify interactions, states and edge cases, and with Marketing and Translation to settle on straightforward feature naming for an international audience.

Moving from finding issues to fixing them.

After validation launched, we moved on to the next opportunity: helping customers fix accessibility issues across multiple PDFs.

Building on our earlier research, we explored an experience that could remediate one or more PDFs, automatically adding foundational accessibility elements such as document tags and image alt text. Customers could then review a report of the proposed fixes and download the remediated documents.

The aim was to automate time-consuming fixes and make documents more accessible at scale, while recognising that more complex issues might still require manual attention.

I created an interactive prototype using Figma Make and tested it with customers. To evaluate the quality of the proposed solution using real documents, I also designed an in-product experiment inviting customers to submit three PDFs for remediation and assess the results. The product manager and quality engineers coordinated the manual service workflow behind the experiment.

The project reinforced the value of involving customers throughout the product journey: first to understand where they struggle, then to test whether a proposed solution addresses the problem in practice.

It also showed me the cost of discovery running too close to development. With a shifting roadmap and pressure to build, new findings could mean reworking decisions late in the process. Given the chance to do it again, I would advocate for more time to explore and validate the riskiest assumptions earlier, while still leaving room to learn as the work progresses.