A PDF can look organised and professional while being difficult to use with a screen reader, keyboard or other assistive technology. The problem often starts long before export.
Accessibility is therefore not primarily about repairing a finished PDF. It needs to be built into the source document.
Start with structure
W3C's WCAG2ICT guidance explains how WCAG principles can apply to documents outside the web. In practice, information needs a structure software can understand, rather than only a visual form that looks right.
A document built from separate text boxes, manual line breaks and subheadings made merely larger and bolder becomes harder to interpret and repair later.
Paragraphs, heading levels, lists and tables should therefore be defined as what they are in the original file.
The reading order needs to make sense
In a complex layout, the eye can move naturally between a heading, introduction, main text and fact box. A screen reader depends more on the document's structural order.
W3C describes a meaningful sequence as an order that preserves the meaning of the content. For tagged PDFs, the tag structure and reading order therefore become part of the content itself.
This matters particularly in reports, brochures and other documents with columns, graphics or page elements. A simple check is to consider how the page would work if all its content were read aloud from beginning to end.
Headings need to be coded as headings
Large type and bold weight are visual signals. They do not automatically make text a structural heading.
Correct heading levels make a document's organisation easier to understand and its sections easier to navigate. The same applies to lists and tables: their structure should be real, rather than visually imitated.
The image's purpose determines its text alternative
A decorative image and a chart containing important information have different jobs.
Images conveying content need a text alternative that makes the relevant information available without the image. Purely decorative elements should not create unnecessary noise for assistive-technology users.
Complex figures may need more than short alt text. The explanation can then be provided in the main text or a fuller description.
Checking tools are the final step
InDesign and Acrobat support tags, document language, titles, reading order and accessibility checks. These tools are useful, but cannot automatically make a poorly organised original file logical.
Adobe also emphasises that some issues require manual assessment. The most robust workflow is therefore to build the document correctly, export with the right settings and use checking tools for quality assurance.
Norwegian requirements make this practically relevant
Digdir sets requirements for text documents public-sector organisations publish online and refers to WCAG. Accessibility depends partly on how a document is produced.
Private businesses are not necessarily subject to the same document requirements in every situation. The principles are still useful for reports, product sheets, manuals and presentations because they produce documents that are easier to read, navigate and reuse.
Check before publishing
Before publishing an important PDF, check:
- that heading levels are logical
- that the reading order makes sense
- that informative images have useful text alternatives
- that tables are built as tables
- that link text describes the destination
- that document language and title are set
- that text and contrast are readable
- that tags and structure are included in the export
- that an automated check finds no obvious errors
- that key pages also work during manual review
An accessible PDF is the result of an organised production process, rather than a final repair round.
