1 of 67

I'm Ricky Onsman, Principal Content Writer for The Knowledge Center at TPGi. TPGi is a global digital accessibility consultancy with a large team of accessibility engineers, consultants, product managers, and auditors scattered around the world, and an equally diverse and large client base from smaller companies to multinational giants.

My job, along with a couple of other very clever people at The Knowledge Center is to research, test, and write technical guidance for the rules, testing procedures, techniques, solutions, and articles our engineers and clients rely on to make websites accessible.

PDF accessibility is only a part of my focus, but in the past few months I've been writing a series of self-directed training modules on PDF accessibility for our ARC platform, as demanded by our clients who want to make sure they comply with legal requirements.

This presentation is not an anywhere-near-complete or even methodical tutorial on PDF accessibility, more a grab-bag of things I discovered as I researched my training modules. I hope you find it useful.

Let me start by stating two simple facts.

2 of 67

It would be a very good thing if all PDF documents on the web were converted to HTML.

3 of 67

It would be a very good thing if all PDF documents on the web were converted to HTML.
That's not going to happen.

4 of 67

PDF was not invented for the presentation of web content.

Following several years of development work, the Portable Document Format was released as a proprietary format by Adobe in 1993.

It's based on the PostScript language, chiefly used for desktop publishing, and was designed to take content source material generated in a wide variety of applications including printed material, and to contain within one file all the information needed to reproduce that content in an electronic format, and to allow it to be shared as a complete document, viewed on any device, and printed so that it would always look the same.

In 2008, PDF was released as an open standard under the control of the International Organization for Standardization. ISO 32000 was last revised in 2020.

I should also acknowledge there are good reasons for choosing to present documents online in a PDF format, including forms. Advantages include:

5 of 67

they can be viewed across devices, operating systems, and user agents
they keep their formatting, regardless of where they’re viewed
they’re easy to share
they’re easy to print
they can be password-protected
they’re standard procedure across industries and government

* they can be viewed across devices, operating systems, and user agents

* they keep their formatting, regardless of where they’re viewed

* they’re easy to share

* they’re easy to print

* they can be password-protected

* they’re standard procedure across industries and government

What they're mostly not, however, is accessible.

As at 2016, there were about 2.5 billion PDF documents on the web (as indexed by Google).

I always have trouble getting my head around very large numbers, so let me just put those numbers in perspective.

One thousand seconds is about 16 and two thirds minutes.

One million seconds is about 11.5 days.

One billion seconds is about 31 years and 8 months.

Two and half billion PDF documents is a lot.

Can we guess how many of these PDFs are accessible?

There are no firm facts, but my guess is somewhere between very, very few and bugger all.

We know that PDFs were designed to contain content from material produced in a range of applications, so here's my first tip.

6 of 67

TIP: Start with accessible source material

7 of 67

When you put a PDF document on a website, it is web content.

8 of 67

https://www.w3.org/TR/WCAG22/

9 of 67

https://www.w3.org/WAI/WCAG22/Techniques/#pdf

10 of 67

11 of 67

alt=“captcha 246”

12 of 67

alt=“captcha 246”

13 of 67

E205.4 Accessibility Standard

Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

EXCEPTION: Non-Web documents shall not be required to conform to the following four WCAG 2.2 Success Criteria:

2.4.1 Bypass Blocks
2.4.5 Multiple Ways
3.2.3 Consistent Navigation, and
3.2.4 Consistent Identification.

�

https://ictbaseline.access-board.gov/document-baselines/

14 of 67

E205.4 Accessibility Standard

Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

EXCEPTION: Non-Web documents shall not be required to conform to the following four WCAG 2.2 Success Criteria:

2.4.1 Bypass Blocks
2.4.5 Multiple Ways
3.2.3 Consistent Navigation, and
3.2.4 Consistent Identification.

�

Example: Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript.

https://ictbaseline.access-board.gov/document-baselines/

https://www.w3.org/TR/wcag2ict-22/#dfn-technologies

15 of 67

https://www.iso.org/standard/64599.html

16 of 67

Yes.

PDFs can be made accessible.

17 of 67

document language
page title
color contrast
headings
lists
link text

18 of 67

scanned documents
tagging
reading order
tab order
alternative text for images
tables
forms

19 of 67

First, you need a way of checking a PDF for accessibility issues that need remediating.

Second, you need a way of remediating the issues that you found.

20 of 67

Test with assistive technology
Test with an accessibility checking tool
Test with an accessibility checking service

21 of 67

people with no vision at all
people with low vision
people with cognitive disabilities
people with motor impairments

people who are deaf
people who are hard of hearing

people sensitive to animated content

22 of 67

screen reader software
magnification software
voice operated software
switches and other pointer hardware
customized or standard keyboards
customized or standard mouses
inbuilt device settings

