Accessible PDF Documents in the Shop: Invoices, Catalogs, Data Sheets

1. Why PDF documents in the shop are so often overlooked entirely

Accessibility projects almost always focus on a shop's HTML pages: contrast, forms, keyboard operability. PDF documents such as invoices, product data sheets, or seasonal catalogs frequently fly completely under the radar, even though they're legally subject to the same requirements as the website itself once they're made available through a publicly accessible or customer-facing surface.

The problem is compounded by the fact that PDF documents in Magento stores are rarely created manually, but generated automatically from templates, say invoices via the built-in PDF engine or data sheets via an export module. If the underlying template isn't built accessibly, thousands of inaccessible documents get produced without a single human ever laying eyes on the individual file.

2. The PDF/UA standard: what it concretely requires

PDF/UA, officially ISO 14289, defines precise technical requirements for accessible PDF documents, making it to PDF what WCAG is to HTML pages. Among other things, the standard requires a complete tag structure in which every visible element is mapped to a semantic tag, a logical reading order defined independently of the visual layout, and alternative text for all information-carrying images and graphics.

PDF/UA additionally requires correctly marked-up tables with header cells, a language declared in the document so screen readers pick the right pronunciation, and searchable, real text instead of rasterized image data. A document meeting these criteria can be validated automatically with a tool like the PAC checker, which makes PDF/UA considerably more verifiable than vague accessibility promises.

3. Tagged PDFs versus scanned images: the fundamental difference

A scanned invoice or a scanned data sheet is, from the PDF format's point of view, nothing but an image, regardless of how clear and readable the text on it looks to a sighted user. A screen reader can't extract any text content from such an image unless optical character recognition has been run beforehand, and even then that process delivers no semantic structure such as headings or tables.

A tagged PDF, by contrast, contains an invisible structure overlaid on the visible layout, the so-called tag tree, in which every element is marked as a heading, paragraph, table, list, or image. That structure is exactly what a screen reader reads out, independent of the visual arrangement on the page, and that structure is exactly what's completely missing from a plain image PDF, even once OCR has added a searchable text layer after the fact.

4. Auto-generated Magento invoice PDFs: the core problem

Magento's built-in PDF generation for invoices, shipments, and credit memos relies on a simple, coordinate-based drawing logic: text, lines, and table cells get drawn at fixed X and Y positions on the page, with no semantic tag structure resulting from that process. To a sighted user the result looks like a neat, tabular invoice, but to a screen reader it's merely a collection of individual, unconnected text fragments with no discernible order or table structure.

Whoever swaps out the underlying PDF generator directly can close this gap technically, say by switching to a library like mPDF that, in its UA-compliant mode, converts HTML source with semantic tags into a tagged PDF structure instead of blindly drawing coordinates onto a blank page.

<?php

declare(strict_types=1);

namespace Mironsoft\SeoSuite\Model\Pdf;

use Mpdf\Mpdf;

/**
 * Generates tagged, PDF/UA-compliant invoices from semantic HTML instead
 * of coordinate-based drawing commands.
 */
class AccessibleInvoicePdfGenerator
{
    /**
     * Renders an accessible invoice PDF from semantic HTML markup.
     *
     * @param string $invoiceHtml Semantic HTML with a table/th/caption structure.
     * @param string $language Language code for the document tag, e.g. "en".
     * @return string Binary PDF content.
     */
    public function generate(string $invoiceHtml, string $language = 'en'): string
    {
        $mpdf = new Mpdf([
            'mode' => 'utf-8',
            'format' => 'A4',
            // Enables the internal tag tree generation instead of pure
            // coordinate output.
            'tag_mode' => true,
        ]);

        $mpdf->docLang = $language;
        $mpdf->SetTitle('Invoice');

        $mpdf->WriteHTML($invoiceHtml);

        return $mpdf->Output('', 'S');
    }
}

5. Tools for post-processing: the Adobe Acrobat tags panel

