Frequently asked questions

It is a plugin for Adobe InDesign plus a small helper program that runs on your own computer. Together they take you from an InDesign layout to a PDF that meets PDF/UA-1, the ISO standard for accessible PDFs.

The plugin does three jobs: it checks your document and shows you what is missing, it fixes many of those things with one click, and after export it repairs and validates the PDF and produces a conformance report you can hand over as evidence.

• Adobe InDesign 2025 (version 20.0) or newer, on macOS or Windows.
• The helper program. It comes with the plugin and is also available as a separate download. It runs locally and is only reachable from your own machine.
• A Java runtime, used by the PDF repair step.
• veraPDF, the free open-source validator, for the PDF/UA check.

You do not need an internet connection for any of the core work.

The plugin itself is installed through the Creative Cloud desktop app, like any other Adobe plugin:

1. Buy TagAlly Pro on the Adobe Marketplace, signed in with the same Adobe ID you use for InDesign. You can also reach the marketplace from inside InDesign, under Plugins → Marketplace.
2. Open the Creative Cloud desktop app and switch to Marketplace → Plugins → Manage plugins. TagAlly Pro now appears among your plugins.
3. Click Install. Quit InDesign beforehand if it is running, because the plugin only becomes available in a newly started InDesign.
4. Start InDesign and open the panel under Window → Extensions → TagAlly Pro (in some versions Window → Plug-ins).

If you work with a company Creative Cloud licence and the plugin does not show up, your Adobe administrator may first have to allow plugin installation in the Adobe Admin Console.

The helper program is a separate, one-off step, and the panel does most of it for you. Under ⚙ Advanced → Set up the helper program you pick a folder, the panel puts the archive there and opens it. Unpack it, then double-click START TagAlly (macOS).command or START TagAlly (Windows).bat — the unpacked folder shows little else. It then keeps running in the background. You can also download the helper separately, which is what you need for a second machine or a locked-down computer.

Under Window → Extensions → TagAlly Pro (in some versions Window → Plug-ins). You can dock it like any other panel. It works best docked to the side at roughly 380 pixels wide or wider.

It follows your InDesign interface language automatically. TagAlly Pro is available in English, German, French, Spanish, Italian, Dutch, Portuguese (Brazil), Polish, Danish, Swedish and Norwegian Bokmål. If your InDesign runs in a language we do not have yet, the panel falls back to English.

The report language is separate and you set it yourself in the export settings — see the report section.

Yes, that is the normal case. TagAlly does not need a special template and does not restructure your layout. It reads what is there, tells you what is missing for accessibility, and writes only the things you approve.

Everything it writes lives inside the InDesign document itself — export tags on paragraph styles, object export options, articles. There is no separate database, so a colleague opening the same file sees the same state.

1. Basics — document title and language. Both are mandatory for PDF/UA.
2. Tag mappings — every paragraph style needs a PDF role: body text, heading level, or artifact.
3. Headings — the heading levels must start at H1 and must not skip a level going down.
4. Artifacts & decoration — rules, empty frames and ornaments must be marked as decoration so they are skipped.
5. Alt texts, tables & contrast — every meaningful image needs a description, tables need header rows, text needs sufficient contrast.
6. Reading order — the order in which everything is read out.

The steps are in the recommended working order: it is much less work to tag content first and define the reading order last.

It shows how many of the six steps are green. It is a progress indicator for your work, not a conformance score — a full bar means TagAlly found nothing left to complain about in the document, which is the best possible starting point for the export.

A blocker will almost certainly make the PDF fail validation — a missing document title, for example, or a broken heading hierarchy. A warning is something you should look at but which may be legitimate in your document; you are expected to judge it.

Both are worth clearing before you export. Clearing them is the fastest route to a passing PDF.

It jumps to the page and selects the object the finding refers to. That is usually the fastest way to understand a finding: you see exactly which frame, image or paragraph is meant.

It is the panel section at the bottom of the Check tab. Select any object in the layout and the inspector shows what matters for accessibility: its type and page, whether it is an artifact, its position in the reading order, its alt text, and — for text — the language and the live contrast value.

Everything shown there is editable on the spot. It is the right tool for one-off corrections, where the step list is the right tool for working through a whole category.

Not by default, because objects on parent pages usually repeat on every page and would flood the findings list. You can switch it on under Advanced → “Include parent pages”.

Running heads and folios placed on parent pages should normally be artifacts — that is exactly what the check will tell you when you enable it.

