PDF Accessibility on the Web: Tricks and Traps: Ricky Onsman

>> PAOLA GONZALEZ: Welcome, everyone, to our WordPress Accessibility Meetup, PDF Accessibility on the Web: Tricks and Traps with Ricky Onsman. I do have a few announcements. You can always join our Facebook group to connect between meetups. You can find that at facebook.com/groups/wordpress.accessibility. You can find upcoming events and past recordings in one place. Yes, this meetup is being recorded, and you can find the recording at equalizedigital.com/meetup. That’s gonna redirect you to the longer URL where you can find anything and everything related to our meetups. You can also join our email list to get news and event announcements at equalizedigital.com/focus-state. You can tune into our podcast where we upload the audio version of the meetup so you don’t have to necessarily go on YouTube and watch the video and the recap. You can also listen to it on your phone or wherever you get your podcasts from, and you can find it on accessibilitycraft.com. We are seeking additional sponsors for the meetup. If you’re interested in sponsoring for live captions or ASL interpretation, you can always contact me during the meetup.

Or if you have any suggestions for the meetup, or need any additional accommodations, you can always contact us at meetup@equalizedigital.com. That email goes to both me and Amber, who’s usually here giving the announcements. Who are we? We are the organizers, Equalize Digital. We are a mission-driven organization and a corporate member of the IAAP focused on WordPress accessibility. You can find us on X or Twitter @equalizedigital. We do have a live captioning sponsor today, GoDaddy. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience.

GoDaddy provides a managed WordPress experience that is as easy as it is effective. The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, and malware removal, so our pros can spend less time on monotonous maintenance and more time building their business. You can find them at godaddy.com. You can also tweet at them on X @GoDaddy. We always encourage our attendees to tag them on X or Twitter, however you want to call it.

Tag our sponsors and thank them for sponsoring. We’re very grateful and thankful to GoDaddy for being our live captioning sponsor today. Just a quick reminders of our upcoming events. We have Building an Accessible and Highly Usable Transportation Website with Ron and Kevin on Thursday, November 7th at 10:00 AM Central. On this same time slot, we’re going to have Joe Dolson speaking about Managing Plugin Accessibility for the Long Term. That’s going to be next month on Monday, November 18th at, that is a typo, it’s going to be at 7:00 PM Central, so at the same time slot as this meetup.

For today’s speaker, we have Ricky Onsman. Rikki is a Principal Technical Writer at TPGi’s Knowledge Center, a veteran Australian designer, front-end developer, writer, and editor. His web experience extends to 30 years. He’s filled senior writing, editing, and marketing roles for the likes of UX Australia, SitePoint, Web Directions, and Smashing Magazine. Thank you so much, Ricky, for being our speaker today. I’m going to stop sharing.

>> RICKY ONSMAN: As noted, I’m Rikki Onsman, principal content writer for the Knowledge Center at TPGi. Just should let you know that TPGi is an accessibility consultancy with a large group of accessibility engineers, consultants, product managers, and authors scattered around the world. We have a very large client base from small 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, techniques, solutions, articles for our engineers and clients who rely on them 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. It’s more of 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. It would be a very good thing if all PDF documents on the web were converted to HTML.

That’s not going to happen. Let me be clear, I’m not here to pile on PDFs. That’s just not going to help anyone. My view is that PDFs are currently used on the web and therefore they must be accessible. To do that, the first thing is to get some perspective. PDF was not invented for the presentation of web content. Following several years of development, the portable document format was released as a proprietary format by Adobe in 1993. It’s based on the PostScript language, which is chiefly used for desktop publishing.

It 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 that there are good reasons for choosing to present documents online in a PDF format, including forms.

The advantages include 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, and 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. Now, I don’t know about you, but I always have trouble getting my head around very large numbers.

Let me just put those numbers in perspective. 1,000 seconds is about 16 and 2/3rds minutes. 1 million seconds is about 11.5 days. 1 billion seconds is about 31 years and 8 months. 2.5 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. Here’s my first tip, start with accessible material. The vast majority of documents come from content created in other applications.

Our job is to make the source documents accessible so that your PDF documents will be accessible. Microsoft applications have accessibility features that can carry over into PDF documents, including Word, PowerPoint, Excel, and Outlook. Adobe applications also have accessibility features that can carry over into PDF, most especially in design, which is great for forms. This of course applies to newly generated PDF documents. If your job is to make existing PDF documents accessible, you may not have access to the source material. Before we get to what we can do to fix those existing PDF documents, let me say this.

When you put a PDF document on a website, it is web content. That means it needs to conform to the web content accessibility guidelines. Here we’ve got the homepage of WCAG 2.2. Note that conformance to WCAG is itself not a legal requirement, but most accessibility related legislation like the Americans with Disabilities Act and Section 508 of the Rehabilitation Act, which requires that information provided by government agencies must be accessible. In fact, most disability and accessibility legislation around the world uses WCAG as a standard for assessing accessibility.