23 of 67

a document with text, images, tables, and charts
a form with different types of fields to complete and submit
an email signup or login
interactive media

24 of 67

JAWS screen reader with Chrome and/or Edge browser on desktop and/or laptop
NVDA screen reader with FireFox browser on desktop and/or laptop
VoiceOver screen reader with Safari browser on iOS mobile device and on macOS desktop or laptop
TalkBack screen reader with Chrome browser on Android mobile
Dragon Dictate speech recognition software with Chrome and/or Firefox browser on desktop and/or laptop
ZoomText screen magnification software with Chrome and/or Edge browser on desktop and/or laptop

JAWS screen reader with Chrome and/or Edge browser on desktop and/or laptop device

NVDA screen reader with FireFox browser on desktop and/or laptop device

VoiceOver screen reader with Safari browser on iOS mobile device and on macOS desktop or laptop device

TalkBack screen reader with Chrome browser on Android mobile device

Dragon Dictate speech recognition software with Chrome and/or Firefox browser on desktop and/or laptop device

ZoomText screen magnification software with Chrome and/or Edge browser on desktop and/or laptop device

Not everybody tests with all these combinations, but we at The Knowledge Center do, to make sure we cover as many bases as possible. We'll also occasionally have clients who want their content tested using, say, the Narrator screen reader built in to Windows.

It's worth noting that while the Firefox browser doesn't have an enormous market share, the people who make the NVDA screen reader recommend using it with Firefox, so that's why we test that combination.

Also, VoiceOver on an iPhone has some differences to VoiceOver on a Mac, so we test both.

That's all very well for people who have access to even a small device lab, or can at least emulate one, but for most people there's another alternative.

* Test with an Accessibility Checking Tool

Professionals including designers, developers, content authors, and accessibility auditors may use a purpose-specific testing tool, designed to check for accessibility issues in a PDF document before or after it is loaded to the web.

These tools usually take the form of software applications downloaded and installed on the tester’s device.

Professionals will also test PDF content using functionality built into an operating system or browser, such as contrast settings and zooming functionality, and tools built into PDF reading and editing software.

Examples include:

25 of 67

The Acrobat Suite

Acrobat Reader
Acrobat Standard
Acrobat Pro

https://www.adobe.com/acrobat.html

axesPDF

https://www.axes4.com/en/software-services/axespdf

CommonLook PDF

https://allyant.com/commonlook-accessibility-suite/cl-pdf/

The Acrobat Suite

Adobe offers several tools for working with PDF documents - not surprising since they invented the document format.

Acrobat Reader

We mention this first because it’s important to understand that Reader is not a remediation tool. It’s good for viewing, printing, sharing, and commenting on PDFs but it can’t be used to edit them and therefore can’t fix accessibility issues.

Acrobat Standard

Standard does have basic editing capabilities and can be used to edit text and images, to export to other formats, convert other documents to PDF, to make documents secure, and to organize documents - up to a point.

Acrobat Pro

This is Adobe’s professional PDF editing application and can do everything that Standard does with a range of additional editing capabilities, some of which are essential for ensuring PDFs are accessible.

Acrobat Pro includes an automated accessibility checking tool that identifies accessibility issues and, where possible, provides a way of fixing them. Like all automated accessibility checking tools, there are some issues that must be checked manually, including that reading order is logical, that alternative text applied to images is appropriate, and whether the use of color and contrast is accessible.

Acrobat Pro also has capabilities such as Optical Character Recognition (OCR) that enable the conversion of a scanned image to a document with readable and editable text and images.

It’s important to note that Acrobat Pro does not check for accessibility to conform to WCAG or to PDF/UA standards. It applies a more general understanding of accessibility issues. Passing Acrobat’s accessibility check does not mean a document is conformant with accessibility guidelines, standards or legislation.

axes4 family

The AxesPDF tool focuses on the tag tree, with quite sophisticated software to examine tags, find issues and fix them. It aims for PDF/UA standards, and offers some clever features such as finding and fixing unicode errors, keyboard shortcuts for managing tags, and screen reader previews.

The people behind AxesPDF are the same people who created the PDF Accessibility Checker (PAC) https://pac.pdf-accessibility.org/en, which is freeware for PDF accessibility testing. PAC 2024 is the first worldwide ISO 14289-1 (PDF/UA) validator, so you can check PDFs for compliance with PDF/UA and WCAG standards. For that reason, it has become a popular and respected alternative to checking with Acrobat Pro. As of November 2023, Axes4 owns PAC.

