PAC 2024 Says Your PDF Fails WCAG 1.4.10 Reflow — Here Is How to Fix It
You ran PAC 2024 on your PDF and got a failure you did not expect. The report flags WCAG Success Criterion 1.4.10 Reflow and marks it as a critical error. Every other check passed. Tagging looks fine. Reading order is correct. But 1.4.10 is red.
Here is why this happens, why the usual remediation tools cannot fix it, and what you actually need to do.
What PAC 2024 Is Telling You
PAC 2024 (PDF Accessibility Checker) is the standard tool for pre-submission compliance checking under PDF/UA and WCAG 2.1. When it flags 1.4.10, the report typically reads something like: “Content is not fully available at a viewport width of 320 CSS pixels without horizontal scrolling.”
That is not a tagging error. It is not a reading-order problem. PAC is identifying a structural constraint in the file format itself — and it is right.
What WCAG 1.4.10 Actually Requires
WCAG Success Criterion 1.4.10 Reflow (Level AA) requires that content can be presented “without loss of information or functionality, and without requiring scrolling in two dimensions” when the viewport is 320 CSS pixels wide. For vertical scrolling content, that means no horizontal scroll at 320px width. For horizontal content, no vertical scroll at 256px height.
The intent is simple: users who zoom their browser to 400% — or use a small-screen device — must be able to read your content without scrolling left and right. Every line. Every table cell. Every column.
This is not a cosmetic issue. For users with low vision who rely on extreme zoom, horizontal scrolling breaks reading flow entirely. It is a real barrier.
Why PDFs Cannot Satisfy 1.4.10
A PDF is a fixed-layout format. Every element — every line of text, every image, every column — is placed at an absolute position on a page with fixed dimensions. When you open a PDF, you are looking at a digital reproduction of a printed page. The page is, say, 612 by 792 points (US Letter). That dimension does not change.
When a PDF viewer renders that page at 400% zoom on a 320px-wide viewport, the viewer must either shrink the page (making text tiny and defeating the purpose of zooming) or show only a portion of the page (requiring horizontal scroll). There is no third option. The format does not allow content to reflow into the available space.
Tagged PDFs can satisfy many WCAG criteria. Tags give structure to reading order, headings, and alt text. But tags do not change the page geometry. A perfectly tagged PDF still has fixed layout. WCAG 1.4.10 requires the layout to adapt. PDFs cannot adapt their layout. This is not a bug in your PDF — it is the definition of the format.
Why PDF Remediation Tools Cannot Fix This
If you have tried to fix a 1.4.10 failure in Acrobat Pro, PDFix, or CommonLook, you have hit a wall. These tools are excellent at what they do: adding tags, fixing reading order, setting language, labeling tables. They operate on the PDF structure layer.
None of them can fix 1.4.10. The failure is not in the tags. It is in the coordinate system. To satisfy 1.4.10, content must be able to flow into a narrow column. A PDF’s content stream is a list of draw commands with absolute coordinates. Remediation tools do not rewrite those coordinates — and even if they did, the result would not be a valid PDF.
CommonLook’s own documentation notes that 1.4.10 compliance requires a reflowable format. The Acrobat accessibility guide acknowledges the same limitation. If a vendor is promising you a PDF that passes 1.4.10, ask them to demonstrate it in PAC. The check will still fail.
The Only Real Fix: Convert to a Reflowable Format
WCAG 1.4.10 is solvable. You just need to change the format.
EPUB3 and HTML are reflowable by design. Content in an EPUB3 file is stored as HTML and CSS. When the reading system displays it at 320px width, the text wraps. Tables scroll or collapse. Images scale. No horizontal scroll. PAC 2024 does not check EPUB files — but EPUB validators (EPUBCheck, Ace by DAISY) do, and a properly structured EPUB3 satisfies 1.4.10 natively.
This matters for compliance. Under the European Accessibility Act (EAA), which entered enforcement in June 2025, digital documents distributed to consumers must meet WCAG 2.1 AA. Organizations that relied on PDF for document delivery are now in scope. 1.4.10 is Level AA. It counts.
Converting to EPUB3 is not a workaround — it is the correct technical answer to a fixed-layout problem.
How to Convert with toolkit.bot
If you have a PDF that fails 1.4.10 and need a reflowable version, toolkit.bot/pdf2epub converts it in your browser. No software to install. No account required for the free tier.
Upload your PDF, run the conversion, and download an EPUB3 file. The converter handles text extraction, heading detection, table structure, and image placement. For scanned PDFs with no text layer, it falls back to OCR.
The resulting EPUB3 can be validated with EPUBCheck or Ace by DAISY. It will not carry a 1.4.10 failure, because the format itself is reflowable.
Fix the Format, Not the Tags
PAC 2024 is giving you an accurate diagnosis. WCAG 1.4.10 failures in PDFs are not fixable with remediation — they require a format change. If you are distributing documents that need to meet WCAG 2.1 AA, EPUB3 or HTML is the path. PDF is not.
Convert your PDF to reflowable EPUB3 — no more 1.4.10 failures. Free, no account required.
Convert a PDF → WCAG 1.4.10 technical explainer →