WCAG conformance is required to achieve legal compliance. The laws are not all consistent, by the way. Section 508, for example, still uses WCAG 2.0 level AA as its standard. Others use version 2.1, and newer laws are adopting 2.2. Even so, WCAG is the standard. The Accessibility Guidelines Working Group has published techniques for WCAG 2.2 that can be applied by accessibility testers to ensure that PDFs on the web are accessible. Each technique lists the relevant WCAG success criteria. However, there are 58 success criteria in WCAG 2.2, so it looks like we’ll have to come up with some extra techniques, as there are only 23 techniques available.

Then, maybe not all the WCAG success criteria apply. Many success criteria do have exemptions where the purpose, nature, and point of the criteria would be made impossible if the success criteria was conformed to. Possible examples include you don’t have to provide captions for some online quiz videos because it might give away the answers to some. We can see here the image of a quiz show where viewers can see the answer to a spelling question. That doesn’t work. You don’t have to provide text alternatives for captures because that would defeat the purpose of the test.

Here we have a capture that requires entering the phrase CAPTCHA246, and the image has alt text of CAPTCHA246. A bit pointless. It also doesn’t apply to images where the orientation of an image can only be done in one way. If it’s a landscape image of a piano keyboard, you don’t have to provide that in portrait because it would be sideways. Other than that, the only exception to WCAG conformance allowed is under– I wish I could get rid of that little window, the understanding doc for text spacing, which states, currently, this success criteria does not apply to PDF as it is not implemented using markup.

Which is a bit weird because Acrobat Pro does give you two ways to change text spacing. Still, some legislation, including Section 508 and EN301 549, which is the basis for the European Accessibility Act, make exceptions to four WCAG success criteria on the basis that they don’t apply to a set of web pages and that PDFs are non-web content. We’ve got them listed here, and it says specifically, electronic content shall conform to level A and level AA success criteria and conformance requirements in WCAG 2.0.

The exception is non-web documents shall not be required to conform to the following four WCAG 2.2 success criteria, bypass blocks, multiple ways, consistent navigation, and consistent identification. The the W3C’s WCAG 2 ICT guidance, which applies to non-web content, says that some web technologies, common examples of web technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. PDF is web content. Some web standards, such as those applied by the UK government to online public sector documents, provide their own exceptions to WCAG conformance for PDFs published before a certain date on the basis that they were published before accessibility requirements came into force.

I guess that’s reasonable at a practical level, but really that’s just avoiding the problem rather than solving it. There’s also another important standard to know about. ISO 14289 is known as PDF UA, where the UA stands for universal accessibility. This is a technical specification defining how to create PDF documents that are accessible to assistive technology. It uses many of the same guidelines as WCAG, but includes PDF-specific requirements, such as ensuring that PDFs are tagged correctly. We’ll talk more about PDF tagging shortly. It’s fitting that the 2014 update to PDF UA was in fact the first standard ever published by ISO to be fully accessible.

That is, the PDF was PDF UA conformant. Even if we don’t have access to the source material, we do have to make existing PDFs on the web accessible. Is that possible? Yes, PDFs can be made accessible. We’re now in the land of PDF remediation where things are done a bit differently to what happens in HTML country. Some PDF accessibilities are common to HTML content accessibility issues, and they can be addressed in much the same way. Examples include document language, page title, color contrast, headings, lists, and link tests. If you know how to make these content components accessible on HTML web pages, you won’t find fixing them in PDF too difficult.

You just need the right tools. Other issues are quite particular to the PDF format, and they require PDF-specific remediation techniques. Scanned documents, tagging, reading order, tab order, alternative text for images, done a little bit differently in PDF, tables, and forms. Although the methods of remediating these things to make them accessible are different to how you’d approach HTML, they’re still quite fixable if you have the right tools. This is probably the right time to talk about those tools. There are two parts to a PDF remediation process involving two sets of tools, although they can often be found together in one piece of software.

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. Now, there are three ways to check web-based PDF documents for accessibility issues. You can test with assistive technology, you can test with an accessibility checking tool, or you can test with an accessibility checking service. As with all testing for web accessibility, testing with assistive technology delivers the most relevant, useful, and to conduct formal structured usability testing with a person with a disability who’s using assistive technology.

That delivers the most genuine results. Typically, this can be done by providing the user with a set of tasks to be completed, designed to reveal how accessible the document is and to record any specific obstacles or difficulties they encounter. For best results, the document should be tested by people with no vision at all, people with low vision, people with cognitive disabilities, people with motor impairments. If the PDF has embedded multimedia or audio, you want it to be tested by people who are deaf and people who are hard of hearing.

