Accessible PDFs in editorial workflows: templates, checks and versions

Accessible PDFs do not result from a single export button. They require structured source documents, suitable export methods and checks of the file actually published. The essential ingredient is an editorial workflow that repeats these steps for every new release. Before designing the document, decide who structures the content, who owns the export and what evidence is required for publication approval. An accessible template makes the work easier, but does not replace testing the finished document.

This article focuses on ongoing production: Word templates, tags, reading order, tables, text alternatives, OCR, metadata and versions. The examples are explicitly hypothetical and do not describe client project outcomes. For the legal context, read the Austrian guide to accessible websites. Austria’s BaFG has applied to covered services since 28 June 2025, not automatically to every website or PDF. A technical document audit is also not complete evidence of legal compliance.

Content reviewed: 7 November 2026.

1. First decide whether a PDF is needed

Before creating a file, establish what users need to accomplish. Current opening hours, participation conditions or short instructions are often easier to access and maintain as HTML. A PDF can be useful when a document needs to be downloaded, archived, used offline or cited with stable page references. The decision should follow that use case, rather than a habit of turning every approved text into a downloadable file.

A hypothetical event journey illustrates the difference: someone uses their smartphone to find the venue and register. An HTML page with the address, registration link and current notices directly supports that task. An additional programme PDF can make printing easier. However, it should not be the only way to discover a last-minute change to the starting time. For each publication type, therefore, document which format is authoritative and who carries changes across to the other formats.

2. Define responsibilities and verifiable approval

A workable process distinguishes at least content creation, technical checking and publication. This does not necessarily require three people, but the responsibilities must remain visibly separate. Editors might own headings, understandable link text and technically accurate image descriptions. The reviewer checks the exported file’s structure and usability. The person publishing it ensures that precisely the approved version goes online and is linked with a meaningful description.

Record approval in a short test log. Include the filename, version identifier, template used, export method, test environment, findings and decision. An entry such as “checked” is insufficient. More useful evidence would be: “Table headers associated; second data table manually tested with a screen reader; reference links reachable by keyboard.” Unresolved issues need an owner and a decision about remediation. If a problem prevents an essential task, the affected version should not pass normal publication approval.

3. Build Word templates as editorial tools

A Word template should provide semantic styles for the document title, heading levels, body text, lists and, where needed, captions. A line formatted in large bold type is not yet a structural heading. Use genuine lists rather than manually inserted hyphens, and paragraphs rather than strings of spaces for alignment. Also define how tables of contents, page breaks and headers should be used. This supports consistent design without requiring each document to be assembled individually.

Supplement the template with brief instructions and a separate example document. Show a correctly structured table, a meaningful link and an illustration with a description. Test the template with long titles, additional list levels and tables spanning several pages. These cases reveal whether ordinary editorial changes would push people towards problematic text boxes or manual layout workarounds. The template itself needs a version number and an owner; maintaining it is part of the workflow.

4. Write and design for different ways of accessing content

Editorial decisions affect accessibility before export. Headings should identify the content that follows, references should work without visual location cues, and abbreviations should be understandable. “See the green box on the right” does not work reliably when content is read aloud or displayed differently. A named section with an unambiguous internal link is better. Warnings should likewise communicate their meaning in text, rather than relying exclusively on colour or a symbol.

An assessment against WCAG 2.2 at Level AA includes the applicable Level A and AA requirements. These include sufficient text contrast: generally 4.5:1 for normal text and 3:1 for large text, where large means at least 18 point or 14 point bold. WCAG does not prescribe a particular font family. Readable design helps, but replaces neither document structure nor operability. WCAG and EN 301 549 are not interchangeable either; explicitly define the standard used for assessment.

5. Control the export and the tag tree

Use an export method that carries over the source document’s structural information. A virtual PDF printer may lose that information. Check the actual options available in your software and test the export using a reference file. The internal tag tree describes elements such as paragraphs, headings, lists and tables. Its mere existence does not demonstrate quality: a document tagged entirely as paragraphs can look correct while offering no useful heading navigation.

After export, compare representative locations with the source. Do headings form a meaningful hierarchy? Are lists genuinely represented as lists? Are repeated headers and footers appropriately treated as decorative or recurring artifacts without hiding important information? Wherever possible, correct the source or export process. If a repair is only possible in the PDF, document it and account for it during every subsequent export. Otherwise, the next small text amendment can overwrite the structure that took considerable effort to repair.

6. Test reading order and navigation as a user journey

Visual placement does not reliably indicate the order in which assistive technologies present content. Columns, side notes and text boxes are particularly vulnerable to becoming disconnected. In a hypothetical information sheet, a screen reader might jump into a side note after the first sentence, then resume halfway through the main paragraph. The remedy is not simply to move the text visually, but to correct the logical structure and sequence, preferably in the source document.

The W3C technique PDF3 explains reading order and logical keyboard navigation. Use it to inform concrete tests: jump from the title to the required heading, read the complete section and reach the link it contains. For longer documents, also check the table of contents and bookmarks. A documented task sequence with expected and observed behaviour provides useful acceptance evidence. This informative technique is neither the only permitted method nor proof of PDF/UA certification.

7. Simplify tables and check relationships

Tables need identifiable relationships between headers and data cells. Visually highlighting the first row is not enough. Avoid using tables for layout and avoid unnecessary merged cells. If several levels of column headers appear necessary, first consider whether multiple simpler tables would be clearer. The underlying meaning must remain intact; simplification must not omit essential relationships. Explicitly state units and explain what missing values mean.