When the PDF generator can't be swapped out directly, or an existing stock of PDF documents needs fixing, manual or semi-automatic post-processing via Adobe Acrobat Pro remains the option. The Accessibility Check tool first automatically produces a rough tag tree, which can then be refined manually in the tags panel: fixing misdetected heading levels, adding missing table tags, adjusting reading order via drag and drop.

Correctly marking up tables with TH cells for header rows is especially important in the tags panel, since Magento invoices typically contain multiple tables, say for line items, shipping costs, and payment data, which turn into a meaningless pile of individual numbers for screen reader users without a clean tag structure. On top of that, the alt text assistant lets a matching alternative text be assigned to every logo and graphic in the document.

6. PAC checker: automated PDF/UA conformance testing

The PAC checker, provided free of charge by the Access for All foundation, automatically tests a PDF document against the technical criteria of PDF/UA and reports concrete, severity-sorted errors such as missing alt text, an undeclared document language, or an incomplete tag structure. Unlike a purely visual check, PAC delivers an objective, reproducible test result that can be integrated into a quality assurance process for automatically generated invoices as well.

In practice it's worth running the PAC checker not just once when a new PDF template is introduced, but on a spot-check basis after every major Magento update too, since changes to the underlying PDF library or the invoice layout can quietly undo previously achieved conformance without anyone noticing.

7. Catalogs and data sheets: the editorial workflow

Unlike automatically generated invoices, product catalogs and technical data sheets are usually built in a layout program like Adobe InDesign before being exported as PDF. That export step is exactly where it's decided whether the result ends up accessible: InDesign lets paragraphs, headings, and tables be given semantic roles right in the layout, which then carry straight through into the PDF/UA structure on export instead of having to be laboriously reconstructed in Acrobat afterward.

For editorial practice this means accessibility shouldn't happen as a fix at the end of a catalog project, but needs to be considered while the InDesign template itself is being built, including consistently using paragraph style export mapping and a sensible reading order for multi-column layouts.

8. Practical case: making a Magento invoice PDF accessible step by step

The most pragmatic path for an existing Magento store combines both approaches: rebuilding the PDF generator so it produces a tagged base structure from the start, and spot-checking with PAC afterward to catch regressions early. In the first step, the existing invoice template gets replaced by an HTML-to-PDF pipeline built on a semantic HTML structure with table, th, caption, and correctly nested headings, as shown in the following excerpt of a line item table.

In the second step, every logo and graphic in the invoice header gets an alt text, the document language is explicitly set to English, and the reading order is defined to match the visual order: sender details first, then invoice number and date, then the line item table, and finally the payment information. A subsequent test run with PAC confirms whether the generated invoice is actually UA-1 compliant before the new template goes live.

<table>
  <caption>Line items for invoice no. 2026-04871</caption>
  <thead>
    <tr>
      <th scope="col">Item</th>
      <th scope="col">Quantity</th>
      <th scope="col">Unit price</th>
      <th scope="col">Total price</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Safety shoe S3, size 43</td>
      <td>2</td>
      <td>89.90 EUR</td>
      <td>179.80 EUR</td>
    </tr>
  </tbody>
</table>

9. Alternative: offering HTML invoices instead of PDF

Besides retrofitting existing PDF templates, it's worth asking the more fundamental question of whether a PDF invoice is even the right output format at all. An invoice rendered as a regular HTML page in the customer account automatically benefits from every accessibility measure already implemented for the rest of the store, say correct heading hierarchy, keyboard operability, and responsive layout, without a separate PDF pipeline needing to be maintained.

For many stores a hybrid approach therefore makes sense: a well accessible HTML view of the invoice as the primary presentation in the customer account, supplemented by an optional PDF download for bookkeeping purposes, which should still be built PDF/UA compliant but no longer represents the only available presentation of the invoice data.

The table below compares the tools covered here and their typical use cases.

10. Summary

11. FAQ: Accessible PDF Documents: The Essentials at a Glance