If the PDF uses animation, you’d also want it tested by people sensitive to animated content, like people who have epilepsy might be triggered by some animated content. The testers might use screen reader software, magnification software, voice-operated software, switches and other pointer hardware, customized or standard keyboards, customized or standard mouses, mice, mouses, and inbuilt device settings. A typical testing process might ask them to access a website, open a PDF document and record how easily or otherwise they can access, understand, and operate the content.

The content tested could include a document with text, images, tables, and charts, a form with different types of fields to complete and submit, an email signup or login, and interactive media. That’s a lot of testing with a lot of people. More commonly, this kind of testing is undertaken by professionals using a limited set of assistive technologies, such as a screen reader and keyboard alone, inbuilt device settings, and bookmarklets designed for the purpose.

Professionals will often use the most popular combinations of assistive technologies, browsers, and devices to test web-based PDF documents, including JAWS screen reader with Chrome and/or Edge browser on a 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 an Android mobile. Dragon Dictate speech recognition software with Chrome and/or Firefox browser on desktop and/or laptop, and ZoomText screen magnification software with Chrome and/or Edge browser on desktop or laptop.

Not everybody tests with all of those combinations, but we at the Knowledge Center do, and that’s what I’ve been doing with PDFs, 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 into 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. Now, there’s quite a few checking tools that are available out there. Let’s just look at a couple of them. The Acrobat suite. Adobe offers several tools for working with PDF documents. Not surprising, since they invented the document format. Acrobat Reader, I 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, it can’t fix accessibility issues. Acrobat Standard does, which is paid, does have basic editing capabilities, and it 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 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 the 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 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. Then there’s the Access For 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 binding 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, which is freeware for people for PDF accessibility testing. PAC 2024 is the first worldwide ISO 14289-1 PDF UA validator. 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, which is 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 only see 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 the 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 documents, PowerPoint slides, and PDF documents accessible, but like Acrobat Pro, they aren’t cheap.

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, we’ll talk more about that in a little while, and they 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.

There’s also CommonLook PDF. This 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 and 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 Allyant.

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 GrackleDocs, PAVE, PDFix. Other creation editing or remediation tools, mostly paid, include Equidox, Foxit, Nitro, Omnidocs, PDFix Pro, PREP, SODA, and Venngage. I’ll provide links to all of these in a separate page that you can download when you download the slides, if you’re inclined.

How well any of these 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’s one more important caveat before we move from the tools to the issues. In the slide here, I’m showing that Acrobat 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. 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 you more problems than they solve. Second, the reason most of them are free is because they’ll 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. All right, let’s take a look at what the Acrobat Pro Accessibility Tool does.

From the All Tools menu, select Prepare for Accessibility. And in the screenshot, you can see I’ve highlighted the All Tools menu and highlighted the Prepare for Accessibility tool, which has a little tool tip saying create and verify PDFs to meet accessibility standards. Once you open the Prepare for Accessibility menu, you’ll see there’s an option there to check for accessibility, which I’ve highlighted. This has a tool tip saying, check this document for accessibility issues. When you run that, it opens the Accessibility Checker Options dialog. The Reports section of this dialog lets you set options for what you’d want the Accessibility Checker to do.

One of the first things is to create an accessibility report. This is actually worth doing because that document will be quite useful later. The Page Range section lets you check either the whole document 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’d check for everything except Table Summary, which means my checking options total, as in the screenshot, 31 of 32 in all categories. My tip is 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 even have anything that will convert to a Table Summary anyway, so just leave that item unchecked. When you run the Accessibility Checker, it will open the Accessibility Checker pane on the right side of the screen. If any of the categories have issues, these will be indicated in parentheses after the category name.

You can see I’ve highlighted here the Accessibility Checker panel is open, and I’ve highlighted that the Documents section has three issues, one of which is logical reading order, one of which is color contrast, and another under page content, which is figures and failed alternate text. The fact that it’s highlighted logical reading order and color contrast doesn’t mean that there’s issues with those things necessarily. It just means you have to do those manually. You’ve got to check them yourself. You can’t do it automatically. That’s why they have a question mark icon.

Detected issues will appear with a cross in a red circle icon. I’ve highlighted here under alternate text that figures alternate text has failed. If you right-click on a failed issue, you’ll see an Options menu with the options 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 the 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, which can be useful.

Check Again is for when you want to make sure your fix was applied, and 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 webpage. The Options option opens up the Accessibility Checker Options dialog again in case you want to change the checking options.

This is a very handy way to check for and fix some 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, and when fixes are applied, just make sure it’s the right fix for the right issue. I want to dig a little deeper into what some of those accessibilities are that can occur in PDF documents on the web. Some of these are covered by the checking tools like Acrobat Pro, axesPDF, and CommonLook. Some require manual checking, and some have just come up in my experience.