The free demo of AxesPDF (Windows only) is great for checking things like language settings inside the tags that are difficult to find with other tools. It's also great for checking forms because all the text is visible in there while you’ll only see a part of the text at the time in tools like Acrobat and PAC. AxesPDF is also a good tool for checking tables (properties of cells, scope, labels). Note that demo checking results can't be saved in the free version, and there are file size restrictions.

Axes4 has three main paid tools that are also respected and popular: AxesWord, AxesSlide and a full-featured version of AxesPDF. Each of these tools have good reputations for making Word docs, PowerPoint slides and PDF docs accessible, but, like Acrobat Pro, they aren't cheap.

So, the upshot is that Axes4 is like most providers - offers a very good free tool that shows the problems but can't fix them, and a suite of paid tools that are very good for remediation. The remediation tools do some things Acrobat can't (like making multi-page tables in Word accessible when converted to PDF, and fixing font errors caused by things like ligatures in some fonts), have a reputation for being easy to use, and go beyond WCAG to PDF/UA standards.

Of the rivals to Acrobat, I'd say Axes4 is the standout.

CommonLook PDF

CommonLook PDF is a plugin that works within Adobe Acrobat. The free version can verify and validate document compliance and conformance with Section 508, WCAG 2.1 Level AA, PDF/UA and Department of Health & Human Services standards. It has a number of features that focus on checking and validating PDF document accessibility.

The full featured plugin identifies issues and provides a way to fix them from within the plugin. Also Windows only, although it’s possible to use the plugin in a macOS environment by using Parallels. CommonLook is part of A11yant.

The combination of Acrobat Pro and paid CommonLook PDF creates a powerful and effective PDF accessibility remediation tool.

I mostly test with Acrobat Pro but I'll also check certain things with the other two tools to compare results.

Other checking tools, mostly free, include:

26 of 67

Other checking tools, mostly free, include:

GrackleDocs
PAVE
PDFix

Other creation, editing, or remediation tools, mostly paid, include:

Equidox
Foxit
Nitro
Omnidocs

PDFix Pro
PREP
SODA
Venngage

27 of 67

GrackleDocs

PAVE

PDFix

Other creation, editing, or remediation tools, mostly paid, include:

Equidox

Foxit

Nitro

Omnidocs

PDFix Pro

PREP

SODA

Venngage

How well any of them works for you depends on your specific needs, budget, and expertise.

You'll see that when I show examples from here on in, I'll be using Acrobat Pro screenshots.

There is one more important caveat before we move from the tools to the issues.

Adobe revamped its Acrobat products in November 2023, and did it in a big way. Some sidebars moved from the left to the right side of the screen, some previously prominent functions and options were hidden deep in menus, and some new menus were introduced to provide quicker access to certain functions.

This included putting most of the accessibility-related features under a Prepare for Accessibility menu.

I mention this because if you have an older version of Acrobat Pro, what you see in my screenshots may not match what you see in your software.

Also note that the screenshots used in that collection of WAI PDF techniques are pre-November 2023.

* Test with an accessibility checking service

You might recall I mentioned a third way of testing for PDF accessibility issues.

There are quite a lot of online services that will test your PDF documents for accessibility for free, often using - or claiming to use - artificial intelligence to analyze your document and tell you what's wrong with it.

First, I don't find the results of this kind of testing very reliable. It's a bit like using an overlay to check your website - they often miss things, misrepresent things and end up causing your more problems than they solve.

Second, the reason most of them are free is because they will only tell you what the problems are, not how to fix them. That will cost you.

I have no doubt there are some reliable, ethical, skilled and efficient online PDF accessibility checking services out there. Some.

28 of 67

29 of 67

30 of 67

The Report Options section lets you opt to create an accessibility report, and you can select where that report should be stored. This is worth doing, as the report document may be useful later.

The Page Range section lets you check all pages or a specified range.

You'll see in the Categories dropdown there are four options, each of which have things you can choose to check, or not.

Typically, I check for everything except Table Summary, which means my Checking Options total "31 of 32 in all categories".

TIP: There's no need to check for a Table Summary. A table summary was considered necessary for accessibility back when screen readers were less sophisticated and informative than they are today. Tables in Word documents, for example, don't have anything that will convert to a Table Summary anyway, so just leave that item unchecked.

Whatever settings you chose last time will persist, so I can ignore the "Select All" button (which would include the Table Summary check), and the "Clear All" button (unless for some reason I want to check just one or two things), and I leave the "Show this dialog" option checked so I can see what I'm doing.

Click "Start Checking" and soon (depending on the length of the PDF) you'll see the Accessibility Checker panel open on the right of the screen.

31 of 67

If any of the Categories have issues, they will be noted in parentheses after the Category name. Open up those Categories to see the issues.

In the Document category, you should always see two issues, and when you open it up you'll see they are Logical Reading Order and Color Contrast with a note that each needs a manual check.

