Making a tagged, accessible PDF in Layout by Zaweba
Layout by Zaweba builds tagged PDFs itself, with reading order, H1 to H6 headings from styles, lists, table headers, alt text and decorative marking.
Many organisations now have to publish documents that everyone can read, including people who use screen readers. A PDF that only looks right on screen isn't enough; it needs a structure underneath that says what is a heading, what is a list, which cells are headers and what each picture shows. Layout by Zaweba builds that tagged PDF itself when you export, from the information you put into the document.
What goes into the tags
The reading order tells assistive technology which order to read the content in, which on a magazine page with sidebars and captions isn't always top to bottom. Headings are tagged H1 to H6 from your paragraph styles, so a screen reader user can jump from heading to heading as easily as a sighted reader scans the page.
Lists are tagged as lists, so their structure is announced. Tables are tagged with header cells and summaries, so each data cell can be read with its row and column headings. Figures carry alt text. Notes and links are tagged too.
Setting tags from paragraph styles
Export tagging is set per paragraph style. In each style you can choose the tag and class it exports with. Set your chapter heading style to H1, section headings to H2, and so on, and every heading in the document is tagged correctly with no extra work at export.
That is the main reason to use styles consistently. A heading made by hand with bold text and a bigger size looks like a heading but has no style to tag it, so it exports as an ordinary paragraph.
Alt text and decorative objects
Every picture that carries meaning needs alt text: a short description of what it shows and why it's there. A chart's alt text should give its point, not just "chart". A photo of a speaker should say who it is.
Decorative objects can be marked as such. Background shapes, dividing rules, ornaments and purely decorative photos are then left out of what is read aloud, which spares screen reader users a stream of meaningless items.
A practical routine for an accessible document
Start with styles. Set up heading levels and map them to H1 to H6 before you build the document.
Check the reading order as you lay out pages, especially where sidebars, pull quotes and captions sit among the main text. Layout has a Reading order panel for this.
Write alt text when you place pictures, not at the end. It is far easier while you remember why each one was chosen.
Mark decorative items as you make them.
Give tables proper header rows and add summaries.
Fill in File info, such as title, author and subject, because that information goes into the PDF.
Export with the Accessible preset, and run the Accessible preflight profile beforehand to catch missing alt text and similar problems.
Mistakes that break accessibility
Using text as pictures is one. Text turned into outlines or flattened into an image can't be read aloud. Keep text as text.
Skipping heading levels, such as H1 then H3, confuses navigation. Keep levels in order.
Alt text that repeats the caption word for word wastes the reader's time. Say something the caption doesn't.
Leaving everything to the end turns accessibility into a long, error prone chore. Build it in as you go and the export takes care of itself.
Checking the result
Once exported, File > Check a PDF can check the PDF against PDF/UA-1 rules and show the structure tree, so you can see the tags that were written. It is a useful self check, though not a certified validator, so documents with formal accessibility requirements may still need checking by the organisation's own process.
