PDF Accessibility for E-Commerce: Making Size Guides, Spec Sheets, and Policy Documents Usable

Quick answer: A PDF linked from a product or support page is still “web content” once it’s on the site, and WCAG applies to it the same way it applies to any HTML page. Most e-commerce PDFs — size guides, spec sheets, warranty and return-policy documents, assembly instructions — are exported straight from a design or word-processing tool with none of the underlying structure (headings, reading order, image descriptions, table markup) preserved, which is what makes a PDF “accessible” or not. The result is a document that looks fine on screen but is either silent or unusable to a screen reader. Fixing it means going back to the source file, not patching the PDF after the fact.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for downloadable documents and how to implement it, not whether a specific site carries legal risk.

Why a PDF can look right and still fail

A PDF has three layers doing different jobs, a distinction WebAIM’s PDF accessibility guide lays out directly: a visual layer that determines how the page looks, a content layer that holds the actual text, fonts, and images, and a tags layer that “contains the document’s structure, including headings, links, lists, and tables” and is what assistive technology actually reads from. Export a size guide from a design tool without setting up structure first, and you can get a visual layer and a content layer that look and read perfectly well on screen — while the tags layer is empty or missing entirely.

That gap matters because WebAIM states it plainly: “an untagged PDF would not be considered ‘accessible.’” A screen reader opening an untagged PDF has no heading to jump to, no way to tell a data table from a wall of text, and — worst case, if the PDF is a scan of a printed page — no selectable text at all, just an image the software can’t read out loud.

The specific fixes, mapped to WCAG success criteria

The W3C’s PDF Techniques for WCAG 2.0 lists the concrete techniques that satisfy WCAG’s success criteria inside a PDF. The ones that come up constantly in e-commerce documents:

Alt text for images (SC 1.1.1, technique PDF1)

WCAG SC 1.1.1 Non-text Content (Level A) requires that non-text content have a text alternative “that serves the equivalent purpose.” Inside a tagged PDF, that’s set via an /Alt entry on the image’s structure element — the PDF equivalent of an <img alt=""> attribute. A spec sheet’s exploded diagram or a size guide’s measurement illustration needs the same kind of description a webpage image would: what it shows and why it’s there, not “image1.png.”

Heading structure (SC 2.4.6, technique PDF9)

WCAG SC 2.4.6 Headings and Labels (Level AA) requires headings and labels that “describe topic or purpose.” A multi-page spec sheet or return-policy document needs real H1–H6 tags on its section titles, the same way an HTML page needs an <h1>/<h2> hierarchy — not larger, bolder body text that only looks like a heading. Without the tag, a screen reader user loses the ability to jump between sections entirely and has to listen through the whole document top to bottom.

Table markup (SC 1.3.1, technique PDF6)

WCAG SC 1.3.1 Info and Relationships (Level A) requires that structural relationships “can be programmatically determined.” A size chart or spec table needs Table/TR/TH/TD structure tags so a screen reader can announce a cell together with its row and column headers (“Chest, Medium: 40–42 inches”) instead of reading every number in the grid as one undifferentiated stream.

Reading order (technique PDF3)

Design tools place content by visual position, not logical order. A two-column spec sheet or a page with a pull-quote box can end up with a tags-layer reading order that jumps between columns mid-sentence, even though it looks fine visually. PDF3 covers setting the actual tag order to match the order a sighted reader would follow, which has to be checked and fixed by hand — no export setting gets this right automatically for anything beyond a single column of text.

Document language (SC 3.1.1, technique PDF16)

WCAG SC 3.1.1 Language of Page (Level A) requires that “the default human language… can be programmatically determined” — set in a PDF via the /Lang entry in the document catalog. Without it, a screen reader may guess wrong and read an English spec sheet with a French or German pronunciation engine, or vice versa.

The fix that actually works: start in the source file

WebAIM’s guide to converting documents to PDF lays out the order of operations: build accessibility into the Word, PowerPoint, or other source file before export, rather than retrofitting a finished PDF. As WebAIM puts it, “a document created with accessibility in mind in Word should contain almost all the information necessary for an accessible PDF” — headings, image alt text, table structure, and lists all generally carry through cleanly on export. In practice, that means:

• Use the source application’s built-in heading styles, not manually bolded/enlarged text that only looks like a heading.
• Add alt text to images in the source file — it’s one of the elements that carries through to the exported PDF’s tags automatically once it’s there.
• Use real table tools (not tab-separated text or a screenshot of a spreadsheet) for any size chart or spec table.
• Export with structure tags enabled — in most tools this is an explicit “tagged PDF” or “accessibility tags” checkbox in the export dialog, not the default.
• Don’t use “Print to PDF.” WebAIM is direct about this one: “Never create a PDF with the ‘Print’ option in Office, or in any other program. A screen reader user may still be able to access the text of a PDF created in this way, but heading structure, alternative text, and any other tag structure is lost.”

Retrofitting tags into a PDF that’s already exported is possible with tools like Acrobat Pro’s tag editor, but it’s slower and more error-prone than exporting correctly the first time — the same reason WebAIM’s guide recommends fixing the source file, not the output.

Scanned documents need OCR, not just a tag pass

A warranty card or return form that’s a photograph or scan of a printed page has no real text at all — just an image. W3C technique PDF7 covers running optical character recognition (OCR) on a scanned PDF to generate actual, selectable text before any tagging work can happen. No amount of tag editing fixes a document that has no underlying text to tag.

What a scan catches here, and what still needs a person

An automated accessibility scanner running against a webpage generally can’t open and evaluate a linked PDF’s internal tag structure at all — it can flag that a link points to a .pdf file, but whether that file is tagged, has correct reading order, or carries real alt text on its images is outside what a page-level scan checks. That’s exactly the kind of gap a manual review closes: open the file, check for a tags panel (Acrobat’s own built-in accessibility checker will report “document has no tags” if none exist), and spot-check a data table or diagram against what a screen reader actually announces.

FAQ

Does every PDF on an e-commerce site need to be tagged? Any PDF that conveys content a shopper needs — size guides, spec sheets, warranty terms, return policies, assembly instructions — falls under the same WCAG requirements as an HTML page. A decorative or purely visual asset wouldn’t carry the same requirement, but that’s rare for the kinds of PDFs e-commerce sites actually link.

Is it better to just publish the content as an HTML page instead of a PDF? Often, yes. PDF accessibility work is generally harder to get right than HTML, and a size chart or return policy built as a regular page is usually easier to make accessible — and easier to keep accessible as it’s updated — than a PDF re-exported from a design file each time it changes. PDFs make sense for printable formats (assembly instructions someone wants on paper); marketing and policy content usually doesn’t need to be a PDF at all.

Can Acrobat’s accessibility checker confirm a PDF is fully accessible? It catches a meaningful subset — missing tags, missing alt text, missing document language — but it’s a rules-based check, the same kind of gap that exists between an automated HTML scanner and a full manual review. A clean checker report is a good sign, not a guarantee that a screen reader user can actually navigate the document well.

Get your linked documents checked, not just your pages

Quietramp’s $890 audits include the PDFs and downloadable documents linked from a site, not just its HTML pages — checked with a real screen reader, not just a scanner’s page-level report. See a real sample report or check pricing.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.