This doesn't mean there is a problem with those items, just that the Checker can't check them automatically so you should do it yourself. That's why they have a question mark icon.

Detected issues will appear with a cross in a red circle icon.

Right click and you'll see an options menu, with Fix, Skip Rule, Explain, Check Again, Show Report, and Options.

Fix is very useful, when activated it will usually open the appropriate tool, such as the "Set alternate text dialog", where you can apply a fix.

Skip Rule is for when the Checker finds an issue but you know it's not an issue.

Explain goes to your browser and opens up the relevant Adobe help page.

Check Again is for when you want to make sure your fix was applied.

Show Report opens up the report you opted for in the Report Options section within the panel you're currently in. I quite like this as it gives you the full checking report at a glance, with each rule linked to an Adobe help web page.

Options opens up the Accessibility Checker Options dialog again, in case you want to change the checking options.

So, this is a very handy way to check for and fix accessibility problems in your PDF as long as you remember:

* It doesn't equate to a full WCAG audit

* It can check for some things that don't need checking

* Some things still need a manual check

* When fixes are applied, just make sure it's the right fix for the right issue

32 of 67

33 of 67

structural issues

document structure
page structure
navigation
forms

content issues

images
text
color
content reflow
annotations

34 of 67

TIP: When you edit a PDF document in Acrobat Pro and change something, save the file, close it, and re-open it.

Otherwise, you may not see your changes take effect.

35 of 67

• tag order

This is a big one. Don't let anyone tell that all you have to do to make a PDF accessible is make sure it's tagged - that's nonsense - BUT tagging does have a big impact on accessibility.

Put it this way - getting the tagging right won't make a PDF accessible, but getting it wrong will make a PDF inaccessible.

That's because assistive technology conveying PDF content correctly relies on it having the right tags in the right order. Screen readers and speech recognition software, especially, use the tag order.

There is a learning curve with tags, it isn't always obvious which tags should be used for specific types of content, and the language is sometimes different to HTML markup. For example, images go inside a Figure tag.

Then there's the hierarchy of tags, which tags go inside other tags and which tags should never be parent tags. Indenting nested tags helps to keep the hierarchy visually clear.

And then there's each tag's properties, which define what they are and thus how they're announced by screen readers.

To work with the tag order, you need the right tools. In Acrobat Pro, the tag order is represented in the "Accessibility tags" panel. A quick way to access this panel (and several others) is via the icon in the list at the right edge of your screen.

36 of 67

TIP: Auto-tagging is quick and easy but unreliable - you need to check that the tags are right.

37 of 67

TIP: In the Prepare for Accessibility menu, use the Fix Reading Order tool to manipulate the reading order in several ways.

• reading order

This is the way content is visually presented, also known as the architectural reading order. When a source document is converted to PDF, it puts the visible content into a logical reading order for people not using assistive technology.

The conversion process can sometimes mess up the reading order so it should be checked visually and, if necessary, adjusted to make sense.

As a side note, Acrobat has a Read Out Loud tool, that, not surprisingly, reads PDF text out loud. Be aware that this tool conveys the reading order, not the tag order.

The smart move is to make the reading order match the tag order. If you adjust the reading order, it will often also adjust the tag order, but not vice versa. Set the tag order, then the reading order.

TIP: In the Prepare for Accessibility menu, use the Fix Reading Order tool to manipulate the reading order in several ways.

38 of 67

TIP: The Prepare a Form tool in Acrobat Pro helps you fix any focus issues in forms.

39 of 67

TIP: The document Title property is not the same thing as the Title of a tag, which is set in the Object Properties of the tag. Each tag can have a separate Title, different to the document Title.

40 of 67

TIP: Again, this is not the same thing as the Language of a tag, which is set in the Object Properties of the tag.

41 of 67

document security

This is also often overlooked but can easily be the cause of major accessibility problems.

Remember that one of a PDF's strengths is its security. PDFs are designed to be created by a content author, and then locked up tight so no-one can mess with them.

Unfortunately, security settings can be so tight that they can lock out assistive technology.

There are three ways to apply security settings to a PDF document.

First, there is the Security tab in Document Properties. Here, you can choose between five security methods.

* No Security - self explanatory

* Password Security - this prompts you to set a password that users must enter.

* Certificate Security - this prompts you to set an encryption level and type, and specific recipients with access permissions.

* Adobe Experience Manager Document Security - this prompts you to select a server on which the document is stored and how to access it.

* Microsoft Purview Information Protection - this is a licensed way to protect data, manage data governance, and prevent data loss in Microsoft-based documents.

It is possible to set Password Security as assistive technology can be used to enter a password (assuming you know what it is). The only other setting that is AT-friendly in Document Properties is No Security.