No. Objects on hidden or non-printing layers, and objects set to non-printing individually, are skipped everywhere — they do not appear in the exported PDF, so they cannot cause accessibility problems. The same applies to anything already marked as an artifact.

Yes. Every action is a normal InDesign undo step — ⌘Z / Ctrl+Z reverses it, including bulk actions like “mark all as artifact”, which undo in one go.

There are also deliberate reset functions under Advanced for whole categories (tag mappings, reading order, artifact markings). Those ask for confirmation twice before they run. Alt texts are excluded from all reset functions on purpose — text you typed by hand is never deleted in bulk.

Tags are the invisible structure of a PDF: this is a heading, this is body text, this is a list. Screen readers use them to navigate — jumping heading to heading, for example. Without them a PDF is a picture of text.

In InDesign you attach that role to a paragraph style, so it applies everywhere the style is used. That is why TagAlly asks you to map styles rather than individual paragraphs: one decision covers the whole document.

• P for body text and anything that reads as a paragraph.
• H1–H6 for headings, by their level in the document’s outline — not by their visual size.
• Artifact for anything that is not content: running heads, folios, decorative labels.

List, table-of-contents and footnote styles do not appear in the list — InDesign tags those automatically.

The rule is about the document’s outline, not its appearance. The first heading in reading order has to be H1, and levels must not jump downwards (H1 to H3 without an H2 in between).

A common case: a contents page or a section label sits at the front and is styled as a subheading. Visually that is right; structurally it means the document starts at H2. Either promote it to H1, or make it an artifact if it is really just a label.

TagAlly checks this in the order of your articles, because that is the order InDesign exports and the validator reads — which can differ from the order the frames were created in.

Someone typed a custom value into InDesign’s export tagging instead of picking a standard one — something like H_neg or Intro. InDesign will happily export that name, but a validator reads it as a broken structure element.

Pick a proper tag from the dropdown in the finding. TagAlly also repairs this automatically during post-processing, but fixing the style is the cleaner solution because it stays fixed.

It is the sequence in which a screen reader announces the content. Sighted readers navigate a spread visually; a screen reader user gets one linear stream. If the order is wrong, a caption may be read before the article it belongs to, or a pull quote may interrupt a sentence.

In InDesign the reading order is defined by the Articles panel: objects inside an article are read in the order they are listed, and several articles are read one after another.

In step 6, click “Record reading flow” and then click the objects in the layout in the order they should be read. Each click adds the object and numbers it on screen, so you can see your progress in the layout.

Tip: group related elements with ⌘G / Ctrl+G beforehand — for example the year, headline and text of an info card. A group is recorded as one element, which keeps the article list short and readable.

No. Stop whenever you like and continue later — TagAlly remembers how far you got and tells you what number the next click will be. Objects you have not clicked yet stay behind the recorded ones, so nothing is lost.

Yes. Type a name into the target-article field before you click the first object of that chapter. The field is read again on every click, so you can switch mid-recording; the log confirms each switch with “Target article from now on: …”.

TagAlly never reorders your articles — the order in the Articles panel is your editorial decision.

That is the default article TagAlly creates when you have not named one. It is called “Content” in every interface language on purpose: the name is a real article name inside your document, not a label. If it changed with the panel language, a colleague working in another language would end up with a second, parallel article.

Documents from earlier TagAlly versions used the German name “Inhalt”; that article is renamed automatically the first time it is touched, so your recorded order stays intact.

The overlay is a snapshot, not a live view. After you re-sort articles or mark something as an artifact, rebuild it — the button is right there in step 6 — and the numbers will match again.

Every object on the page has to be one of the two: either part of the content (in an article, so it gets read) or decoration (an artifact, so it gets skipped). Anything in between produces the validator error “content not tagged”.

The finding lists them with a “Show” button, and at the bottom there is a safeguarded button to mark all remaining ones as artifacts in one go — useful when you have finished the reading order and only decoration is left.

It should convey what the image contributes to the document, in one or two sentences. Ask yourself: if I read this page aloud to someone on the phone, what would I say about this picture?

• Do not start with “Image of…” — screen readers already announce that it is a graphic.
• Describe the meaning, not every detail. A conference photo is “Participants in discussion at the 2025 annual conference”, not a list of what everyone is wearing.
• If the image contains text that matters, put that text in the description.
• Charts and infographics usually need more than an alt text — explain the finding in the body text or add a long description.
• Purely decorative images need no alt text at all. Mark them as artifacts instead.

Cover it up and read the page. If nothing is missing, it is decoration — mark it as an artifact. If a reader would lose information, it needs an alt text.

