How to Check PDF Accessibility: A Publisher’s QA Guide

How to Check PDF Accessibility: A Publisher’s QA Guide

A PDF can look perfect and still be difficult to use with a screen reader.

That is why checking PDF accessibility requires more than looking at the page or running one automated test.

Publishers need to check the document structure, headings, reading order, images, tables, links, navigation, and other elements that assistive technology depends on.

A PDF accessibility checker is a useful first step. It is not the final test.

A stronger process combines automated checks with manual review and, for complex documents, human accessibility testing.

What does checking PDF accessibility actually mean?

Checking PDF accessibility means finding out whether people using assistive technologies can understand and navigate the document.

A good review asks two different questions.

First:

Is the PDF technically structured correctly?

Then:

Does that structure make sense to a real reader?

Those questions are related, but they are not the same.

For example, a checker may confirm that a table contains tags. A human reviewer still needs to know whether the right cells are treated as headers and whether the relationships make sense.

W3C’s PDF techniques cover areas such as image alternatives, bookmarks, reading order, tables, OCR, headings, links, and form controls. W3C

1. Start with a PDF accessibility checker

An automated PDF accessibility checker can identify many common technical problems quickly.

It may flag missing document language, missing tags, structural errors, image issues, or other conditions that need attention.

This is useful because large documents can contain hundreds of elements. Automated checking helps teams find obvious problems before manual QA begins.

But a clean result does not prove that the PDF is fully accessible.

Automated tools cannot reliably judge every issue involving context and meaning.

A useful workflow is:

Automated Check → Manual Review → Assistive-Technology Test → Correct → Retest

This prevents the checker from becoming the only measure of success.

2. Check whether the PDF has useful structure

An accessible PDF needs more than visible formatting.

A heading that looks large and bold should also be represented as a heading in the document structure.

The same applies to paragraphs, lists, figures, tables, and other content.

W3C specifically includes techniques for marking headings correctly in PDF documents. Logical heading levels help users understand how sections relate to one another. W3C

For publishers, the main question is:

Does the underlying structure describe the document accurately?

A visually polished report can still fail this test.

3. Check the reading order

Reading order is one of the most important parts of PDF accessibility testing.

Consider a research article with two columns.

A sighted reader knows to move down the first column before starting the second.

Assistive technology follows the underlying document order instead.

If that order is wrong, sentences from separate columns can become mixed together. Captions, sidebars, footnotes, or forms may also appear at the wrong point.

W3C explains that logical reading and tab order need to follow the meaning of the content. It recommends checking the document with a screen reader or another tool that exposes the reading sequence.

For QA, ask:

If I listen to this document without looking at the page, does the content still make sense?

That simple test can reveal serious problems.

4. Check headings and navigation

Headings give readers a map of the document.

In a long report or academic publication, they help users understand the hierarchy and move between sections.

Check that heading levels follow a logical order.

For example:

H1 should represent the main document or major section level.

H2 should normally sit below H1.

H3 should sit below H2 where appropriate.

The structure should reflect the content rather than simply matching font size.

Bookmarks and useful navigation can also make long PDFs easier to use.

A document that contains hundreds of pages but no useful navigation creates unnecessary work for readers.

5. Check images and alternative text

Not every image needs the same treatment.

A decorative image may not need a meaningful description.

A chart, diagram, map, scientific image, or educational illustration may carry important information.

For those visuals, check whether the alternative text explains what the reader needs to know.

Do not judge accessibility only by asking:

“Is alt text present?”

Instead ask:

“Does the alt text communicate the purpose of this image?”

An empty or generic description can pass a basic structural check while still providing very little value.

6. Check tables carefully

Tables require more than visible borders.

A reader needs to understand which headers belong to which data.

W3C’s PDF table technique explains that tabular relationships should remain available even when users cannot see the table visually. W3C

For a simple table, row and column headers may be straightforward.

Complex tables may contain grouped headings, merged cells, notes, or several header levels.

Those tables need deeper review.

Gentize already has a separate article on accessible PDF table remediation, so the role of this article is to explain what to check, not repeat the full remediation process. Gentize Innovations

7. Check scanned PDFs and OCR quality

A scanned PDF may contain no real text at all.

It can look like a normal document while every page is actually an image.

OCR can convert scanned content into machine-readable text, but OCR output needs verification.

W3C includes OCR as a PDF accessibility technique for scanned documents. It also notes that recognition errors may need correction before the content can be relied on. W3C

For publishers, check names, numbers, punctuation, symbols, and table values carefully.

A searchable PDF is not automatically an accessible PDF.

8. Check links and interactive elements

Links should make sense when read out of context.

A phrase such as:

“Read the accessibility guidelines”

is more useful than:

“Click here.”

Forms and other interactive elements also need correct labels and a logical focus order.

Keyboard users should be able to move through interactive content in a sequence that matches the document.

W3C connects logical tab order with accessibility for keyboard and assistive-technology users. W3C

9. Compare the PDF with the required accessibility standard

The correct test depends on the target.

A project may need to consider WCAG, PDF/UA, Section 508, or customer-specific requirements.

These should not be treated as identical.

Gentize’s existing PDF/UA-1 vs PDF/UA-2 guide covers the difference between the two PDF/UA generations in more detail. Gentize Innovations

For this QA process, the important lesson is simple:

Know the target before you decide what “pass” means.

Otherwise, a document may be checked against the wrong acceptance criteria.

10. Test with assistive technology

This is where technical checking becomes real usability testing.

For complex or high-value documents, representative screen-reader and keyboard testing can reveal issues that automated tools may miss.

A document may technically contain all expected elements and still be difficult to use.

Human testing can reveal confusing reading order, weak table context, poor image descriptions, or navigation that requires too much effort.

Gentize has 50+ accessibility testers with visual impairments supporting human-led accessibility QA. Pasted markdown

The aim is not to replace automated tools.

It is to add the human evidence that automated testing cannot provide.

What should happen when a PDF fails accessibility checks?

A failed check should lead to remediation and retesting.

Do not correct one issue and assume the document is finished.

A structural change can affect reading order. A table correction can change how content is announced. A new description may need another review for context.

A practical cycle is:

Find → Fix → Review → Retest → Approve

This is especially important in large publishing programmes where the same issue may appear across many documents.

If a defect keeps returning, update the production rule rather than correcting it file by file forever.

How Gentize supports PDF accessibility testing

Gentize supports PDF tagging, reading-order correction, document structure, alternative text, accessible tables, screen-reader testing, keyboard testing, and human accessibility QA.

Gentize’s wider accessibility service also uses manual assistive-technology testing across representative screen-reader and keyboard environments. Gentize Innovations

This allows PDF accessibility testing to cover both technical structure and the reading experience.

For publishers managing many documents, the same QA approach can also support larger remediation and backlist programmes.

Final takeaway

Knowing how to check PDF accessibility means knowing where automated testing ends and human judgment begins.

A checker can find many technical problems.

Manual QA can examine structure and meaning.

Assistive-technology testing can show whether the document actually works for readers.

The strongest workflow is:

Check → Inspect → Test → Fix → Retest

And the final question should not be:

“Did the PDF accessibility checker show green?”

It should be:

“Can the reader understand and navigate the document successfully?”

That is the standard a meaningful PDF accessibility check should aim to meet.