Note that these settings can also be reached through the Protection option on the Main Menu, which sits right above the Document Properties option. I guess it saves a couple of keystrokes.

But wait, there's more!

42 of 67

TIP: In Document Properties set No Security. In Security (Enhanced) disable Protected Mode, turn Protected View off, and disable Enhanced Security.

The Main Menu also has a Preferences option, where you'll find two more sets of security settings.

Scroll down to Security, and you'll find options to configure different kinds of server access, including using the aforementioned Adobe Experience Manager and Microsoft Purview Information Protection.

Right below Security, you'll find Security (Enhanced). Here you can set Sandbox Protections, Enhanced Security, and Privileged Locations.

Most of these settings are AT-friendly by default. If certificate, server or purview security is set, you probably can't do much about it. The exception is that most PDF documents will have "Enable Protected Mode at startup" and "Enable Enhanced Security" turned on by default, and these two options effectively lock out assistive technology. Turn them off. "Protected View" is usually off by default but if it's on also turn that off.

TIP: In Document Properties set No Security. In Security (Enhanced) disable Protected Mode, turn Protected View off, and disable Enhanced Security.

43 of 67

TIP: Headings properly formatted in Word documents should convert to properly tagged PDF headings.

44 of 67

45 of 67

TIP: Use the Accessibility Tags panel to check the table structure.

46 of 67

TIP: If you decide you need to synchronize Acrobat’s page numbering with the visible page numbers, select the pages in question in the Pages panel, right-click and open the Page Labels dialog. That’s where you can change the page numbers.

page numbering

Because many PDF documents are based on a paper structure, they can come supplied with visual page numbering. These are often not tagged automatically in the conversion process, and when they are, they're often tagged incorrectly. This means you have to go in and tag them or re-tag them yourself to make them accessible to assistive technology.

The page numbers displayed in Acrobat's Pages panel generally don't synchronize with page numbering carried across from, say, a Word document. You can adjust them to be the same as the visual page numbers but it's a fiddly and time-consuming process.

TIP: If you decide you need to synchronize Acrobat’s page numbering with the visible page numbers, select the pages in question in the Pages panel, right-click and open the Page Labels dialog. That’s where you can change the page numbers.

How much benefit synchronizing and tagging visible page numbers actually delivers is dubious. Many screen reader users find having a number read out for every page tedious, at best.

47 of 67

TIP: JAWS does not announce PDF page numbers by default.

Press CTRL + SHIFT + N to open the Go To Page dialog.

JAWS will announce the current page number, while the dialog provides the option to move to another specified page.

NVDA does announce the PDF page number by default at the beginning of each page.

BONUS TIP: If you artifact page numbers, you can still use the Go to Page tool, the numbers will just be ignored by screen readers.

48 of 67

TIP: Check the tag order. Your new tag should sit between the two tags that contain the text in the default language. If not, drag it into place.

language changes

As in HTML web pages, you can set instructions for a screen reader to announce specific words or phrases in a language other than the default language you set in Document Properties. It can be fiddly to do, but otherwise screen readers will pronounce all text as if it was, for example, English, which can sound very hicksville.

The thing to remember is your content is encased in tags, so that screen readers know what to announce. If you want the content of an entire tag to be pronounced in an alternative language, it's pretty straight forward to locate the tag in the Accessibility Tag panel, right-click Properties to open the Object Properties dialog and select the preferred language in the Language field.

Setting a different language for just one word or phrase in a block of text content within a single tag is a bit trickier.

Make sure the Accessibility Tags pane is open. Highlight the text you want changed in the Document Pane. Open the Options menu at top right of the Accessibility Pane (the ellipsis icon), and select Create Tag From Selection. You'll see the text is now highlighted in the Document Pane within the larger block of text and has its own tag. Right-click that tag, select Properties to open the Object Properties dialog and apply the Language you want.

TIP: Check the tag order. Your new tag should sit between the two tags that contain the text in the default language. If not, drag it into place.

49 of 67

TIP: A linked Table of Contents, a linked Index, and Bookmarks are good ways of navigating to specific content in a PDF.

multiple ways

WCAG Success Criterion 2.4.5 Multiple Ways says there must be more than one way to locate a web page within a set of web pages. This raises the question as to whether this applies to PDF documents on the web.

As we saw earlier, legislation such as Section 508 and EN 301.549 includes this Success Criterion as one of four that are exceptions because they normatively (that is, in the literal wording of the success criterion) apply to "sets of web pages" and therefore not to "non-web content" like documents.

We also saw that WCAG2ICT includes PDF in its definition of "web content". So, this success criterion does apply to PDF documents on the web. I should add this is not a popular opinion.

For me, it comes down to practical benefits. In the same way you might add a site map to a website in addition to a navigation menu, it makes sense to me to provide more than one way of navigating within a PDF document.