Yes. Many image files carry a description in their XMP metadata, often written by a photo agency or a picture desk. The alt-text finding has a button that pulls those in for all images that have none yet. Review them afterwards — agency captions are often written for a different context.

Yes — group the paths and give the group an alt text in the object inspector. InDesign then exports the group as a figure with a description, exactly like a placed image.

Once an object has an alt text, TagAlly stops treating it as decoration, so it will not reappear in the decorative-objects list.

No. If a group consists only of decorative parts, TagAlly lists it as a single entry — “group of 14 objects” — and one click marks the whole thing. Only mixed groups, where decoration sits next to real content, are broken down into their parts.

TagAlly collects the linked images that have no alt text, sends them one by one to a vision model, and shows the suggestions in the panel. Every suggestion is editable and is only written into the document when you accept it — either individually or all at once.

That approval step is deliberate. An AI description is a good first draft; whether it is right for your context is a judgement only you can make.

No. It is entirely optional and off by default. Everything else in TagAlly works without it.

You can use Anthropic, OpenAI or OpenRouter with your own API key, or run a local model through Ollama — that last option is free and works entirely offline. Enter the key once under Advanced → AI access; it is stored locally in the helper’s configuration file and never in the document.

We deliberately do not ship a shared key. A key bundled in a plugin can be extracted, and the cost would land on whoever owns it.

Only the individual image, downscaled, and a short instruction asking for a description. No other page content, no document, no metadata about you. If you use a local model through Ollama, not even that leaves your machine.

The panel shows the provider’s reason in plain words:

• “Model overloaded” — free models in particular are often busy. Try again later or pick a low-cost paid model.
• “Model no longer available” — free models get retired regularly. Choose another from the dropdown, which is fetched live.
• “Key invalid” — check the key, and make sure it belongs to the provider whose field you pasted it into.
• Nothing happens at all — the helper program is probably not running. See the troubleshooting entry.

Images pasted directly into the layout have no file on disk, so TagAlly cannot send them for analysis. Place images as links rather than embedding them — that is better practice anyway — or write those alt texts by hand in the inspector.

Because a screen reader announces the column heading together with each cell — “Revenue: 1.2 million” instead of just “1.2 million”. Without a defined header row the table becomes a stream of numbers with no context.

Visual formatting is not enough: bold text in the first row does not make it a header. It has to be a real header row.

Use the button in the finding, or the object inspector when the table is selected. TagAlly converts the existing first row. Be careful with InDesign’s own header-row setting, which inserts a new empty row instead of converting the one you have.

Then it cannot be tagged as a table, and a screen reader cannot navigate it. A picture of a table needs a description that conveys the data, or the data repeated in accessible form. Text frames arranged in a grid read as separate paragraphs in whatever order the article defines.

For anything that is genuinely tabular data, rebuild it as a real InDesign table. It is the only construct that exports as a proper table structure.

The WCAG AA thresholds: 4.5:1 for normal text and 3:1 for large text, where large means from 18 pt, or from 14 pt if bold.

It reads the text colour and works out what is behind it: the frame’s own fill, or the smallest coloured shape covering that spot, or the paper colour. CMYK and LAB colours are converted to screen colours for the comparison.

That conversion is an approximation — without a defined output profile no tool can be exact. It is more than accurate enough to judge whether a combination passes or fails; treat borderline values near the threshold with some caution.

Because a photo has no single background colour. The contrast varies across the image, and whether the text stays legible depends on where it sits. That is a judgement call, so TagAlly lists those places with page numbers for you to look at.

Not if you approve it. Each visual-check item has a “Visually checked — fine” button. The approval is stored in the document, so it survives sessions and travels with the file, and it is stated in the report as “visually checked and approved”. You can withdraw all approvals again with one safeguarded button.

Yes — select the text and look at the object inspector. It shows the ratio live, with the two colours as swatches and a clear pass or fail verdict. That replaces reaching for an external eyedropper tool.

Because a screen reader uses it to choose pronunciation. An English quotation inside a German text, read with German pronunciation, is close to incomprehensible. The document language sets the default, and passages in another language should carry their own.

Select the text and use the language row in the object inspector. You can apply it to the selection, the paragraph or the whole story. It is InDesign’s standard character language attribute — the same one used for spell checking.

The language check in step 1 shows the distribution across your document as a bar and warns about text with no language assigned at all.

Correct — and it is not your mistake. InDesign does not write character-level languages into the PDF tag structure. We verified this on real documents: paragraphs marked as English or French in the layout arrive in the PDF with no language of their own.