The W3C technique PDF6 describes relationships between Table, TR, TH and TD structures. A hypothetical test task could be: “Find the registration deadline for course B without looking at the table.” If navigation does not communicate the relevant row and column headers, the problem remains unresolved despite the presence of table tags. Check the associations in the PDF and repeat the task using assistive technology. Also inspect continuations across page breaks rather than approving only the first table row.

8. Make links and illustrations understandable

Link text should communicate the destination or the action it enables. “Workshop registration form” is more useful than repeated instances of “here”. Check that a link is actually available as an interactive element in the PDF, makes sense in its structural context and can be reached by keyboard. A readable web address may additionally help people using a printout. A QR code alone does not replace an accessible link, however; its destination and purpose must remain understandable without a camera.

An image’s function determines its alternative. A decorative shape does not need a spoken description, whereas an informative photograph needs an appropriate textual equivalent. A short alternative text is often insufficient for a complex chart: add a summary of its meaning and, where necessary, the underlying data as an accessible table. Describe the relevant message, not merely colours and shapes. Subject-matter editors must verify that message; automatically generated descriptions without content review do not provide a dependable basis for approval.

9. Treat OCR and metadata as separate tasks

OCR turns scanned characters into recognised text, but does not automatically create a reliable document structure. A searchable scan can still contain incorrect reading order, missing headings and inaccessible tables. Pay particular attention to numbers, dates, special characters and word breaks. In a hypothetical historical form, a misrecognised digit could change a deadline. A simple success notification from the OCR software would not be sufficient evidence. If a suitable original file exists, revising it is usually the more controllable approach.

Also enter a meaningful document title and the correct primary language; passages in other languages may need appropriate language identification. Align the visible title, metadata and download label. Inspect security settings for restrictions that could interfere with assistive technology access. Interactive PDF forms introduce additional requirements for labels, field order, instructions and understandable error feedback. These documents need their own testing scope; a template for static reports does not automatically cover them.

10. Combine automated and manual checks

Check the source document first, then the exported PDF and finally the published file. Automated tools reliably identify certain structural problems, but cannot fully judge whether an image description is accurate or a reading path makes sense. The W3C guidance on selecting evaluation tools emphasises these limitations. A report showing no errors is therefore part of the assessment, not its conclusion. Also record the software and viewer versions used.

Add visual inspection, magnification, keyboard operation and screen reader tasks. A hypothetical acceptance test could cover three journeys: finding an eligibility condition, understanding a table value together with its header, and opening a related link. For each failure, document its location, impact, correction and retest. After correction, also test neighbouring content: changing a table structure can affect other cells. Manual review of long documents can be organised according to risk, but a sample must not be presented as a complete assessment of every page.

11. Version the source, export and evidence together

Keep the source file, template version, PDF and test log together as one release. The version identifier must make their relationship unambiguous, even when the public download remains at the same address. A change log should distinguish between changes to content, layout, structure and metadata alone. This distinction supports planning the next round of testing, but does not remove the need for it: even an additional paragraph can trigger a page break and problematic table continuations.

Also define how withdrawn versions are handled. Do not only replace the download on an overview page; check direct links, embedded references and, where relevant, cached files. If a correction is exceptionally made only in the PDF, flag that special case in the version record. Before the next release, establish how it will be reproduced or transferred into the source. This prevents an editorially current file from technically regressing behind a version that had already been improved.

12. Keep HTML alternatives and editorial work synchronised

An HTML alternative is useful when it provides the same essential information and functions and is easy to find. A short summary does not replace a full report when users need specific conditions or data from it. Clearly link related versions and identify the file format at the download. Define how updates reach both representations. Otherwise, conflicting information leaves users guessing which version is authoritative or current.

Plan renewed testing particularly when templates, export software or document types change. A fixed review frequency can be organisationally useful, but is not a universal monthly or annual WCAG requirement. The W3C guidance on sustaining accessibility emphasises ongoing checks, training and addressing root causes. Zensations’ work for FFG included evaluating websites and tools, alongside editorial workshops covering PDFs. This illustrates the connection between technical and editorial work without implying particular outcomes or a current conformance status.

Frequently asked editorial questions

Is an accessible Word template enough?

No. The template provides a foundation. Inserted content, individual formatting and export can introduce new barriers. Check the finished PDF and the actual download as well.

Is a PDF accessible after OCR?

No. OCR provides recognised text. Structure, sequence, table relationships and text alternatives must additionally be created or checked. The accuracy of text recognition is also part of acceptance testing.

Does every small change require another check?

Every new release needs traceable approval. The scope of retesting depends on the change and its risks. At minimum, inspect the affected areas and possible consequences for structure and export.

Can HTML replace a problematic PDF?

HTML is often the better primary format. Whether an alternative is sufficient in a particular case depends on equivalent information, functionality and applicable requirements. Adding a link does not automatically remove the PDF’s barriers.

Next step: Establish a sound process for one document type

Start with a regularly published document type and gather its source, template, PDF and existing test evidence. Zensations, a digital studio founded in Vienna in 2010, can examine the technical starting point through an accessibility audit and support a suitable editorial workflow through its accessibility services. The aim is a traceable working foundation with concrete improvements, not a blanket guarantee of conformity.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — normative requirements.
• W3C: PDF3 — reading order and keyboard navigation.
• W3C: PDF6 — table structure and cell relationships.
• W3C WAI: Selecting Web Accessibility Evaluation Tools — capabilities and limitations of evaluation tools.
• W3C WAI: Sustain Accessibility — maintaining accessibility within an organisation.