All it takes is reading "web page within a set of web pages" as "pages within a PDF document on the web". PDFs have pages, and they're on the web, so they're web pages, whether or not each PDF has a URL like an HTML page.

PDF readers usually have a Search function built in, but then you have to know what to look for. Page numbers aren't much use by themselves, either.

TIP: A linked Table of Contents, a linked Index, and Bookmarks are good ways of navigating to specific content in a PDF. The users can browse, select their destination and jump to it.

50 of 67

TIP: Equivalent to standard HTML markup is Visible Rectangle + Underline + None + Blue + Medium.

links

As with HTML web pages, PDF text links should make their purpose and/or destination clear, either by themselves or taking their surrounding content into account. They should be clearly differentiated from non-link text, and not by color alone.

Highlight the text to be turned into a link, right-click and select Create Link to be guided through options.

The Link Properties in both Create a Link and Edit Link can be confusing. Here's a lightning guide.

• Link Type: Two choices. Invisible Rectangle makes the other link properties visually hidden. Visible Rectangle makes the link properties visible.

• Line Style: Three choices. These refer only to the appearance of the Visible Rectangle. Solid displays a solid border around the link. Dashed displays a dashed border around the link. Underline displays solid bottom border, creating an underline effect. That's right: it's a visible rectangle but only the bottom part is actually visible. These options are greyed out when Invisible Rectangle is selected as the Link Type.

• Highlight Style: Four choices. This displays when the link is activated.

o None does not change the appearance of the link.

o Invert changes the link’s color to its opposite, so a black text link on a white background briefly changes to white text on a rectangular black background.

o Outline briefly changes the link’s outline color to its opposite and a rectangular outline in an opposite color to the link, so a red text link on a white background changes to green text with a green outline.

o Inset makes the link jump slightly, momentarily showing a black background.

• Color: Select from a color palette. This affects the color of the Line Style and the Outline Highlight Style. It does not affect the color of the link text.

• Line Thickness: Select from Thin, Medium, or Thick. This affects the thickness of the Line Style and the Outline Highlight Style.

TIP: Equivalent to standard HTML markup is Visible Rectangle + Underline + None + Blue + Medium.

51 of 67

TIP: If you add Alternate Text for Images, screen readers will read that out, even if you add an Alternate

Description for Links and even though it’s a link not an image. No, that does not make sense.

52 of 67

TIP: Use Acrobat Pro's Prepare a Form tool. This will help you format a form properly and apply the correct and accessible labels and instructions. Do check the results, though.

Forms

If you thought forms on HTML web pages were tricky, gird your loins. PDF forms are not fun, yet are used for some of the most critical content, including collecting information crucial to health, finance, education, legal, and social support, let alone things as innocuous as buying a ticket to a movie or concert.

There are two main flavors of PDF forms on the web: the kind that must be printed out, filled in on paper, and mailed to a postal address, and the kind that are interactive online experiences.

There are thousands, if not millions, of the former, beloved of government departments in particular, which will only accept a paper form with a hand written signature. They assume all users have a printer, and that people who can't see will have someone else fill their form in for them.

Their greatest concession to modern technology is that you may be allowed to fax the completed form instead of mailing it. Welcome to the 20th century.

Interactive online forms are slightly better in that they are either digital versions of a paper form where users can tab from field to field and then submit the form, or they're much simpler procedures designed for the web, enabling everything from ecommerce to logins and search boxes. Both must, of course, be formatted and tagged correctly to be accessible.

All the agony you might feel making HTML forms accessible applies to PDF forms, with some extra pain points thrown in. The best I can do in the limited time I have here is to give you some quick tips.

TIP: Use Acrobat Pro's Prepare a Form tool. This will help you format a form properly and apply the correct and accessible labels and instructions. Do check the results, though.

53 of 67

TIP: Use the Identify Form Fields tool in the Prepare for Accessibility menu. This will help you apply the correct roles, names, states, and values for the form fields.

54 of 67

TIP: Be aware that there is a specific checkbox to in Field Properties to indicate a field is required.

55 of 67

TIP: Use the Format tab in Field Properties to specify any data input formatting requirements, like date, currency, phone number, zip code, etc.

56 of 67

TIP: Information in every field's Tooltip property is conveyed by assistive technology as the accessible name. The Name property is ignored. Except for buttons. For buttons, the Label property becomes the accessible name.

57 of 67

TIP: Make sure any form submit buttons are present, accessible and functional. The Button Properties dialog will let you define exactly how a submit button should behave.

58 of 67

TIP: In the Prepare for Accessibility menu, there is a very handy tool called "Add alternate text". When activated, this identified all images in a PDF and lets you cycle through a little dialog for each of them.