Broadly, I’ve divided the PDF accessibility issues I’m covering here into two main types. Structural issues, whoops, go back there, which can include the document structure, the page structure, navigation and forms, and content issues, which can include images, text, color flow, content reflow, and annotations. Each of those sections can include more than I’ve included there, but I’m just going to focus on these. I’ll try and cover a little bit about each one in this talk and offer at least one tip on how to address accessibility issues associated with them.

Here’s a tip. When you edit a PDF document in Acrobat Pro and you change something, save the file, close it, and reopen it. Otherwise, you may not see your changes take effect. Sometimes they do, and sometimes they don’t. If I save the file, close it, and open it, I’ll always see the effect take effect. A lot of people get thrown by this, and a lot of people say Acrobat is buggy as a result of it. Yes, it is annoying, but you do get used to it. It’s a bit like editing an HTML page, then reloading it in your browser, then you go back to the editor, then you go back to the browser. It’s no big deal.

Now let’s get started with the issues. Tag order, and this is a big one. Don’t let anyone tell you that all you have to do to make a PDF accessible is to make sure that it has tags. That’s nonsense. Tagging does have a very 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 a 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. You can see in the screenshot here, I’ve got a screenshot of the accessibility tags panel open, and you can see the hierarchy of tags sitting nested within each other, and they’re in a logical order.

I’ve also got the Object Properties dialog open for one particular tag, which shows you the properties that you can set and manipulate for each tag. To work with the tag order, you do 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 an icon that’s in the list at the right edge of your screen, which I haven’t shown there, but they’re there. Auto tagging. This is a tool that comes in the Prepare for Accessibility menu, and it allows you to, at a click, just automatically tag the entire PDF file.

It’s quick and it’s easy, but it is unreliable. My experience is you’d still need to check that the tags are right. They’re the right tags in the right order. Reading order. This is the way the content is visually presented, also known as the architectural reading order. When the document is converted to PDF, it puts the content into a logical reading order for people who are 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, so it won’t reveal the content in the same way that a screen reader does. 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 to match the tag order. In the Prepare for Accessibility menu, you can use the Fix Reading Order tool to manipulate the reading order in several ways, and the screenshot here shows the Prepare for Accessibility menu open with the Fix Reading Order menu item highlighted.

That has opened a reading order panel that has all the content there. The document panel shows all the pieces of content numbered, so you can tell what order they will be read in. Sometimes, those orders are not correct. You can literally, in the order panel, drag them around so that they sit in the order that you think is correct. It’s very useful, very fiddly. There is also the focus or tab order, and this is different again. This is the order in which focusable content is accessed. In an HTML page, a keyboard can be used to go from one focusable element to the next using the tab key.

The trick with PDF documents is that a conversion process can muck up the tab order in things like forms and tables, or even if the content is in columns, you might not be able to tab in the order that you should be able to. Again, the smart move is to ensure that the tab order follows the reading order, which should match the tag order. Tag, then reading, then focus. Always check the tab order with a keyboard. My tip, the Prepare a Form tool in Acrobat Pro helps you to fix any focus issues in forms. Now we come to some specific things. The document title.

This is often overlooked, but it can have a major impact on accessibility. A PDF document title is announced by assistive technology when it’s present. Otherwise, the file name is announced, which is often not informative as to the content or purpose of the document. You want to set a document title if one isn’t present. In the main menu, the first thing you want to do in the top left hamburger, select Document Properties. The document title is set in the title property of Document Properties. In the screenshot, I’ve got the Document Properties dialog open, and I’ve highlighted both the file name, which is not very helpful, and the title property.

I’ve called it the Walrus in Antarctica. Seems fair. My tip, the document title property is not the same 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. They’re often confused. The document language. This is the default language of the document, and it’s set in the advanced tab of Document Property options. Again, this is not the same thing as the language of a tag, which is set in the object properties of the tag. The document language lets you set the default language of the whole document.

The object properties of the tag lets you set the content of a tag to be announced in a language different to the document language. We’ll talk more about that later. However, the tag language property has just 16 options, and the document default language property has 35 options. I do not know why. Document security. This is also often overlooked, but it can also be the source of major accessibility problems. Remember that one of the PDF strengths is that 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 the document properties. In the screenshot here, I’ve got the document properties dialog open, and I’ve highlighted the security method. That security method lets you choose between five options. No security, which is 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, set specific recipients with access permissions.

They need the certificate in order to get access to the document. Adobe Experience Manager document security. That’s a mouthful. This prompts you to select a server on which the document is stored and how to access it. It’s really only relevant if you’re dealing with server-based PDFs. The Microsoft Purview Information Protection. What a title. This is a licensed way to protect data, manage data governance, and prevent data loss in Microsoft-based documents. The main menu also has a preferences section where you’ll find two more sets of security settings.