TagAlly works around it. During “Post-process & validate” the panel hands the helper a list of your foreign-language paragraphs, and the helper writes the language onto the matching structure elements in the PDF. The result line tells you how many were tagged.

One limitation to be aware of: this works at paragraph level. A single foreign word inside an otherwise German sentence is not covered.

A known InDesign quirk: the document language you pick in the export dialog sets one place in the PDF, but the root of the tag structure gets its language from a second, internal source — which can disagree. A German document then announces itself as English to a screen reader.

TagAlly’s post-processing corrects the root language to match the document language, so you do not have to think about it. If you want to see it for yourself, open the structure view: it shows a red warning banner whenever the two disagree.

Use TagAlly’s own export button. It produces an interactive PDF with tagging, structure-based tab order and title display already switched on. Everything else — resolution, compression, page range, spreads, reader layout — is adjustable behind the settings disclosure.

Print PDF export is not suitable: it drops parts of the accessibility information.

It works on a copy — your original export is never modified. The copy is saved next to it with the suffix -ua.pdf. In it, TagAlly:

• adds the PDF/UA identifier that marks the file as claiming the standard,
• sets the viewer to show the document title instead of the file name,
• corrects the root language of the tag structure,
• gives link annotations a description and wraps orphaned ones into proper link elements,
• resolves custom style names into standard tags,
• writes the languages of foreign-language paragraphs,
• adds the scope attribute to table header cells,
• wraps untagged vector paths as artifacts,
• removes incomplete font data that validators reject.

Then it validates that copy with veraPDF and writes the report.

The -ua.pdf. That is the repaired, validated file the report refers to. Keep the original export if you like, but do not ship it.

Some conditions can only be judged on the finished PDF, not in the layout — that is exactly why the validation step exists. Common cases:

• Heading order. The panel checks it in article order; if the reading order changed after the last check, run the check again.
• Links in untagged areas. Post-processing repairs these, so make sure you validated the -ua.pdf and not the raw export.
• Font problems. Some fonts carry incomplete data. Post-processing handles the common case; a genuinely broken font has to be replaced.

The report names the clause and the pages. If a finding is unclear, send us the report — it usually tells us immediately what happened.

It shows the finished tag tree as a readable web page: reading order top to bottom, heading hierarchy, every image with its alt text, tables, and language switches highlighted with a badge. It is the closest you can get to “seeing” what a screen reader will encounter, without installing one.

It is generated from the validated PDF, so it shows the real result — not what the layout intended.

For important documents, yes. It is the most honest test there is and it costs ten minutes: VoiceOver is built into macOS (⌘F5) and NVDA is free on Windows. Listen to the first two pages and you will notice immediately if the order or the alt texts are off.

Two parts. Part 1 is the machine result: pass or fail, how many rules passed and failed, and a table of any violations with clause, condition and pages. Part 2 is the manual checklist — the conditions of the Matterhorn Protocol that no software can judge, grouped by topic, with checkboxes, a remarks field and a signature line.

Tick the checklist on screen, add your remarks and your name, then print it to PDF from the browser. The print view is deliberately leaner than the screen view: the explanatory boxes, the tool hints and your local file path are left out, so the printed record contains only what belongs in evidence.

Yes, and that is the point. The panel language follows your InDesign; the report language is a separate setting in the export section. So you can work in German and hand a Spanish authority a Spanish report. It is available in all eleven languages, and it starts out matching your panel language until you change it.

No, and no tool can issue one. It is documentation: it records what was checked, with which tool and profile, on which date, what the machine result was, and which manual conditions a named person confirmed. That is exactly the kind of evidence accessibility obligations expect — but the responsibility for the document stays with you.

Because it adapts to your document. If the contrast check found nothing and there is no text over images, the report states that it was machine-checked and drops the manual item entirely. If there are places over photos, it lists exactly those pages. If something is below the threshold, it says so in red. The idea is that the report never asks you to check something that does not exist in your document.

The helper program that does validation and PDF repair is not running. It has to be started once per session: double-click START TagAlly (macOS).command or START TagAlly (Windows).bat in the helper folder — the window tells you whether it started or was already running. Leave that window open while you work. If you do not have the helper on this computer yet, put it there from the panel under ⚙ Advanced, or download it.

If it says veraPDF was not found, the path in the helper’s configuration file is wrong or veraPDF is not installed.

The plugin was updated but the helper still runs the old version from before the update. Quit the helper and start it again — it does not restart itself.