images

After dealing with forms, image management will feel like a summer breeze. The principles are the same as in HTML. Informative images must, of course, have appropriate alternative text and decorative images must be artifacted, removing their tags and deleting them from the accessibility tree.

TIP: In the Prepare for Accessibility menu, there is a very handy tool called "Add alternate text". When activated, this identifies all images in a PDF and lets you cycle through a little dialog for each of them. You can check whether an informative image has alt text, whether it's appropriate and whether it needs adding or editing, or you can mark it as decorative. Much easier than finding every Figure tag in the Tag panel and checking it that way.

This is not the only way of checking, editing, or adding alternative text to PDF images but it's certainly the easiest.

59 of 67

TIP: Use the Scan & OCR tool.

60 of 67

TIP: Setting Smooth Text for Monitor will generally produce the best results for all screen types.

61 of 67

Converted from MS Word using Angsana New font

When Character Spacing is applied in Acrobat

Aptos Serif font in MS Word document

Aptos Serif font when converted to PDF

A not uncommon problem with text in PDF documents is that they may not reproduce all the fonts in a converted document. Unlike a web font applied to an HTML document, the PDF relies on fonts installed on the user's device.

This may result in less common fonts appearing with Encoding Errors in the Accessibility Checker, particularly if they use ligatures.

Ligatures are when two letters are combined into a single glyph, such as a lower case "f" and "i" being combined into a single character where the top of the "f" curves over to become the tittle on top of "i".

In themselves, ligatures can be good for accessibility, preventing a crammed look that's difficult to read in cases like that "f" and "i".

However, when some fonts are converted to PDF, they can become illegible.

On the left at the top is some text converted from an MS Word document using Angsana New font. All the letters and words are crammed together and overlapping and difficult for anyone to read, let alone a person with impaired vision.

However, Acrobat Pro will let you edit that text, increasing the character spacing so that the text becomes legible, including separating ligatures into their component letters, as shown on the left at the bottom.

On the right at the top is an example of text in a Word document in Aptos Serif font. At bottom right is the same text converted to PDF, where it has become gobbledook nonsense. It's not actually random, it's just that each character has been converted to a weird symbol from some other font, making it illegible.

Even Acrobat can't do anything with this: changing the font from within the PDF has no effect. In this case, you'd have to go back to the source document and choose a more PDF-friendly font.

62 of 67

TIP: Manually edit the text with tools in the Edit menu to replace the black diamonds with the desired characters in a native PDF font, such as a single and double quotations marks in the example.

63 of 67

64 of 67

TIP: Use the Control + 4 key combination to turn Reflow on and off quickly.

You must always check that the PDF content displays correctly when a user turns on Reflow.

This means, for example, that multiple column content reflowed into a single column has the correct reading order, both visually and for assistive technology. PDF editing tools can do this, but it always needs checking and frequently needs fixing.

There are exceptions to what content can be reflowed with PDF Reflow, just as there are for the WCAG criteria. Tables don’t reflow, neither do forms, comments, headers, footers, or page numbers.

If a PDF page has a form as well as general text, then the whole page can’t reflow. Images should resize to fit the page when Reflow is used, but they often overlap and obscure text.

If you have, say, white text on a black background and a user zooms the content, finds it spills out of the viewport, and turns on Reflow to make it flow within the viewport, they'll find the text content effectively disappears. This is because using Reflow removes the content tagging, including that the background is black, leaving the user with white text on a white background. The same happens if the user implements high contrast settings and then turns on Reflow. Interestingly, this doesn't happen on mobile with Liquid Mode - hopefully Adobe will change from Reflow to Liquid Mode on desktop in the not too distant future.

TIP: Use the Control + 4 key combination to turn Reflow on and off quickly.

65 of 67

TIP: Check that PDF annotations are correctly tagged to make them available to assistive technology or have been artifacted to be ignored by assistive technology.

Annotations

I could go on with more quirks about checking and remediating PDF documents on the web, like embedding videos in PDFs, but I'm sure you don't have all day.

I do, however, want to briefly mention something you can do in PDFs that's not usually done in HTML pages.

The idea of PDF Annotations is that a user can do things similar to what someone would do to a paper document. They include:

Highlighting text

Underlining text

Marking text as redacted

Adding notes on the page

Attaching sticky notes

Drawing lines and shapes

These annotations can be used in PDF documents to add instrauctions to content without changing the content itself.

As an example, I have a long paragraph of text shown here that has been annotated with circles, arrows, checkmarks, crosses, strikeouts, highlighting, outlining, and a sticky note.

Maybe you wouldn't use all those at once.

TIP: Check that PDF annotations are correctly tagged to make them available to assistive technology or have been artifacted to be ignored by assistive technology.

66 of 67