Scroll down to security, and you’ll find there’s an option to configure different kinds of server access using the aforementioned Adobe Experience Manager and the 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 server certificate or purview security is set, you probably can’t do much about that. It’s set by the author. The exception is that most PDF documents will have enable protected mode at startup and enable enhanced security turned on by default.

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. My tip is that in document properties, set no security. In security enhanced, disable protected mode, turn protected view off, and disable enhanced security. That way, you’ll give assistive technology access to the document. Page structure, headings, very important. As in HTML documents, headings are a major aid to content navigation. Tagged headings are renounced as headings and they’re level.

They can be set as bookmarks for jumping from one set of content to another, and they can be listed by screen readers to provide an overview of content. That also means they have to be meaningful and useful in describing the content of their section. My tip is that headings properly formatted in source material like Word documents should, and I emphasize should, be converted to PDF headings in the conversion to PDF process. Nevertheless, check them and fix them if they need fixing. Lists are also very useful to assistive technology if they are properly formatted and tagged.

Again, check that they are in your converted document. My tip is that bullet points in unordered lists can generally be artifacted, that’s a PDF term for removing it from the tag order and thus the accessibility tree, because otherwise screen readers will announce each list item as dot or bullet followed by the list item content, which isn’t terribly useful. On the other hand, the list item identifier in ordered lists should be left in so that screen readers announce them as item one followed by the content, item two followed by the content, which is useful information.

In the screenshot here, I’ve got two comparisons of an unordered list of items and an ordered list of items. You can see that in the visual view, the unordered list has bullet points, but in the tag order, I’ve removed the bullet points. Whereas in the ordered list of items, the items all have numbers, and I’ve kept those numbers in the tags. Tables. There’s a fair bit that can go wrong with tables. HTML is actually tolerant of things like absent table headers, where PDFs are less tolerant. Tagging tables correctly is essential.

The tags should be structured hierarchically as table, the table element, TR, the table row element, child of the table element, TH, the table header element, child of the table row element, and TD, the table data element, child of the table row element as well. My tip is use the accessibility tags panel to check and correct the table structure. When I say corrected, tags can be dragged. They can actually also be moved by keyboard, but it’s a little bit trickier. You got to know the keyboard shortcuts to get to them and to move them around.

If you have a mouse and can use a mouse, it’s very easy to drag them into position. It’s also very easy to accidentally delete them as I found out. Don’t do that. Page numbering. Because many PDF documents are based on paper, they can come supplied with page numbering. Now, these are often not tagged in the conversion process. 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 but it’s a fiddly and time-consuming process. My tip is 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 Pages 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. Have a think about it.

Another thing about page numbers is that JAWS doesn’t announce PDF page numbers by default. If you press Control, Shift and N in JAWS, you can open the Go to Page dialog. JAWS will then announce the current page number while the dialog provides the option to move to another specific page. That is a form of navigation. NVDA does announce the PDF page number by default at the beginning of each page. A 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, they’re still visible, still usable.

Language changes. Mentioned this before. As in HTML pages, you can set the screen reader to announce specific words in a language other than the default language that you set in document properties. It can be fiddly, but if you don’t do it, screen readers will pronounce all text as if it was, for example, English, which can sound very hicksful. 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 straightforward 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 to change in the Document pane. Open the options menu at top-right of the Accessibility pane, which is represented by an 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 context, text, and it has its own tag. Right-click that tag, select Properties to open the Object Properties dialog, and apply the language you want. My tip is to 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. In the screenshot here, you can see that the content that I’ve applied an alternative language to, French, has appeared as a tag below the two sections in which it is supposed to sit.

You can literally just drag it above the second section so that the reading order is maintained properly for assistive technology. Multiple ways. This is a curly one. WCAG success criterion 2.4.5 multiple ways says there must be more than one way to locate content in a set of web pages. This raises the question of whether this applies to PDF documents. 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 WCAG 2.ICT includes PDF in its definition of web content. This success criterion does apply to PDF documents on the web. I should add that this is not a popular opinion. For me, it comes down to practical benefits. In the same way you might add a sitemap 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, 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. That’s not terribly useful as a way of multiple ways of navigating content. Page numbers aren’t much use by themselves either. They just tell you the page, not how to find content. My tip, a linked table of contents, a linked index and bookmarks are good ways of navigating to specific content in a PDF. Users can browse, select their destination and jump to it. I’ve got on a screenshot here, an example of a table of contents where you can most, if you format them properly, you can click on either or activate the link for either the entire line or just the page number and go directly to that piece of content.

Same applies to indexes, usually found at the back of large PDF documents, or you can also set bookmarks and you can actually create bookmarks pretty much automatically by say, using a tool in the Prepare for Accessibility menu that lets you create bookmarks from existing headers. That’s a useful tip as well. Links. As with HTML webpages, PDF text links should be clear about their purpose and their destination, either by themselves or taking the surrounding context into account. They should be clearly differentiating linked text from non-linked text and not by color alone.

