PDF Accessibility: The Complete Guide
What an accessible PDF actually is, what the law requires, how the structure underneath the page works, and how to check your own files. In plain language, with nothing held back.
This guide is written for the person who has just been told that their documents have to be accessible and wants to understand the subject properly before spending money on it. Communications teams, publishers, in-house designers, project managers at translation agencies. No prior knowledge is assumed, and every term is explained in the glossary at the end.
It is free, it has no tracking of any kind, and it is complete on one page. Read it end to end or use the contents below to jump to what you need.
- What is PDF accessibility?
- Who benefits from accessible PDFs?
- Why it is required by law
- How accessible PDFs actually work
- Tags: the invisible skeleton
- Images and alt text
- Reading order
- WCAG: the global rulebook
- Accessible PDFs in more than one language
- Testing tools
- The accessibility checklist
- Resources and further reading
- Glossary
What is PDF accessibility?
A PDF is accessible when every person can read, understand and navigate it fully. That includes people who use screen readers, people with low vision, people with motor impairments and people with cognitive disabilities.
Think of it like a building. An entrance with nothing but steps excludes anyone who cannot climb them. Put a ramp alongside those steps and the entrance works for everyone, not only for people who can walk.
An accessible PDF works the same way. It does not look different to most readers. Underneath the visual layer it carries a deliberate structure that lets assistive technology interpret the document and read it aloud in an order that makes sense.
Most PDFs created by exporting from Word, InDesign or Canva are not accessible by default. Accessibility requires deliberate action while the document is being built. It does not happen on export.
PDF/UA (Universal Accessibility) is the international standard for accessible PDFs. It defines exactly what an accessible PDF must contain, from tagging through to metadata.
ISO 14289 ↗Building accessibility in from the start costs far less than retrofitting it. Structure set up in the source saves remediation work on every PDF exported from it.
Who benefits from accessible PDFs?
The word disability can make this sound like a niche issue. Accessible documents serve a far wider group of people than most organisations assume, and several of those groups are already among your readers.
Use screen readers that announce every element. A poorly tagged PDF becomes an unintelligible jumble of text fragments.
May zoom to 200% or 400%. They need proper reflow and scalable text so the document does not fall apart at large sizes.
Navigate by keyboard alone or with switch devices. They need a logical tab order and forms they can actually complete.
Clear structure, plain language and a logical reading order help readers with dyslexia, ADHD or cognitive disabilities.
Vision and hearing change with age for many people over 60. Accessible design meets their needs too.
Reflowable, well structured PDFs behave far better on small screens. The same structure helps everyone on any device.
Think of it as the curb cut effect. Ramps built for wheelchair users also help people with prams, delivery workers, cyclists and everyone else pulling a suitcase. Accessibility is good design for all.
A parent holding a baby, someone reading in bright sunlight, a person in a loud office. Everyone experiences temporary accessibility needs. Accessible PDFs serve them as well.
Why it is required by law
PDF accessibility is a legal requirement in a growing number of situations. It is not a single blanket rule, and anyone who tells you that every PDF your organisation produces is now illegal is selling something. The question is which rule applies to you, because the answer changes what you actually have to do.
Europe has two separate regimes
Public sector. The EU Web Accessibility Directive (2016/2102) has applied to public sector websites and apps for years, and it explicitly covers documents published on them, including PDFs. In Germany this runs through the Behindertengleichstellungsgesetz and BITV 2.0.
Private sector. The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025. It covers a defined list of products and services sold to consumers: e-commerce, e-books, consumer banking, passenger transport, telecoms, ticketing. It is not a general rule about company documents. Where a covered service supplies documents to consumers, those documents are in scope. E-books are named explicitly, which puts publishers squarely inside it.
Germany: the BFSG
The Barrierefreiheitsstärkungsgesetz implements the EAA in German law and has applied since 28 June 2025. Two transitional rules help with older material: office file formats such as PDFs published before 28 June 2025 are exempt under section 1(4), and under section 38 services may keep using products already in use for them until 27 June 2030.
The exemption most companies ask about first is for micro-enterprises. Under section 3(3), micro-enterprises that offer or provide services are outside the BFSG, and section 2 no. 17 defines those as businesses with fewer than ten employees and either annual turnover of at most 2 million euros or an annual balance sheet total of at most 2 million euros. Two things about that exemption are regularly misread. It covers services only: a micro-enterprise that places covered products on the market is still bound by the law. And it is not a general small-business exemption from accessibility, only from this specific statute.
Two further exceptions exist, for fundamental alteration of the product or service and for disproportionate burden. Both require documented justification that has to be reviewed at least every five years. Neither is a shortcut.
Non-compliance can attract fines of up to 100,000 euros under section 37, and the market surveillance authority can order a service withdrawn. In practice the more likely first contact is a warning letter from an organisation with standing to bring one.
The United States
Section 508 of the Rehabilitation Act covers federal agencies and their contractors. The ADA has been applied to digital content through litigation rather than through a document-specific rule, and the Department of Justice's Title II regulation sets WCAG 2.1 AA for state and local government with staged compliance dates.
EN 301 549, and how this actually reaches suppliers
EN 301 549 is the European standard for accessible ICT. For documents it points at WCAG and PDF/UA. It is the harmonised standard behind the Web Accessibility Directive, the usual reference in EU public procurement, and increasingly written into private-sector contracts.
Commercially, this is the route that counts, and many guides leave it out. Few translation agencies and design studios are legally covered themselves. They meet PDF/UA because a client took on the requirement through a tender and passed it down the supply chain as a contract term. If you are a supplier, ask whether the law applies to your client.
Almost none of these laws say the word PDF. They require accessible digital content and point at standards. The standards say PDF/UA and WCAG. That is where the actual technical obligation lives, and why a contract clause referencing EN 301 549 binds a supplier in practice.
Which rule applies
| If you are | The instrument | What it covers |
|---|---|---|
| A German or EU public body | Web Accessibility Directive, BGG, BITV 2.0 | Documents on public websites and apps |
| A company selling covered products or services to EU consumers | European Accessibility Act, BFSG in Germany | Documents forming part of the covered service, e-books |
| A micro-enterprise providing services | BFSG section 3(3) exemption | Outside the BFSG, though not outside client contracts |
| A supplier to any of the above | EN 301 549, via contract or tender | Whatever the contract specifies, usually PDF/UA and WCAG AA |
| A US federal agency or contractor | Section 508 | ICT including PDFs |
Directive (EU) 2019/882. Applies to covered products and services sold to consumers, in force since June 2025.
Read the directive ↗The European ICT accessibility standard. References WCAG and PDF/UA, mandatory in EU public procurement, increasingly used in private contracts.
Download EN 301 549 ↗Requires federal agencies and their contractors to make ICT accessible, including PDF documents used by federal employees or the public.
Section 508 PDF guidance ↗How accessible PDFs actually work
A useful mental model: every PDF has two layers.
The visual layer is what you see on screen. Typography, images, columns, colour, everything that makes a document look the way it looks.
The logical layer is invisible. It is a set of instructions that tell software: this text is a heading, this image shows a bar chart, this table has a header row, read this paragraph before that one.
Screen readers rely on the logical layer to understand the document. If that layer is absent, wrong or incomplete, the listener gets nonsense.
A visually beautiful PDF can be completely inaccessible, and an accessible PDF looks exactly the same as any other PDF to most readers. Accessibility is invisible infrastructure.
The four pillars of an accessible PDF
Tags define what every element is: heading, paragraph, list, table, figure. Without them the document is a flat, unstructured picture of text to assistive technology.
The order content is read aloud has to match the intended logical order, not the visual layout. Multi-column and complex designs frequently get this wrong.
Every meaningful image needs a text description. Decorative images must be explicitly marked as decorative so they are skipped.
Title and language tell a screen reader which document it is in and which voice and pronunciation rules to use to read it.
The fastest way to understand PDF accessibility is to hear it. Install NVDA, which is free on Windows, or switch on VoiceOver, which is built into macOS and iOS, and try to navigate one of your own PDFs without looking at the screen.
Tags: the invisible skeleton of your PDF
Tags are the most important accessibility feature in a PDF. They are hidden labels attached to every element in the document that describe what that element is: the role it plays, whatever it looks like.
Think of tags as the equivalent of HTML elements on a website: <h1> for a main heading, <p> for a paragraph, <ul> for a bullet list. PDF tags do the same job.
The tags you need to know
| Tag | Means | What it does |
|---|---|---|
<H1> to <H6> | Headings | Screen reader users navigate by heading to move around a document, the way a sighted reader skims a contents page |
<P> | Paragraph | Normal body text. Without it, blocks of text may be read as one run-on line or skipped |
<L> <LI> | List and list item | The screen reader announces "list of five items", giving context before reading any of them |
<Table> <TR> <TH> <TD> | Tables | Without table tags, tabular data is read as a stream of unrelated cells with no row or column context |
<Figure> | Image or graphic | Marks where images are so that alt text can be attached to them |
<Artifact> | Decorative content | Tells the screen reader to skip the element. Used for page numbers, rules and decoration |
<Link> | Hyperlink | Makes links recognisable and operable from the keyboard |
Tags have to be correct, not merely present. A heading tagged as a paragraph is still inaccessible. The text may be large and bold on the page, but a screen reader will not offer it as a navigation point.
PDF 2.0 (ISO 32000-2) introduced an expanded tag set, which PDF/UA-2 builds on. For now, PDF/UA-1 remains the safer target: most export tools, checkers and assistive technology support it, and it is what contracts usually ask for.
ISO 32000-2 ↗In Adobe Acrobat Pro, open the Tags panel (Accessibility Tags in current versions) to inspect the tag tree of any PDF. That tree is what a screen reader works from.
Images and alt text
Every image in a PDF falls into one of two categories, meaningful or decorative. The handling is completely different for each.
Meaningful images
These carry information that is not available anywhere else in the document. A chart, a photograph of a product, a diagram of a process, a signature. They need alternative text, a written description that communicates the same information the image provides visually.
Do not write "image of a graph". Write what the graph shows: "bar chart showing a 40% increase in sales from Q1 to Q4 2023". Alt text conveys the meaning of the image.
Decorative images
Ornamental rules, background shapes, purely aesthetic illustrations. These add no information and should be marked as Artifact in the tag structure, which tells screen readers to skip them entirely. That keeps the listening experience free of meaningless descriptions.
Charts and infographics are the most commonly inaccessible images in PDFs. A complex chart with no alt text is simply invisible to a screen reader user. Every data point, trend and conclusion has to exist in text, either as alt text or as a caption or table near the image.
Complex images need more than alt text
For detailed diagrams, infographics and data charts, a single description is rarely enough. Three options, which combine well:
- Give the chart's data in full in the body text
- Place a data table with the actual numbers below the chart
- Use a long description linked from the figure, which PDF/UA supports
A logo used purely as branding in a header is usually decorative. The same logo used to identify a company in a list of partners is meaningful. Context decides.
Current tools can generate alt text automatically. They describe what they see literally rather than what the image means in context, so treat the output as a first draft and review every line.
Reading order: the hidden disaster in most PDFs
This is the issue that surprises people most. A PDF can look perfectly logical on screen, with columns flowing left to right, captions under images and headings before body text, while the reading order stored inside the file is something else entirely.
Screen readers follow the order in the file structure, not the visual layout. A two-column PDF might read all of column one and then all of column two, or it might jump between them. A caption might be read before the image it belongs to. A sidebar might interrupt the middle of a sentence.
Why it happens
Most design applications record elements in the order they were created, not the order they should be read. A designer who adds a pull quote after finishing the body text places it after the body text in the file structure, even though it appears visually in the middle of a paragraph.
How to fix it
For anything more complex than a single column, reading order has to be set deliberately. In Adobe Acrobat Pro that means the Reading Order tool or the Tags panel. In InDesign it means the Articles panel, set before export, which is by far the cheaper of the two.
The golden rule: the reading order in the file must match the logical reading order of the document, regardless of how the content is arranged on the page.
Pressing Tab in Acrobat Reader moves through links and form fields only, so it checks the tab order of interactive elements. If the focus jumps around the page, the tab order needs work. For the reading order of the text itself, use a screen reader or the Tags panel.
Multiple columns are the single most common source of reading order problems. Always verify the order on any document with more than one column, however simple it looks.
WCAG: the global accessibility rulebook
The Web Content Accessibility Guidelines are the internationally recognised rules for digital accessibility. They were written for websites, but they apply to PDF documents too, and accessibility law in the EU, the US, the UK, Canada and many other countries refers to them.
WCAG rests on four principles, remembered as POUR.
Information has to be presentable in ways people can perceive, including by non-visual means.
All functionality has to be operable, for example navigable by keyboard and not only by mouse.
Content and operation have to be understandable: clear language, predictable structure.
Content has to be interpreted reliably by a wide range of assistive technologies, now and later.
The three levels of conformance
WCAG criteria are organised into three levels. Level AA is the one most legislation requires.
| Level | What it means | Example for PDFs |
|---|---|---|
| A | Minimum. Without it, some people cannot access the content at all | All images have alt text, the document has a title, the language is set |
| AA | Standard. Required by most legislation. Removes significant barriers | Contrast of at least 4.5:1, text resizable to 200% without loss of content |
| AAA | Enhanced. Not achievable for all content types | Contrast of at least 7:1, explanations for unusual words and abbreviations |
Colour contrast, the most commonly failed criterion
Text needs sufficient contrast against its background. This is one of the most frequently failed criteria anywhere in accessibility, and one of the easiest to check before you publish.
The current version of the guidelines, published by the W3C. Most laws and EN 301 549 still reference WCAG 2.1 AA, which 2.2 extends with nine further criteria.
Read WCAG 2.2 ↗The free WebAIM Contrast Checker tells you instantly whether any two colours meet WCAG AA or AAA. Worth a bookmark next to your brand palette.
Contrast Checker ↗Colour must never be the only way information is conveyed. Around 8% of men have some form of colour blindness and will miss any cue carried by colour by itself.
Accessible PDFs in more than one language
An accessible PDF in one language does not become ten accessible PDFs by translating it. Everything the tag structure carries (the declared language, the alt text, the reading order and the document title) either travels with the translation or silently does not. Silently is the important word: nearly every failure in this chapter produces a file that passes an automated checker.
Language: the setting almost everyone gets wrong
A screen reader chooses its voice and its pronunciation rules from the language declared in the file. A German voice reading French text produces something close to unintelligible noise. PDF/UA requires the natural language of all text to be declared, at the document root and again on any passage in a different language.
Here is the trap. In InDesign, language is a character-level attribute carried by paragraph and character styles. Translate an English file into French and those styles still say English. The exported PDF declares French text as English. PAC passes it, because a language is declared. It is just the wrong one.
There is a second trap on top of that one. InDesign's Middle Eastern feature set writes ar-SA as the root document language on export, regardless of what the document is actually set to. Same outcome: a valid tag, the wrong value, no error from any checker.
The problem is widespread. The 2026 study of German public sector PDFs by axes4 and mindscreen tested nearly 70,000 documents and found that 31.6% of them fail the check for a correct language attribute, the fifth most common failure once purely formal errors are left out. Close to a third of the documents have no correct language declaration, in a sector that has been legally required to get this right for years.
Automated tools verify that a language is declared. Only a screen reader tells you whether it is the right one. For multilingual work, an NVDA or VoiceOver pass is the only test that catches this class of error at all.
Alt text is translatable content, and usually is not translated
Alt text lives in InDesign's Object Export Options. Whether it reaches the translator depends entirely on how the CAT tool's IDML filter is configured, and in many default configurations it is simply not exposed.
The result is a French PDF with English alt text. Checker: pass. Every image description read aloud: the wrong language.
It compounds, because alt text usually is not in the translation word count either. Nobody quoted for it, so it is not anyone's job. The same applies to the document title in the metadata, which the screen reader announces before anything else and which is almost never translated, plus table summaries and link text.
The fix is a decision, made before the file goes out: is alt text in scope, does the filter expose it, and if not, who extracts it into a bilingual file?
Overset text is silent data loss
Text expansion pushes content past the end of a frame. Overset text is not exported to the PDF at all, so it is not in the tag tree, and there is no error for a checker to report. The content simply does not exist.
A sighted reviewer might notice a sentence that stops mid-clause. An automated tool never will. See overset text in InDesign.
Right to left: direction is visual, reading order is logical
Mirroring a layout changes how the page looks. It does not change what the tag tree needs to say. The common failure is a properly mirrored Arabic layout whose Articles panel order was never revisited, so the reading order still follows the sequence in which the original left-to-right elements were created.
Mixed content is the other half of it. Latin-script brand names, figures and URLs inside an Arabic run each need the right directional handling, or they are read back reversed.
Two notes from production. Validate the text layer by exporting Text (Accessible), not by copy and paste, which is unreliable from Middle Eastern InDesign output. And treat the Arabic font itself as a variable: some releases decompose marks in a way that breaks the ToUnicode mapping, so the page renders perfectly while the extracted text is garbage. No checker flags it. More in right-to-left languages in InDesign and fonts in multilingual DTP.
CJK and Indic scripts
For CJK, the metric that predicts fit is point size against leading, not character count, which is why estimates built on word counts fail. Kinsoku line-breaking sets have to be assigned explicitly; a style with no set assigned breaks lines in the wrong places.
For Devanagari, InDesign's World-Ready composer can produce doubled combining marks and replacement characters in the accessible text layer while the page itself looks entirely correct.
The pattern repeats: the page is right, the text layer is wrong, the checker is satisfied.
Build it in the source
Accessibility built into the InDesign source, meaning tags, alt text, reading order and language, carries into every exported language version. Remediating finished PDFs instead means paying for full remediation once per language, with results that drift apart as they go.
The same German study makes the point from the other direction. It grouped every document by the software that created it and the software that exported it. InDesign exported through the Adobe PDF Library accounts for 18.2% of everything tested and reaches 7.7% conformity. Word exported through axesWord, a dedicated accessible-PDF exporter, reaches 73%. The export workflow decides the outcome more than the authoring tool, and a workflow can be fixed once and reused.
One setup pass, then a short verification pass per language.
A full remediation pass per language, every time, with no shared structure.
In multilingual accessibility, automated checking is the weakest link, because almost every failure mode produces a technically valid file. The tests that actually work are a screen reader and a native speaker.
Testing tools: how to check your PDFs
Visual inspection tells you nothing about accessibility. You need tools that inspect the structure underneath the page, and you need a person listening to the result. You need both.
Automated checkers
Built into Acrobat Pro. Runs an automated check against PDF/UA and WCAG criteria. A reasonable first pass, not an exhaustive one.
Adobe accessibility guide ↗The PDF Accessibility Checker, free for Windows and the most thorough automated checker available. The 2026 release added AI assisted checks for semantic structure, including headings, paragraphs and tables.
Download PAC ↗Professional accessibility testing platform with PDF support, used widely by enterprises and accessibility consultants.
axe DevTools ↗Enterprise-grade testing and remediation software, widely used in government and large organisations. The company is Allyant; the software still carries the CommonLook name.
CommonLook suite ↗Screen readers, for the test that counts
NonVisual Desktop Access. Free, open source, and one of the two most used screen readers in WebAIM's surveys. The tool for hearing what your PDF actually sounds like.
Download NVDA ↗Built into macOS, iOS and iPadOS with nothing to install. Activate it with Cmd and F5 on a Mac.
VoiceOver guide ↗Built into Windows. Less capable than NVDA or JAWS, but useful for a quick sanity check with nothing to install.
Narrator guide ↗Automated tools verify what a machine can verify: that a tag exists, that an attribute is present, that a value is well formed. They cannot tell you whether the tag is the right one, whether the alt text describes the image, or whether the declared language matches the text.
Chapter 9 is the proof. Every failure mode described there produces a file that PAC passes.
Run PAC first to clear structural errors quickly, then do the manual screen reader pass to catch the logical and experiential problems the automated tool cannot see. Doing it the other way round wastes the listening pass on errors a machine would have found.
JAWS, by Freedom Scientific, is a paid screen reader widely used at work. NVDA is the free alternative, used about as widely, which makes it the sensible one to test with.
About JAWS ↗The accessibility checklist, before you publish
Run through this before any PDF leaves the building. A document that passes all of it is close to genuinely accessible, beyond compliance on paper.
<TH> and are not used for layout.Six more, if the document exists in more than one language
PDF/UA requires a conformance claim in the document's XMP metadata. Without it a PDF cannot be described as PDF/UA conformant, even if it passes every technical check. Check whether your export tool writes it; Acrobat's Preflight can add it.
US government and enterprise procurement often asks for a Voluntary Product Accessibility Template, an Accessibility Conformance Report documenting how your content meets Section 508 and WCAG.
About VPATs ↗A set of 136 failure conditions for PDF/UA testing, used by PAC and other checkers as the definitive list of what can make a PDF non-conformant.
Matterhorn Protocol ↗Resources and further reading
PDF accessibility has an active professional community and a lot of free, reliable material. These are worth bookmarking.
Standards and guidelines
- WCAG 2.2, W3C. The full specification. Dense, but the Understanding documents alongside it make it readable.
- PDF/UA overview, PDF Association. The custodian of the PDF standards. The most authoritative material on PDF/UA anywhere.
- PDF/UA Technical Implementation Guide. The detailed implementation reference for people doing the work.
- Section 508 PDF resources, GSA. Clear guidance from the US General Services Administration.
- EU Web Accessibility Directive. Full text and guidance on Directive 2016/2102, including monitoring and complaint mechanisms.
Hands-on guidance
- WebAIM PDF accessibility. A clear guide to document accessibility.
- Adobe Accessibility Resource Centre. Adobe's own documentation for Acrobat and InDesign.
- The WebAIM Million. Annual analysis of the top million websites. Sobering reading on the general state of digital accessibility.
Research and benchmarks
- PDF Accessibility Index 2025 to 2026, Allyant. A large cross-industry benchmark of public-facing PDF accessibility, covering nearly 645,000 documents. 94.75% failed at least one checkpoint.
- Accessibility of PDF documents on public sector websites in Germany 2026. By mindscreen and axes4, using CAAT and axesPAC. Nearly 70,000 documents from federal authorities, social insurance bodies, health insurers and cities. Published under CC BY 4.0, so the data is free to reuse.
Tools
- PAC, PDF Accessibility Checker. Free, Windows. Run it on every PDF before publishing.
- WebAIM Contrast Checker. Free. Two colours in, a pass or fail against AA and AAA out.
- IAAP certification. The International Association of Accessibility Professionals runs the CPACC and WAS certifications, the recognised professional qualifications in this field.
Some vendors sell overlay tools that claim to fix accessibility automatically. For PDFs, no such tool exists in any meaningful form. Accessibility has to be built into the document structure.
Glossary
Every term in this guide, in plain language, in one place.
The principle that products, services and documents should be usable by everyone, regardless of ability, disability, or the technology they use to get at them.
A written description of an image, stored in the file and read aloud by screen readers. It describes what the image communicates.
A tag marking an element as purely decorative. Screen readers skip artifacts entirely and read nothing for them.
Any hardware or software that helps people with disabilities use technology: screen readers, braille displays, switch controls, voice control and more.
Barrierefreiheitsstärkungsgesetz, the German law implementing the European Accessibility Act, in force since 28 June 2025. It covers a defined list of consumer products and services, with an exemption for micro-enterprises that provide services.
Text mixing right-to-left and left-to-right scripts in one run, for example a Latin brand name inside an Arabic sentence. Without explicit directional handling it is displayed, and read back, in the wrong order.
A number expressing how different two colours are in luminance. WCAG AA requires at least 4.5:1 for body text. Higher is easier to read.
The European standard for accessible ICT. It references WCAG and PDF/UA, is mandatory in EU public procurement, and increasingly appears as a clause in private contracts.
The logical nesting of headings: H1 for the title, H2 for main sections, H3 for subsections. Screen reader users navigate documents by jumping between headings.
Japanese line-breaking rules governing which characters may not begin or end a line. In InDesign they are applied through a kinsoku set assigned to the paragraph style. With no set assigned, CJK text breaks in the wrong places.
The code declaring the natural language of a document or a passage, for example de-DE or ar-SA. Screen readers use it to select voice and pronunciation. A wrong tag still passes automated checks.
A list of 136 failure conditions for PDF/UA, used by PAC and other checkers as the definitive technical reference for what makes a PDF non-conformant.
PDF Accessibility Checker, a free Windows tool that tests PDFs against PDF/UA and WCAG. The 2026 release added AI assisted checks for semantic structure such as headings, paragraphs and tables.
The international standard for universally accessible PDF files. It defines the technical requirements a PDF has to meet to be considered accessible.
The four principles of WCAG: Perceivable, Operable, Understandable, Robust. Every WCAG criterion maps to one of them.
The sequence in which a screen reader meets the content of a PDF. It has to match the logical reading order of the document, whatever the visual arrangement on the page.
Fixing an existing, inaccessible PDF so that it meets the standard. Usually means adding tags, correcting reading order and writing alt text after the fact.
Software converting text and document structure into speech or braille. NVDA and JAWS on Windows, VoiceOver on Apple devices. Used by people who are blind, have low vision, or have reading disabilities.
Hidden structural labels attached to every element of an accessible PDF, defining what each one is: heading, paragraph, list, table, image, link.
A mapping inside the PDF that tells software which Unicode character each glyph represents. When it breaks, the page renders perfectly while the extracted text, which is what a screen reader actually reads, is garbage.
Web Content Accessibility Guidelines, the global standard for digital accessibility published by the W3C and referenced in law in many countries. The current version is WCAG 2.2; most laws still reference 2.1.
Extensible Metadata Platform, the standard for embedding metadata inside files. In PDFs it holds the title, language, author and the PDF/UA conformance claim.
Further reading
Remediation to PDF/UA-1 and WCAG 2.1 AA, in one language or twenty, including Arabic, Hindi and CJK. Audits, remediation, and accessible InDesign sources that stay accessible after translation. The first look at your files is free.
PDF accessibility services →