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 ↗It is far cheaper to build accessibility in from the start than to retrofit it later. Every minute spent on structure now saves hours of remediation afterwards.
Who benefits from accessible PDFs?
The word disability can make this sound like a niche issue. It is not. Accessible documents serve a far wider group of people than most organisations assume, and several of those groups are already in your readership.
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.
Age related changes to vision and hearing affect more than 40% of 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. What matters 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.
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 mandatory reference in EU public procurement, and it is increasingly written into private-sector contracts as well.
This is the route that matters commercially, and most guides miss it. Very few translation agencies and design studios are themselves legally covered. They encounter PDF/UA because a client inherited the requirement through a tender and passed it down the supply chain as a contract term. If you are a supplier, the question to ask is not whether the law applies to you. It is whether it 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 it is why a contract clause referencing EN 301 549 is as binding in practice as a statute.
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
Here is a mental model that helps. Imagine every PDF as having 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 ignore the visual layer entirely. They rely only on the logical layer to understand the document. If that layer is absent, wrong or incomplete, the reader 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. Not what it looks like, but what role it plays.
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 | Why it matters |
|---|---|---|
<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 and more precise tag set. For new accessible PDFs, target PDF 2.0 for the best compatibility with current assistive technology.
ISO 32000-2 ↗In Adobe Acrobat, open View, then Navigation Panels, then Tags to inspect the tag tree of any PDF. That tree is what a screen reader sees.
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". The job is to convey the meaning, not to record that an image exists.
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, not the image.
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.
Open the PDF in Acrobat Reader and press Tab repeatedly. Elements highlight in the order a screen reader will meet them. If the highlight jumps around the page, the reading order needs work.
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 they are referenced in virtually every national accessibility law in the world.
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, sign language interpretation provided |
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 and referenced by law in the EU, the USA, the UK, Canada, Australia and many other countries.
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, meaning the declared language, the alt text, the reading order and the document title, either travels with the translation or silently does not. And 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 is not accented French. It is 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.
This is not an edge case. The 2026 CAAT study of German public sector PDFs tested nearly 70,000 documents and found that 31.6% of them fail the check for a correct language attribute, making it the fifth most common failure in the entire study. Close to a third of published documents are being read aloud in the wrong voice, 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 not optional polish. It 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 practical notes. 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 tables have to be explicitly assigned. A type with no table assigned has nothing to act on.
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, not in the PDFs
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 authoring tool is not what decides the outcome. The export workflow is, and a workflow is something you can fix once and reuse.
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. Both, not one.
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 testing that matters
NonVisual Desktop Access. Free, open source, and the most widely used screen reader in the world. Essential 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 the most widely used screen reader in enterprise settings, at over 1,000 dollars a year. NVDA is the free alternative most home users run, which is why it is the sensible one to test with.
About JAWS ↗The accessibility checklist, before you publish
Run through this before any PDF leaves the building. It covers the requirements that matter most, and a document that passes all of it is close to genuinely accessible rather than merely compliant 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 metadata. Without it a PDF cannot be described as PDF/UA conformant, even if it passes every technical check. Add the XMP flag in Acrobat or on export from InDesign.
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, authoritative material. These are the ones 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. Practical and 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.
Practical guidance
- WebAIM PDF accessibility. The best practical, human-readable guide to document accessibility on the internet.
- 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. The first large-scale 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, nothing of the kind 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, not what it looks like.
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 national law almost everywhere. The current version is WCAG 2.2.
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
We remediate documents to PDF/UA and WCAG 2.1 AA, in one language or in twenty, including Arabic, Hindi and CJK. Audits, remediation and accessible InDesign sources built to stay accessible after translation.
PDF accessibility services →