In PDFs, you can highlight the text to be turned into a link, right-click and select Create Link. You can also create a link to be guided through the options. This often happens when you convert documents from say a Word document to PDF that links just for no reason are not carried over. You’ve got to go in and create links. The link properties in both Create a Link and Edit a Link for those that are existing can be confusing. Here’s a lightning guide. On the screenshot here, I’ve got the Create Link dialogue open, and I’ve got these options that I’m going to describe are highlighted.

Link type. There are two choices. Invisible rectangle makes the other link properties visually hidden. Visible rectangle makes the other link properties visible. Line style. There are three choices. These refer only to the appearance of the visible rectangle. Solid displays a solid border around the entire link. Dashed displays a dashed border around the link. Underline displays a 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 grayed out when invisible rectangle is selected as the link type.

Highlight style. There are four choices. This displays when the link is activated, so when you actually click on the link. None does not change the appearance of the link. Invert changes the link’s color to its opposite. A black text link on a white background briefly changes to white text on a rectangular black background. Outline briefly changes the link’s outline color to its opposite and a rectangular outline in an opposite color to the link. A red text link on a white background changes to green text with a green outline. Inset makes the link jump slightly, momentarily showing a black background.

These are the choices. Color, you can select free. Once you activate that option, a color palette opens up and you can select the color that you want, or you can enter it with RGB values. This affects the color of the line style and the outline highlight style. It doesn’t affect the color of the link text. Note that. Line thickness, select from thin, medium, or thick. This affects the thickness of the line style and the outline highlight style. My tip is the equivalent to standard HTML marker is a visible rectangle plus underline, plus none, plus blue, plus medium.

That makes it look pretty much like a standard HTML link. If you want screen readers to announce alternative, announce text for a link other than the visible link text, perhaps because the link text itself doesn’t provide sufficient context for a screen reader, you can navigate to the Object Properties dialog and select properties. You can also select Properties and go to the tag and right-click and select Properties. That will open the Object Properties dialog. In there, you’ll see that for each tag, there is an option for alternate text for images and alternate text description for links.

You can add your preferred alternate text for the link. Just be aware that if you add alternate text for images to a link, 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, know that does not make sense, but it’s true.

Forms. Now, if you thought forms on HTML webpages were tricky, gird your loins. PDF forms are not fun, but they are some of the most critical content, including collecting information that’s crucial to health, finance, legal, and social support, let alone things as innocuous as buying a ticket to a movie or a 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, God help us, 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 handwritten signature. They assume that 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 e-commerce 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. My first tip is 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. My next tip is to 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. Now, be aware that there is a specific checkbox in field properties to indicate that a field is required. I’ve got here a slide screen showing a form in the document panel. I’ve got the Prepare a Form tool open, and I’ve right-clicked on a field in the Fields panel to show the text field properties. We can see the properties for name, tooltip, I’ll get to that, whether the form field is visible, whether it’s read-only, its orientation stated in degrees, and a little checkbox for whether it’s required.

Screen readers will announce the field as required if that checkbox is checked. Another tip, use the Format tab in field properties to specify any data input formatting requirements like date, currency, phone number, zip code, et cetera. In the slide, I’ve got the text field properties open for a zip code field, and it lets me set the format category, in this case, as special, which has options of zip code, zip code plus four, phone number, social security number, and additional arbitrary mask.

I don’t even know what that is. I’ve set this one to zip code, which will then encourage the user, and it will tell assistive technology users whether they have filled the form incorrectly or not. The text field properties, you may have noticed, also has a tooltip field. Now, this property is conveyed by assistive technology as the accessible name. The name property is ignored by assistive technology. I don’t even know why it’s there. I think it’s for structural reasons.

Oh, except for buttons. Buttons don’t have– the tooltip field doesn’t create the accessible name. The label property becomes the accessible name. I hope you weren’t expecting consistency in PDFs. Submit buttons. Make sure that the form submit buttons are present, accessible, and functional. The button properties dialog will let you define exactly how a submit button should behave. It lets you set what happens when you go to the button and what happens when you actually activate the button.

Now, I haven’t even covered things like tagging form fields to make them keyboard accessible, validating form input, making timed responses accessible, like setting time limits for how long you’ve got to fill in the form, or avoiding keyboard traps. Yes, they do exist in PDF forms. However, we’re running out of time, so let’s move on to some content issues. Images. After dealing with forms, image management is going to seem like a summer breeze. The principles are pretty much identical to 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. My tip is in the Prepare for Accessibility menu, there’s a very handy tool called Add Alternate Text. When it’s activated, this identifies all images in a PDF and lets you cycle through a little dialogue 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. That’s not the only way of checking, editing, or adding alternative text. In fact, there are about four or five ways of doing it, but this is certainly the easiest. Then we come to an image issue that is specific to PDF documents. Some documents are, in fact, just one giant image. This typically happens when someone scans a paper document into PDF format. It needs to be converted to readable text and image content using OCR Tool.

