A structure-first study plan for the ADS exam: learn the tag tree, classify every element as real content, artifact, or decoration, work through a layout-table scenario and a table-header scenario, run automated checks and screen-reader passes as separate activities, and close with a four-week rotation plus a graded readiness rubric.
The tag tree is a separate document from the page you see
Document structure questions ask you to reason about a logical layer — headings, lists, tables, and their sequence — that exists independently of the visually arranged page. Learning to describe that layer precisely is the foundational skill.
In a tagged PDF, content lives in a hierarchy of structure elements: H1 through H6 for headings, P for paragraphs, L and LI for lists, Table containing TR, TH, and TD cells, and Figure for images. That hierarchy, not the left-to-right visual position on the page, determines the order in which a screen reader or refreshable braille display presents the text. The same separation exists at the authoring source: in Word, a real heading comes from applying a heading style, which exports as an H tag, while manually enlarging and bolding text produces only a larger-looking paragraph.
Train yourself with a translation drill: pick any page and write three structural statements about it — its outline, its lists, and its table headers — using only tag vocabulary, never font or layout vocabulary. A sixteen-point bold navy line is not a heading until it is tagged as one; a line starting with a typed hyphen is not a list item until L and LI structure exists. If you cannot describe a document without referring to how it looks, you are not yet reading the structure layer, and remediation decisions will remain guesses.
Every element needs a verdict: content, artifact, or decoration
Remediation decisions start with classification: before fixing anything, decide what an element is for. The three-way verdict — real content, artifact, or decoration — drives every later handling choice.
Artifacts are elements that exist for presentation or pagination, not meaning: repeated page headers and footers, page numbers, decorative rules, background color blocks. They are excluded from the tag tree so assistive technology does not read them. Real content is anything whose removal changes what a reader understands or does. Decoration sits between: visible and intentional, but carrying no information, such as a brand watermark or a purely ornamental divider. Informative images — charts, diagrams, annotated screenshots — are content, and they need a text alternative that states their function or takeaway.
The verdict is a judgment, not a lookup, which is why it deserves deliberate practice. Ask two questions in order. Would meaning be lost if this element were never read aloud? If yes, it is content and needs structure plus a text alternative where applicable. Would reading it aloud repeatedly add noise without information? If yes, it is an artifact. For the gray zone, document your reasoning in one sentence — that habit of written justification mirrors how accessibility decisions are recorded in real project work.
| Observation | Classification question | Typical verdict | Structural handling |
|---|---|---|---|
| Repeated page footer with a page number | Would its content matter if read once, detached from any page? | Artifact | Exclude from the tag tree |
| Brand watermark or ornamental divider | Does it convey any information a reader needs? | Decorative | Mark decorative or as artifact; no text alternative |
| Chart comparing three product lines | Would meaning be lost without it? | Informative image | Short text alternative plus a longer description nearby |
| Callout box containing a warning | Does it change how a reader acts? | Real content | Tag in reading order with appropriate heading and paragraph tags |
Scenario: an invisible layout table scrambles the reading order
A two-column flyer can look flawless while its tag tree stores the text inside an invisible table, splitting sentences into cells. This scenario shows why order, not styling, is the defect to hunt.
Picture a two-page event flyer. The designer built the two-column layout with a visual table, and when the file was later tagged, that table became part of the structure tree as Table, TR, and TD elements: the entire left column first, then the entire right. A screen reader reads the left column end-to-end — a headline, half a sentence, a date — then jumps to the right column and continues mid-thought. The plausible remediator mistake: they add text alternatives to the logo and a badge image, see a green checker result, and close the ticket.
The better decision is to treat the layout table itself as the defect. Re-tag the content as sequential paragraphs in the intended reading order, or, better, fix the authoring source so the two columns export as flowing text blocks rather than table cells. Then verify with a screen reader's read-all mode and confirm every sentence survives intact. This matters because meaningful sequence is a structural property: WCAG 1.3.2 addresses exactly this, and no quantity of image descriptions repairs a scrambled order.
Table header associations: where a green checker still fails users
An automated checker can confirm that a data table has header cells, but not whether those headers actually describe each row and column. Making that judgment correctly is a distinct, learnable skill.
Scenario two: a quarterly report contains a five-column, twelve-row data table. It is tagged, its top row carries TH cells, and the checker passes. But a merged title cell above the table was also tagged as a header, and the row-label column was left as plain TD, so a screen reader announces row three, column two, with no column identity, and occasionally attributes the title as a header. The tempting mistake is treating the green result as proof that the table is finished.
The better decision is a clean header plan. For simple tables, mark the top row and the label column as TH with an explicit scope of column or row; for genuinely complex tables with merged cells, use explicit header-and-id associations so every data cell points to the headers that explain it. Verify by navigating the table cell by cell with a screen reader and confirming each announcement includes its headers. This is WCAG 1.3.1 — information and relationships must be programmatically determinable — and presence is not the same as correctness.
Run two separate passes: an automated check and an AT walkthrough
Testing questions separate two activities that look similar: an automated check enumerates structural facts, while an assistive technology walkthrough shows how those facts behave in real navigation. Study them as different passes.
A checker pass is fast and exhaustive in the wrong way: it will flag a missing document language, untagged pages, figures without text alternatives, low-contrast text, and structural errors, often organized around published checkpoint collections such as the Matterhorn Protocol for PDF. Its limits are conceptual: it cannot judge whether a text alternative conveys a chart's takeaway, whether a heading level fits the content's hierarchy, or whether the reading order matches the author's intent. Treat its output as a defect inventory, not a verdict on usability.
An assistive technology pass answers what the checker cannot. Open the tagged document in a screen reader — NVDA on Windows or VoiceOver on macOS are common practice choices — and navigate in three modes: jump heading by heading, step through a table cell by cell, then run read-all and follow along. Note every surprise: a heading that never appears, a list announced as plain text, an image read only as graphic. Mini-exercise: run both passes on one document and record one defect each pass finds that the other misses.
Name the governing standard behind every fix you make
Policy and standards questions ask you to connect a document defect to the standard language that governs it. Knowing how WCAG, PDF/UA, and published checklists divide that territory is the map.
The layers differ in job. WCAG is organized by success criteria describing what users need — perceivable, operable, understandable, robust content across formats. PDF/UA is a document-specific standard for accessible tagged PDF, published as ISO 14289, spelling out structural requirements for the format itself. Checkpoint collections such as the Matterhorn Protocol translate those requirements into inspection items for tools and auditors. A fix you can justify in both languages — this repairs a sequence failure under 1.3.2 and removes a structure error under the tagging checkpoints — is a fix you can defend in any policy discussion.
Project work builds on that vocabulary. Distinguish authoring-source accessibility, where a Word or InDesign document is built with real styles, lists, and tables so the export is largely accessible already, from remediation, where a finished file is tagged after the fact; the first costs less per document, the second is unavoidable for legacy and archived material. Useful project artifacts include a defect log with severity and standard reference, acceptance criteria for vendor-supplied documents, and a definition of done: checker pass, structure map, and a screen-reader spot check.
A four-week sequence, a structure-map exercise, and a scoring rubric
Sequence the study around building, breaking, fixing, and governing documents. Then grade yourself with a structure-map exercise whose rubric measures whether the structural habit has become automatic rather than effortful.
A workable four-week rotation: week one, author a short document in Word using genuine styles, lists, and a small data table, export it to tagged PDF, and inspect the resulting tree. Week two, remediate a deliberately flawed PDF — an untagged scan, a layout table, a pseudo-list of typed hyphens. Week three, run the two-pass testing method from the previous section on both documents. Week four, write a one-page memo mapping each fix to a success criterion, then work through practice questions and revisit weak topics.
The core exercise takes about twenty minutes. Take any two-page document and, before opening any tool, write its structure map: the intended reading order as an outline; a content, artifact, or decoration verdict for every element; a header plan for each table; and a one-sentence text-alternative plan for each image. Then run a checker and compare findings. Score yourself on the expected observations below. One short administrative note: for exam logistics such as scheduling and fees, rely on the International Association of Accessibility Professionals' own site rather than third-party summaries.
- Rubric check: your predicted reading order matches the actual tag tree with at most one divergence.
- Rubric check: every image has a verdict, and informative images have a drafted alternative sentence stating function, not appearance.
- Rubric check: every artifact verdict comes with a one-sentence justification you could defend.
- Ready when: you can state a document's outline from its tag tree alone, with the visual page hidden.
- Ready when: you can explain, in standard language, why a green checker result does not settle table header correctness.
- Ready when: you can complete a two-page structure map in roughly twenty minutes without consulting a tool — remembering that rubric outcomes are study milestones, not predictions of any exam result.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.