The Big Catch

You remember way back I talked about opening a PDF in a reader. After all, the vast majority of users will not have Acrobat Pro on their devices, so will open a PDF on the web in a reader.

And that's where all your hard work in making your PDF accessible can come undone.

Users will access your PDF via a browser, and that’s where the catch comes in.

Browsers like Chrome, Firefox, Edge, and Safari will by default open an online PDF document in their browser-native PDF reader – and none of them will take any notice of your efforts to make the document accessible!

The fact is that to be accessible to assistive technologies, online PDF documents need to be opened in a standalone PDF reader application that recognizes and supports your accessibility settings.

Note that browser PDF readers are fine for quick visual browsing of a PDF document online, and may even be OK for printing out a physical copy of a form.

But if you want assistive technology users to understand the content and operate the functionality, such as filling out and submitting a PDF form online, they will need to use a non-browser PDF reader.

There are a lot of free PDF readers out there and they’re not hard to find and install.

Once installed, users need to tell their browser not to open PDF documents in its default reader extension.

16. It's Too Hard!

If this talk has shaken your world, perhaps caused some dismay, made you think you've been left with an impossible task, let me ease your concerns a little.

No legislation, standards, rules, or guidelines say that every PDF document on the web must be accessible.

What they do say, is that the content must be accessible. If you can't make your PDF accessible, you can provide its content in an alternative format.

One way to do that is to publish an accessible HTML web page that provides the same content and functionality as the PDF document.

Tools are starting to become available that make this a practical option. In fact, this may be one of the best uses yet for AI - making an accessible HTML copy of a PDF document.

That might make the PDF redundant, of course, but that might not be a bad thing.

It may end up being a lot easier, faster, and cheaper than remediating PDF documents to be accessible.

We can't, of course, sit around waiting for that to happen, so you can use the techniques I've discussed to remediate your PDFs on the web, with the caveats I've included.

17. Wrapping Up

I want to finish by offering some resources for those of you who want to continue the journey into PDF accessibility.

67 of 67

For full-on training, I highly recommend Chax Accessibility Training, the training courses, downloads, articles, and podcast offered by Dax Castro and Chad Celius.

Dax and Chad also run the Facebook group PDF Accessibility

Shawn Jordison has created a series of video tutorials in his The Accessibility Guy YouTube channel - very useful for step by step PDF explanations.

Adobe Community: Acrobat is very useful, where people pose questions about using Acrobat products and get pragmatic responses from people like Bevi Chagnon.

In a similar vein but with a broader remit than just Adobe products, the PDF A11y Slack channel is a goldmine, where people like Juliette Alexandria offer their advice.

I'd also recommend following the people I've just named wherever you can find them: LinkedIn, X, Mastodon, BlueSky. This way, you can often find out about new product releases or features.

Lastly, use the guidance provided by product manufacturers. The big three are:

Adobe, Axes4, and CommonLook.

For full-on training, I highly recommend Chax Accessibility Training, the training courses, downloads, articles, and podcast offered by Dax Castro and Chad Celius.

https://www.accessibilityunraveled.com/

Dax and Chad also run the Facebook group PDF Accessibility

https://www.facebook.com/groups/PDFAccessibility

Shawn Jordison has created a series of video tutorials in his The Accessibility Guy YouTube channel - very useful for step by step PDF explanations.

https://www.youtube.com/c/TheAccessibilityGuy

Adobe Community: Acrobat is very useful, where people pose questions about using the Acrobat family of products and get pragmatic responses from people like Bevi Chagnon.

https://community.adobe.com/t5/acrobat/ct-p/ct-acrobat

In a similar vein but with a broader remit than just Adobe products, the PDF A11y Slack channel is a goldmine of questions and answers, where people like Juliette Alexandria offer their advice.

https://web-a11y.slack.com/archives/C09EAD7SP

I'd also recommend following the people I've just named wherever you can find them: LinkedIn, X, Mastodon, BlueSky. This way, you can often find out about new product releases or features.

Lastly, use the guidance provided by product manufacturers. In my book, the big three are:

Adobe: https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html

Axes4: https://support.axes4.com/hc/en-us/community/topics

CommonLook: https://allyant.com/resources/pdf-accessibility-for-beginners/

I know this has been a whirlwind tour through PDF accessibility, very selective and probably pretty daunting.

Really daunting is that there is a whole other level of editing PDF documents that goes deep into the underlying PostScript code: classes, attributes, elements, arrays, and more.

Typically, you don't need to dive that deep to make a PDF accessible, or at least that's been my experience.

My slides will be available for download so you can revisit these tips, tricks and traps in your own time.

In the meantime, I'm happy now to take any questions you might have, although there's no guarantee I'll be able to answer them.

Thank you.