My tip is to use the Scan and OCR Tool. It’s another one of those little acrobat dialogues where you say, “Just do the whole thing. Click the button and do it.” Very useful. Text. Now, sometimes text in a PDF can be poorly rendered, especially if it’s being converted from a scanned image with OCR. Acrobat Pro has some options to help you improve the rendering. From the main menu, open the Preferences dialog. From Categories, select Page Display.

In the Rendering section, select Monitor option for the Smooth Text option, and check all the boxes for Smooth Line Art, Smooth Images, and Enhance Thin Lines, and Use Page Cache. They will all make all the content render better. My tip, setting Smooth Text for Monitor will generally produce the best results for all screen types. You’ll see there is an option in there for laptop and LCD screens, but I find that if I set it for Monitor, it works everywhere.

A not uncommon problem with text in PDF documents is that they may not reproduce all the fonts or all the characters that are in a converted document. Now, this is partly because unlike, say, web fonts in an HTML document, the PDF relies on fonts that it has available to it, typically that are loaded on the user’s device. This can result in some 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 lowercase f and i being combined into a single character where the top of the f curves over to become the tittle on top of the 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. In my slide here at the top of the left is some text converted from a Microsoft 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 and in the image underneath that one, you’ll see you can increase 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 gobbledygook 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, or not for me anyway. In this case, you’d have to go back to the source document and choose a more PDF-friendly font.

In some cases, including with some forms that include ligatures, the end PDF comes out with, instead of the proper character, a black diamond with a question mark inside. This is because it just doesn’t have access to that character in that font. You can actually manually edit the text in these cases to replace the black diamonds by going to the Edit menu, selecting the text, and literally backspacing over the diamond character and replacing it with single and double quotation marks in the example that I’ve shown here that are available to you in whatever device you’re using.

Content reflow. WCAG says users must be able to resize the content to make it easier to read for people with low vision, and the resized content must then remain fully visible within the viewport. Now, that doesn’t fit very well with one of PDF format’s basic principles, that content and layout should look the same wherever it’s read. However, PDF reading and editing applications do provide a reflow function which can change the content display to a single column that remains within the viewport when the content size is increased. In the slide here, I’ve shown a document that’s open in the document panel.

You can see I’ve highlighted that the text size has been increased to 200%, and the text is flowing to the right out of the viewport. When I apply the reflow tool, all the text is reordered so that it sits nicely within the available viewport. Now, this option can be accessed through the main menu, then view, then zoom, and then reflow. My tip is use Control plus four key combination to turn reflow on and off quickly, so you don’t have to go through the menus.

Annotations. I could go on with more quirks about the ways of remediating PDF documents on the web, including 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, adding sticky notes, and drawing lines and shapes. These annotations can be used in PDF documents to add instructions to content without changing the content itself. As an example, in my slide, I have a long paragraph of text shown here that has been annotated with circles, arrows, check marks, crosses, strikeouts, highlighting, outlining, and a sticky note. Maybe you wouldn’t use all of those at once.

My tip is to check that the PDF annotations are correctly tagged to make them available to assistive technology or have been artifacted so that they are ignored by assistive technology. The big catch. You remember I talked about loading PDF documents in a reader? After all, the vast majority of users don’t have Acrobat Pro on their devices, so they will load PDFs in a reader. 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 those readers 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 they may even be okay 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 they’re installed, users need to tell their browsers not to open PDF documents in its default reader extension. Now, I’ve put on a slide here the ways of doing that, settings in Chrome, Firefox, Windows, which affects the Edge browser, and in Mac OS, which affects the Safari browser. I won’t go through the exact motions of that. They are just strings of basically following menu items to get to these endpoints where you can say, “Download the PDFs and open it in a standalone reader.”

Now, if all this talk has shaken your world and 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 webpage 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. Now, 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 and others to remediate your PDFs on the web with the caveats I’ve included. I better wrap up, but I want to finish by offering some resources for those of you who want to continue the journey into PDF accessibility. For full-on training, I highly recommend Chax Accessibility Training, the training courses, downloads, articles, and podcasts offered by Dax Castro and Chad Chelius.

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. They are very useful for step-by-step video explanations. The Adobe Community Acrobat is very useful where people pose questions about using Acrobat products and get pragmatic responses from people like Bevy Chagnon. In a similar vein, but with a broader remit than just Adobe products, the PDF Accessibility 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. Links, Mastodon, X, Blue Sky. This way, you can often find out about new products or releases. Lastly, use the guidance provided by the product manufacturers. The big three are Adobe, Access4, and CommonLook. 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 to take any questions you might have if we have time, although there’s no guarantee I’ll be able to answer them. Thank you. I’ll stop sharing.

>> PAOLA GONZALEZ: That was a great presentation, Ricky. Yes. Let me just put myself back in here.

>> RICKY ONSMAN: There we go.

