Tables are where PDF accessibility usually breaks. A table is a two-dimensional relationship rendered as a one-dimensional stream of drawing operations, and unless somebody records the structure explicitly, a screen reader encounters forty-two disconnected numbers with no idea which column or row any of them belongs to. This covers what a tagged table needs, how to build one that works, and what to do with the table designs that cannot be made accessible at all.
What a screen reader needs
For a table to be navigable, assistive technology must be able to answer, for any cell: which row is this in, which column, and what are the headers that give it meaning. In a PDF that requires a tagged structure using the table elements:
<Table>— the container.<TR>— a table row.<TH>— a header cell, with a/Scopeattribute ofRow,Column, orBoth.<TD>— a data cell.<THead>,<TBody>,<TFoot>— optional row groupings, valuable in long tables./ColSpanand/RowSpanattributes on merged cells./Headerson a data cell, listing the IDs of the header cells that apply — the mechanism for complex tables where scope alone is insufficient.
With this in place, a screen-reader user can move cell by cell and hear "Revenue, Q3, £1.1 million" rather than "£1.1 million". Without it, the numbers are unattributable and the table conveys nothing.
The vocabulary mirrors HTML's table model almost exactly, which is not a coincidence and which makes HTML knowledge directly transferable here.
Getting it right at the source
Retrofitting table structure in Acrobat is among the most tedious tasks in document work. Building it correctly upstream costs almost nothing. The rules, by tool:
Microsoft Word. Use Insert → Table, never tabs or spaces to align columns. Then, critically: select the header row and tick Table Tools → Layout → Repeat Header Rows. That single checkbox is what tells Word's PDF export to emit <TH> elements rather than <TD>. Also set Table Properties → Row → uncheck "Allow row to break across pages", which keeps rows intact and avoids split-cell tagging problems. Add a table title and description under Table Properties → Alt Text.
LibreOffice Writer. Insert a real table; tick Heading in the insert dialog and Repeat heading rows. Export with Tagged PDF enabled.
Adobe InDesign. Use real tables (Table → Insert Table), and convert the first row to a header row with Table → Convert Rows → To Header. InDesign exports header rows as <TH> correctly. Tables built as a grid of separate text frames — a common design practice — cannot be tagged as tables at all and will need full manual remediation.
HTML to PDF. Semantic <table> with <thead>, <th scope="col"> and <th scope="row"> converts to a properly tagged PDF table with most converters. If you have any choice about the pipeline, this is the least painful route to accessible tables at volume — see how to convert HTML to PDF.
LaTeX. Tagged table output is possible with tagpdf but remains genuinely difficult. For documents where accessibility is a requirement rather than a nice-to-have, this is a real consideration in choosing the toolchain.
Fixing tables in Acrobat
When you have been handed a finished PDF, the work happens in two places.
The Table Editor is the purpose-built tool. In Tools → Accessibility → Reading Order, select the table region and click Table, then Table Editor. Acrobat overlays the detected cell grid, colour-coding headers and data cells. From there you can:
- Right-click any cell → Table Cell Properties to switch it between Header and Data.
- Set the Scope on header cells (Row, Column, or Both).
- Correct Row Span and Column Span on merged cells.
- Assign an ID to a header and reference it from data cells via the Headers list, for tables where scope cannot express the relationship.
The Tags panel is where you fix structural damage the Table Editor cannot: a table that has been tagged as a series of paragraphs, rows that have been merged or split incorrectly, a caption absorbed into the table. This is manual tree surgery, and it is slow.
Check the result with Tools → Accessibility → Accessibility Check, which specifically reports table regularity, missing headers, and summary issues. PAC (PDF Accessibility Checker) gives a stricter second opinion and shows the table structure as assistive technology sees it.
Table designs that fight you
Some tables are difficult because of how they were designed, not how they were tagged.
Merged cells and multi-level headers. A table with a two-row header where the top row spans groups of columns is legal and describable — via /Headers references — but it is laborious to tag and awkward to navigate by ear. Where possible, flatten to a single header row, even at the cost of longer header labels.
Nested tables. A table inside a table cell is valid PDF and a genuinely bad experience for a screen-reader user, who now has to track two levels of position. Restructure.
Layout tables. A grid used purely to position content, with no data relationships. These should not be tagged as tables at all; they should be tagged as ordinary content, or the visual grid marked as an artifact. Tagging a layout table as a table forces the reader through a meaningless navigation model.
Tables split across pages. Each page fragment gets its own <Table> element unless carefully handled, so the header association is lost after page one. Repeating the header row in the source is the standard mitigation, and it helps sighted readers too.
Empty cells. A blank cell announces as nothing, and the reader cannot tell whether they have hit the end of the row. Put a marker in it — an em dash, "n/a", "0" — so the absence is explicit.
Tables that are pictures. A screenshot of a spreadsheet dropped into a document is an image; no tagging can recover the structure. The only remedies are recreating it as a real table, or providing the data another way. This is depressingly common in reports, and it is worth pushing back on at the source.
Practical writing advice for accessible tables
Structure is necessary; design decisions determine whether the result is actually usable by ear.
- Give every table a caption, tagged as
<Caption>inside the<Table>, saying what the table shows. It is announced first and orients the listener. - Keep header labels short. They are re-announced on every cell as the reader moves. "Q3 revenue" is fine; "Revenue for the third quarter of the current financial year (£m)" is punishing when heard forty times.
- Put units in the header, not in every cell. It shortens the announcement and reads better.
- Use one table per idea. Two logically distinct tables joined by a blank row are one table with a confusing structure.
- Order columns so the most identifying one comes first, since that is what a row-scoped header usually is.
- Do not use colour alone to convey meaning in cells — a red cell means nothing to a screen-reader user or a colour-blind reader. Add a symbol or a word.
When a table cannot be made accessible
Some tables genuinely resist: a large financial statement with four levels of header nesting, a complex scientific table with irregular structure. Two honest fallbacks:
- Provide the data in another format alongside. A CSV or spreadsheet link next to the table serves the screen-reader user far better than a heroically tagged but unnavigable structure. How to convert PDF to CSV covers extraction if you need to produce it from an existing document.
- Summarise in prose. A short paragraph stating what the table shows — the trend, the outliers, the total — is what most readers actually take from a table anyway.
Neither is a substitute for tagging where tagging is feasible, and both beat a table that technically validates and cannot be used.
Summary
An accessible table needs <Table>, <TR>, <TH> with a scope, <TD>, and correct spans — the same model as HTML. Build it in the source with a real table and a repeating header row, which is the one setting in Word that determines whether headers are tagged as headers at all. Fix existing files with Acrobat's Table Editor, flatten multi-level headers where you can, never tag layout grids as tables, and for the genuinely intractable ones, publish the data in a format a reader can actually use.