Almost always a loading hiccup rather than a real error, especially if the plugin sits on a network volume. Close the panel and reopen it from the Window menu; if that fails, restart InDesign. Should it persist, reinstall the plugin from the Creative Cloud desktop app.

If a genuine error occurs, the panel now shows it as a red message at the top instead of staying blank — please send us that text.

It creates one numbered badge per object, so a document with several hundred objects takes a moment. Progress is reported as it goes. The build is deliberately chunked and paced so InDesign stays responsive rather than freezing.

You do not need the overlay to work — it is a verification aid. Remove it when you are done; it lives on its own non-printing layer and never appears in the export.

Please report it — that helps a lot. TagAlly writes a marker before every risky operation and clears it afterwards, so after a crash the panel can tell you at startup exactly which step was running. Send us that line together with your InDesign version and roughly how large the document is.

Run “Check document” again — the findings are a snapshot from the last run. If it persists after a fresh check, the finding is probably about something you have not noticed yet; use “Show” to see which object it means.

It follows your InDesign interface language. If your InDesign runs in a language TagAlly does not have yet, it falls back to English. If your InDesign is German but the panel shows English, please report it — that indicates the detection failed, and we can look at it with the diagnostic line the panel logs.

Not during checking, export, repair or validation. The helper program listens only on your local machine. There is no account, no login and no cloud component.

The single exception is opt-in: if you switch on AI alt texts with a provider key, the individual images are sent to that provider. Leave that feature off — or use a local model — and nothing leaves your machine at all.

No. The plugin contains no analytics or telemetry.

In the helper program’s configuration file on your own machine, never inside the InDesign document and never on our servers. You can delete each key from the panel with a single button.

WCAG is the general accessibility standard for digital content, written primarily with the web in mind. PDF/UA (ISO 14289-1) translates those goals into concrete technical requirements for PDF files: which structure types to use, how the tag tree must be built, how artifacts are marked.

They overlap heavily. A PDF/UA-conformant file satisfies most of what WCAG asks of a document. Some WCAG criteria — colour contrast, for example, or not relying on colour alone — are about content decisions and are not part of PDF/UA. TagAlly covers both sides: PDF/UA through validation, and the content side through the contrast check and the manual checklist.

A document published by the PDF Association that breaks PDF/UA into individually checkable conditions and, crucially, marks which of them software can test and which need a human. The manual checklist in TagAlly’s report follows that split, with references to the checkpoint numbers.

In the EU, public sector bodies have been covered for years. Since 28 June 2025 the European Accessibility Act extends obligations to many private-sector products and services — in Germany implemented as the Barrierefreiheitsstärkungsgesetz. Which documents are affected depends on your sector and how they are distributed.

This is general information, not legal advice. If you need certainty about your own obligations, ask a qualified professional.

No — and be sceptical of any product that claims otherwise. TagAlly guarantees that the machine-testable requirements of PDF/UA-1 are checked and, where possible, repaired. Whether your alt texts are meaningful, your reading order matches the intended meaning, and your language is comprehensible remains human judgement. What TagAlly does is make that human part short, guided, and documented in a form you can hand over.

TagAlly Pro costs 199 euros per year and per seat. It is sold as a subscription through the Adobe Creative Cloud Marketplace, which shows you the final amount including any VAT before you buy.

Every update is included for as long as the subscription runs, and you can cancel to the end of the current term.

TagAlly Pro is sold through the Adobe Creative Cloud Marketplace. There the marketplace’s merchant of record (currently FastSpring) is the seller: it concludes the purchase contract in its own name, issues the invoice and collects and remits VAT.

That means invoices and refunds go through that channel, not through us. We can help you with anything about the software itself — but a payment we never received is not one we can refund.

What governs your use of the software is our licence terms, regardless of where you bought it.

Per person. One licence entitles one named person to use TagAlly Pro, and that person may install it on the machines they personally work on, such as a desktop and a laptop. What is not covered is several people sharing one licence.

For teams, agencies or education we offer volume and site licences — just ask us, that is usually cheaper than buying seats one at a time.

Yes, all of them. For as long as your subscription runs you get every correction and every new version at no extra cost, including support for each new InDesign release.

If you cancel, the plugin stops working at the end of the term you have paid for. Your work is not affected: InDesign documents and exported PDFs are ordinary files, and reports you have already produced stay readable without TagAlly Pro.

Yes. The core functions need no internet access at all. The helper listens only on the local loopback interface, so it does not open a port to your network.