>> PAOLA GONZALEZ: Amazing presentation, Ricky. We did have a few questions come in. We just have a few minutes left, so I want to make sure that I get through as many as I can. Alan asks, “Does AccessiBe allow PDF documents that were not originally accessible?

>> RICKY ONSMAN: AccessiBe, the overlay company?

>> PAOLA GONZALEZ: Correct.

>> RICKY ONSMAN: The best I can say is they say they do. I’ll leave it at that.

>> PAOLA GONZALEZ: [laughs] Most people in the web accessibility world have their opinions when it comes to overlays, and will show you–

>> RICKY ONSMAN: You’ll find that a lot of overlay companies do that. UserWay says the same thing. It provides a webpage that says it can take your PDF documents and make them accessible. I have tried a couple of those. I didn’t have a great deal of success with them. Like I said, they’re about as useful as their overlay widgets.

>> PAOLA GONZALEZ: That makes a lot of sense. A little bit more information about anything overlay-related, I’m sharing the overlay fact sheet in the chat as well. That gives a lot more information when it comes to AccessiBe, UserWay, anything overlay-related. Thank you for answering that, Ricky. Then the next question is, Sherry asks, “On my welcome screen from Acrobat Pro, it has a link to set up accessibility using the assistant. Is it okay to just click the button that says use recommended settings and skip setup, or should I go through the whole setup manually?”

>> RICKY ONSMAN: Generally, you can just take the settings as for granted. It’s really if you have a screen reader and that option comes up automatically if you have a screen reader on when you’re using Acrobat Pro. If you’ve configured a screen reader like JAWS to have a lot of personalized sessions, then you might want to go through the steps that Acrobat Pro provides because there might be particular settings that you need to synchronize so that Acrobat Pro works properly with your screen reader.

If you’re the type of person who generally takes a screen reader at default settings, doesn’t change the verbosity levels, that kind of thing, then you can pretty much just say, “Yes, just give me the standard settings.”

>> PAOLA GONZALEZ: That makes a lot of sense. Sherry also asks, “I want to double-check. A PDF file on the web needs to be accessible. Do all PDF files need to be accessible though?”

>> RICKY ONSMAN: The way I put it is that there’s nothing that says PDF files have to be accessible. What there is, is that web content needs to be made accessible. If the content is in a PDF file and the PDF file is on the web, then as far as I can see, it’s web content. Therefore, the content must be made accessible.

>> PAOLA GONZALEZ: That makes a lot of sense. We also have a question from Maureen. “When tagging links, how do you add the actual URL, starting with HTTP within the link tag if the link and the link OBJR tag is already tagged?”

>> RICKY ONSMAN: You’ll find that in the Edit link and the Create link options, there’s a button there that says what should happen when the link is activated. One of those options is go to a web page. When you click on that link, open that option in the dialogue, it gives you a choice of putting in the specific URL that the link should link to.

>> PAOLA GONZALEZ: That is some great instructions there. I just wanted to share a few of the comments. During your presentation, you were getting a lot of praises. One of them was, “This has been the most useful webinar I have attended in a long time.”

>> RICKY ONSMAN: Oh, good.

>> PAOLA GONZALEZ: “Great presentation.” “Very informative presentation, so many great tips.” “Wonderful presentation.” We did get a lot of good feedback and a lot of great tips that you shared, Ricky. Again, we do want to thank you for spending the time with us today. I think we’re just going to wrap this up right on time. Where can people find you?

>> RICKY ONSMAN: Oh, well, my website is https://onsman.com, my surname. You can email me at ricky@onsman.com. I’m @onsman on X. You can find me at Ricky Onsman on Facebook. I’m one of those fortunate people that has an unusual name, so I have very easy-to-find social media connections. I’d be happy to hear from anybody.

I should also mention that my intention is to put all the images that we used in the slides and my script together in a Microsoft Word document that I’ll also make available for download, hopefully on the same page as the presentation is so that you can look at the two things together and not have to jump backwards and forwards from words to images and so on. Y

>> PAOLA GONZALEZ: Thank you so much, Ricky. Everyone would be able to get that recap and the slides and that Word document when we make that available in about a week. You can find that on equalizeddigital.com/meetup. Again, Ricky, thank you so much for joining us today.

>> RICKY ONSMAN: Thank you, and thank you everyone for attending. I’m staggered so many people turned up. It must be very light for some of you. Thanks very much.

>> PAOLA GONZALEZ: Thank you. Bye.

>> RICKY ONSMAN: Bye.

• View “PDF Accessibility on the Web: Tricks and Traps: Ricky Onsman” Powerpoint Presentation.
• View “PDF Accessibility on the Web: Tricks and Traps: Ricky Onsman” Google Doc.
• View “PDF Accessibility on the Web: Tricks and Traps – Part 1” Full Blog Post on TPGi
• View “PDF Accessibility on the Web: Tricks and Traps – Part 2” Full Blog Post on TPGi