« Return to video

How to Create Accessible PDFs [TRANSCRIPT]

SOFIA LEIVA: Well, welcome, everyone. And thank you so much for joining us today for the webinar How to Create Accessible PDFs. My name is Sofia, and I’ll be moderating the webinar today.

And today, I’m joined by David Herr, VP of Marketing and Strategic Alliances at CommonLook, and Michele Landis, Cofounder and CRO at Accessible360. And with that, I’ll hand it over to David and Michele, who have a wonderful presentation prepared for you all.

MICHELE LANDIS: Thank you very much, Sofia. We are pleased to be here today to discuss PDF accessibility. I know it’s been a topic that the followers of 3Play have been waiting to hear some great information on. So I am super excited to have David here with me today.

As Sofia said, my name is Michele Landis. I am a cofounder and the CRO of Accessible360. We’re located in Minneapolis, Minnesota. David will let you know where he’s coming from.

And I just wanted to hit a couple of high points as far as our agenda items today. We’re going to go through why there is such an importance to focus on PDF accessibility, what an accessible PDF is, offer attendees a step-by-step guide to creating accessible PDFs, and kind of round out with why accessibility with inside of PDFs matter going on into the future.

We here at A360 audit all kinds of things. We audit websites, mobile apps, internet of things. The reason why David’s here to walk through these specific things is CommonLook and Accessible360 are now all part of different divisions with inside of T-Base Communications. And so I’ll focus a little bit on an intro here in the beginning about what we do at A360. The majority of this presentation will be delivered by David. And I’ll kick it off to him shortly.

So again, A360, we work with clients in the digital space in primarily two different ways. First of all, we do audits, where we’re diagnosing what’s wrong. And in the past, we would diagnose what was wrong on PDFs. But now we have a great solution in our other division here with CommonLook to take care of PDF remediation and related issues.

Working through an audit with A360 has a second stage with it. And that’s really all about remediation support. This is the stage where dealing with clients– we’re teaching them as much as we can about the proper ways to test manually the issues that are related to the WCAG guidelines. We’re doing a tremendous amount of iterative QA, if you will, quality assurance testing, working towards that A360 letter of conformance, and then putting our clients on more of a maintenance or monitoring type of phase to their digital accessibility initiative.

The other way that we work with clients– and this is ever increasing. It’s a lot of fun for us at A360 because we have a lot of ex-agency people working both on the client development side and in our customer success positions on our services team. When we’re working on new builds and designs, we’re working on everything from previewing your initial design files– so wireframes, Figma files, MVP in, say, Flinto or InVision– and then moving on to building accessibility in so that that launch or that release of that product can be accessible.

So with that, I just want to again summarize the coming together of T-Base Communications, Accessible360, and CommonLook. And I’m going to turn it over to David to jump into his bulk of the presentation on PDF accessibility. And Sofia, if there’s any initial questions in the Q&A or in the chat, please let us know. We would love to take questions at the end. But if there’s something urgent that needs to be addressed during the course of the presentation, we’re happy to do that as well. David, thank you.

DAVID HERR: So thank you, Michele. And welcome, everybody. I’m David Herr. I’ve been involved in document accessibility since around 2012, when I left the IT world, the data center technology world, and got into the accessibility space.

So I’m working for CommonLook. And it’s been interesting. And as I go through some of this, I’ll give you some of the perspectives as to where this was back in 2012 and where it is 10 years later.

So why the focus on PDFs? Primarily because PDFs are everywhere. They just continue to grow and expand in numbers and content and what they’re capable of doing. The whole reason that PDFs were invented to begin with was we needed a universal electronic paper, something that could be read on a PC or a Mac or, as tablets came out, on tablets and other devices.

So the PDF format has continued to stick around. I think it was first invented in the late ’90s. But it’s been something that has really stuck and has stayed. And the other reason is is that they can be so easily produced. You can be in Microsoft Office and easily generate a PDF of your PowerPoint or your Excel spreadsheet or your Word document.

They’ve expanded over the years to be able to be interactive. So images and videos and forms and links can all now be embedded into PDFs. They’ve got various security and signature capabilities built into them. And they’ve now become the third most used file format on the internet. So the first two are derivatives of HTML. And now the third most commonly used file format is PDF, even over images, like JPEGs and GIFs and things like that. Next slide.

So there’s some myths about PDF that I just want to clear up. Early on, when people created PDFs, it took a while for Adobe to add in the tagging view of a document. We’ll talk about that in a couple of minutes. But some people just say, well, PDFs can’t be made accessible.

And that’s just not true. They can be made completely accessible, meeting all of the accessibility standards, work well with assistive technology, work well with screen readers, when they’re properly created and configured. So that’s not true that they can’t be made accessible.

And then a second thing that we hear often is that it doesn’t matter that we have inaccessible PDFs on our website because we have other ways to get the information. Or we have an alternative format. Or we have them in Word format, as well as PDF. I’ve heard that in some markets.

And the truth of the matter is if somebody pulls up a document off your website, and it’s not accessible, you could be legally liable for that. So just because you may have an 800 number to call to say, I haven’t had an accessibility problem, it doesn’t mean you’re not going to necessarily still have accessibility issues if you have inaccessible content on your website. So there really isn’t a fix for this. The only fix is to make the documents accessible if they’re public information on your website. So next slide.

So I wanted to show this because when I started in 2012, I had been hearing as soon as I got into this space that PDFs were going away, that there were other, more accessible formats coming out on the market, and that this may be a problem now. But I don’t need to do anything about it because the PDFs are just a format we’re moving away from. There’s going to be other formats that we’re going to use.

And the big one we kept hearing about was EPUB– was that EPUB was going to replace PDF on the internet. So when you look at this– and this came from the PDF Association. And they track this every year. You see that PDFs were about 80% of the file formats in comparison to Word and Excel and PowerPoint and EPUB. They’re about 80% in 2011.

And we get to 2021, and it’s 85%. And you do see that EPUB has grown in popularity by the time we get to 2021. But it’s still a very small percentage of the overall number of documents.

It’s been estimated that there’s trillions of PDF documents on the internet. And I don’t know what the total number is because you can’t do a search like that anymore on Google. They’ve removed that. But it just continues to grow. It continues to be the default standard for digital paper on the web. Next slide.

So what’s the problem? Why is this such a big deal? If it’s easy to create PDFs, and they’re used commonly, and they’re such a simple format for people to create and publish, what is the problem? Adobe added accessibility to PDFs back in, I think, early 2000. 2002 or 2003 I think is when the tag structure got added.

So they’ve added the ability. And you can go into the accessibility components of Adobe Acrobat Pro. And you can add tags. So that adds a tag structure to the document, which we’ll talk about in a minute.

But there’s a lot of other issues. Just adding the tags does not mean the document’s accessible. Just adding the tags doesn’t mean that the reading order is correct or that you have alt text or you have a number of other things that I’m going to dig down deep into in a couple of minutes.

So bottom line here is that it’s difficult. It’s not easy. You do need knowledge. You do need the right skills. You need training. You need tools. If you want Adobe Acrobat as a bare minimum, you’re not going to be able to manipulate the tag tree. And you may need additional tools to be able to do a better job or an easier job than just using Acrobat.

And then the other part of the problem here is, what standard do you have to meet? If you work in the federal government, you may only have to meet WCAG 2.0 AA because I think that’s what Section 508 right now is requiring. But many other organizations are looking at a higher standard, which has more additional checkpoints you need to reach to conform the document to the accessibility standards, like WCAG 2.1 AA or PDF/UA.

So it depends on what standard you need to do it to. And then how do you test for all of that? So we’re going to cover that today in our presentation.

So we’re going to start now with, what is an accessible PDF? And I’ll apologize for a couple of these slides because they’re super complex. So we don’t need to study all the minutia in here. But I do want to cover this because it does give us a great overall of the anatomy of an accessible PDF.

So there’s two sides to this. There’s the actual accessibility components that are built into the PDF, that tag tree, if you will, which we’ll talk about. But it really starts at the authoring stage because there’s a number of components that, depending on how you created the document, are going to cause accessibility issues even before you get to the tag tree.

For example, fonts– if you’re choosing fonts in a document, and the font sizes are incredibly small, by default, somebody with low vision like myself is going to definitely struggle with the accessibility of that document trying to read it. So font size when you’re doing the authoring is a consideration for accessibility.

What kind of styles and what kind of format have you generated in the document? Have you used heading levels so that there’s a possibility to navigate the document so that somebody when they’re using a screen reader will be able to find what they’re looking for in a document and not just have to start at the top and listen to the entire document all the way down?

Color and contrast are big issues that are not part of the tag tree, or not part of accessibility from that standpoint. But they’re root to accessibility. If you’ve used color in the document, and that’s the only way that you’re denoting a particular meaning, like green is good and red is bad, if the only way that you can determine that the bad section is done in red text, that’s an accessibility concern. If I’m color blind, I’m not going to be able to discern between green and red easily.

And then color and contrast– the same thing. If you’ve created a beautiful document, and you’ve tagged it properly, and you put up alt text, and you’re reading order is correct, you could do everything correct and still have color contrast issues, it’s still an inaccessible document. And you’re going to have to go back and reauthor it with lighter and darker shades of whatever text or whatever the color contrast issues are so that the document will meet the compliance standards and be more accessible.

And then we’re going to drop into these others in a minute. But just things like lists– lists need to be formatted and structured correctly so that a screen reader will announce it’s a list. And then it’ll be able to navigate what’s in it.

Images require alt text. We’ll talk about that. Links need to be properly set up. So when you hover over them, people are going to know that this is going to take me to this URL, that kind of thing. The tag structure that we’re going to talk extensively about in a couple of minutes.

And then bookmarks and bookmarks that match table of contents, things like that, so that it just makes it easy to navigate the document. And then, finally, your tab order, tables, metadata, all of which I’m going to cover here in a second. So let’s go on to the next slide.

So this is a tagged document. I just took one of our brochures. Obviously, our brochures are tagged for accessibility and are completely accessible. But I wanted to walk through what it is to be an accessible PDF.

So when you look at the right, you’re seeing a physical view of a document. This is what people see when they open a PDF. And if they print it, it’ll print exactly like this. And if they email it, share it, pull it up on different devices, that’s the physical view of the document.

What the tag view on the left-hand side is is what a screen reader or any other assistive technology is going to see. And what it’s going to see is every element of that document is– every element of that document is now reflected in the tag tree.

So if we start at the top, we have a tag that just says that this is a document. And then we see three figures. And if we look over on the right, you see CommonLook, and you see CommonLook PDF as a figure. And we see the Certified Section 508 Compliant logo. So each of those figures would have alt text if they’re not decorative or they’re not– if they convey any information that’s necessary.

So each one of those would have an alt text description. So if I’m using a screen reader, and I use my mouse– or excuse me, I use my keyboard– and I navigated to the CommonLook Certified 508 Compliant logo, it would then read to me what the alt text was for that image. And I’ll say, oh, wow, they actually have a certification for their accessibility.

So then we have heading levels. So if I’m navigating this document, what is this? Oh, it’s CommonLook PDF. OK. Well, what is that? I go to heading level 1, which I can do with my keyboard. And then I can read the heading level and have it read to me using the screen reader and say, yes, this is something that I want to read further on.

And then I can navigate further down the tag tree using my Tab key on my keyboard. And then I see there’s a paragraph. And then I encounter heading level 2, which is the features. Oh, I do want to know about the features.

And then when I hit Features, I go down and see that there’s a list. And then in that list, the screen reader would announce, if it’s properly tagged for accessibility, that, oh, this is a list. It contains six elements. And then it could read me each of those buttons in the list or bullets in the list so that I could learn about the product.

So I can navigate this thing. I don’t have to physically see it. I can use a screen reader. I can navigate the document. I could drop down to the fourth bullet if that’s what I wanted to see.

So that’s pretty much wrapping it up. This is the tag tree. This is what a screen reader uses or another assistive technology would use. This is what it sees. And then on the right is the physical view of the document that you could print or read on a screen. So that’s what a tagged PDF looks like. I just saw there’s a question on tables. And we will talk about tables, yes.

So I’m going to do kind of a step-by-step guide to creating accessible PDFs. It’s not going to be how to use Adobe Acrobat to fix PDFs or CommonLook PDF to fix PDFs, but all of the elements in a little more detail on what needs to be done on a document to go through it and to make sure it’s accessible. So we’ll move on to the next slide, and we’ll get started on this.

So this is another busy slide. And again, I apologize for how busy it is. But when we look at this, there’s really eight steps that we see to creating an accessible PDF. These are the things you need to go through in whatever tool you’re using to ensure that it’s going to meet the accessibility standards, that it’s going to work well with assistive technology, and that you can be assured at the end that you’ve done your job right. And you now have an accessible document.

The very first thing is it needs to be tagged. And we’re going to go into each of these in detail. So it needs to have the tag tree that we just looked at. It needs to have a minimum of a certain amount of metadata, which would describe the document. The color and the contrast needs to be reviewed and fixed if it needs. And that’s on the authoring side of the document.

You have to have alt text for any images in the document– charts, graphs, whatever needs to be done– so that if they mouse over those images– mouse over. If they tap over those images, they can then hear what– if it’s a chart or a graph and it’s describing a lot of information, you can read that or hear that through the screen reader.

Lists need to be properly formatted so that they work well in a screen reader. Tables are a big, big deal. People use tables for various reasons. So we’ll talk extensively about tables here in a couple of minutes.

And then there’s some additional tagging functions that need to be done. Call it cleanup, so to speak, that once you’re done with the first six steps, you’re going to do this cleanup in the tag tree so that you can then do your testing, which is the last thing to test the documents. Test them on the screen reader. Test them with assistive technology. Test them with tools that will certify them to the standards. So next slide.

So tags and the reading order are really the first step to making your document accessible. If a PDF is not tagged, by default, it doesn’t meet WCAG 2.0 or 2.1 or PDF/UA. So the file must be tagged. Many tools today will add tagging to a PDF.

If you go into Microsoft Word and you create a document and you save it as PDF– and even better, if you’ve used the accessibility tools in Microsoft Office to have at least established heading levels and a few other components of the accessibility tool that they’ve built in– it will now generate a tagged PDF. It won’t be perfect. It won’t be great. It really depends on– if it’s a simple document, the tool will do a decent job of tagging it.

If it’s a more complex document, if it contains tables, if it contains lists, if it contains other content, the Microsoft tool will probably not tag it well. And you’d still need to open it up in Acrobat and do a lot of cleanup or CommonLook and do the cleanup.

So what you could do with a PDF file that is not tagged is you would open it in Adobe Acrobat. And you would go into their accessibility tools. And you can then add tags right from the toolbar there. And then what you’ll show, then, is when you open up the document, you’ll see that tag tree off to the left.

Now, once you’ve added the tags to the document, your work has just begun. It hasn’t ended. It’s just begun. There’s a number of things that have to happen.

First of all, each tag needs to properly reflect the content within the document. So the Adobe tool does its best ability to be able to look at the document and to determine if it’s a heading level, determine if it’s a paragraph, determine if it’s a heading level 1 or 2 or 3 or a link or whatever it is.

So you have to go through and basically tab through the tag tree, looking at the physical view of the document, and see what it is that each file is– each tag is pointing to and say, yes, that is a heading level 1. Or if it’s not the right heading level, you need to go in and change it to proper heading levels or proper– or this is a paragraph or this is an image, that kind of thing.

If it’s an image tag, and it identified that there’s a figure, you’re going to go into that image. And you’re going to add the alt text description for what that image is used for in the document. What information is it describing in that chart or that graph or that picture of something that was included in the document to enhance the document so it needs to have an alt text description?

Sometimes you’ll have an image that’s tagged as a figure. And it doesn’t need to be because it’s really just a decorative background. So that’s something– you would remove that, and you could artifact that image so a screen reader won’t announce there’s a figure and then not have alt text. And then that can confuse people.

So there’s a lot of work that you have to do going through that tag tree, cleaning it up. And then, finally, when you’re done cleaning up the tag tree, you got to make sure it’s in the right reading order. Very often, when tags are added to PDFs, it’s because of the way PDFs are created, the content can be in layers.

So if the tag order is completely out of order, the screen reader is going to read it completely out of order. So it might start at the top of the document, jump to the bottom, read a footer, and then it may jump back to the middle, and then it might jump to a figure, and then it might jump to a paragraph in the middle.

That’s not how the document was authored. That’s not how the document was meant to be read. So you need to rearrange that tag order so that it matches the physical view of the document so that it would make sense to somebody listening to the document, tabbing through the document’s tags, and that they would be able to understand– this document would make sense to them, rather than be very confusing.

So that’s tags and reading order in two minutes, three minutes. You could talk for a couple of days on this one. But that’s the first step of many. So let’s go to the next slide.

So metadata– very simply, this is just the description and title information, the author, what language the document’s in. It’s the kind of thing that somebody that might encounter a PDF document can listen to that in the screen reader and then decide, yes, this is a document. I am interested in this. Let me open it up. And let me now go through the document to find what I’m looking for.

So metadata is important. It’s required for some of the accessibility standards. And this is minimal metadata. I think title and document language are required. There’s a few others that may be required as well. So metadata is pretty simple. But it needs to be included in the document for it to meet the accessibility standards.

So color and contrast– so you fix these in two different ways. And as I said earlier, there’s nothing wrong with using color in a document. You can use color, of course. It’s perfectly fine.

But one of the WCAG criteria around the use of color is that color can’t be that only means of conveying information, where I talked about if green was good and red was bad for some reason. If you had done that, and the only way to know what was the bad data is by seeing that it was in red, that would not meet the WCAG criteria. Somebody that’s color blind would struggle with that. And that’s why you can’t do that.

So as you author the document, you’re not going to do this in the tag tree. You’re not going to do this in Adobe, per se. But you’re going to do this in looking at how the document was created. And you need to see if there was a use of color that’s not appropriate. And you’re going have to go back to you however you authored the document to make that change if you can’t change it right in Acrobat.

Same thing, then, with contrast. You’re going to need to use a third-party color contrast tool. There’s a number of them out there. I know WebAIM has one that’s free. And there’s some others.

And most of them basically let you look at the document and then basically take samples of the areas that look like they’re out of compliance. And it will tell you whether they meet the correct contrast ratio for the accessibility standards.

MICHELE LANDIS: Sometimes that fix, David, is real minimal. And it’s not even– in our work, anyway, I’ll add that when you’re originally designing things or you’re asked to go back and fix things to make sure that they comply, the change that’s suggested in color, to my visual eyes, sometimes isn’t even all that perceptible.

A lot of what we went through a few years ago was websites that had a really pale, gray font and a white background. They were all the design rage for a while there. And the reality was they had to darken up that pale, gray font in order to meet the requirements. Have different font sizes.

So color contrast shouldn’t really change or interfere with your brand, your brand guidelines, your style sheets, and all that kind of stuff. But there might be a little bit of tweaking if you would like to meet the WCAG criteria directly. And also, logos are excluded from this. So I just wanted to throw that in.

DAVID HERR: No, that’s great. So if you have color contrast concerns, go get one of the tools, WebAIM or one of the other ones that’s out there, that you can then just use to test it. And just make sure that– I mean, sometimes it’s obvious. If you got light text on a gray background and it’s hard to see, those are pretty obvious. But then sometimes, as Michele said, it’s the actual change you have to make is really, really minute. But it is what it is.

OK, so alt text. So anything that’s an image on a PDF document is going to have to have alt text, an alternative text description of what it is. In this case, the CommonLook training logo is a very simple alt text of “CommonLook training logo” because that’s all that is.

Sometimes that might even be considered decorative depending on why it’s there. But in this case, it’s the name of this document. It’s what this document is about, so it does convey information. So it’s worth having an alt text for it.

But when you get more complex is where you get into something where you have a chart or a graph. And you now have to really describe what it is in that chart or that graph that you’re trying to show somebody, which is the reason you put it into the document. So alt text descriptions can get pretty lengthy.

Sometimes they need subject matter experts. It could be an engineering drawing for a construction project, and you can’t just describe that. A layman can’t describe that. So sometimes you do need a subject matter expert, an engineer to write whatever the reason they put this engineering drawing in a particular document.

So alt text descriptions can be simple and easy. Or they can sometimes be really problematic, depending on the documents, how old they are, who authored them. So that can be a problem at times. Next slide.

So lists are pretty commonly messed up. And a lot of it’s just due to authoring. It’s very easy in Microsoft Word to create a list and then hit the List button again. And then you really have two lists. But you have it on screen as one list. And it can get confusing when you then go to tag it.

So the bottom line is when you have a list in a PDF document, it needs to be identified as a list. It needs to have the label on the body and then what the bullets are so that when you hit it with a screen reader, and you’re doing your navigation, it will be announced as a list, one list with six bullets in it. And then you can Tab to each bullet and listen to each bullet. Or you could Tab to the fourth bullet if that’s all the one you wanted to listen to.

So lists need to be properly created so that they don’t create accessibility headaches and issues for the people using the documents. And as you see in this picture, what the tag structure looks like for a properly tagged list. Next slide.

Tables, tables, tables. So tables have traditionally been one of the biggest problems in making PDFs accessible because heading levels can be simply mastered. And paragraphs and putting the tags in the proper reading order and stuff can all be done. You can learn how to do it and make it work and not have problems.

But tables can be very complex and very time-consuming to make accessible, especially if you don’t have tools that can assist you in it. And what I mean by that is if you have to go into Acrobat, and you’ve got to go to each cell of the table, and you’ve got to put in all the criteria for it being a table, and you’ve got to mark which ones are table header rows and table header cells and all of that, it can be very time-consuming with large tables to tag them properly. And the tag structure is pretty complex for that.

So first of all, you need to determine, is it even a table? Many times, people that are authoring documents will insert a table in a document. And they’re really just using it to format.

So for example, if you look at this page here, this slide, this is not a table. It’s a list on the left-hand side, and then it’s a figure on the right-hand side. But somebody could have created a two-cell table in Word and then put a picture and the image in one cell and then put the list in the other cell and called that a table.

If you converted that from Word to PDF, it’s going to come over as a table because that’s what it was. But when you get into the PDF tagging structure, it’s really not a table. You’re going to confuse somebody. There’s no heading levels. There’s no column headers in this because it’s not a table. So I can’t tag it with column headers. So it needs to be converted back to a list on the left and a paragraph on the right– or figure on the right.

So that’s tables. If they are actually tables– in our software, we actually have the ability with a table editor to go in, identify it as what type of table it is– is it a presentation table, which means it’s not a table? Or you can put in how many column headers and how many column rows are in the tool. And then it will auto-populate all the table header cells, marking them correctly so that the document can be read. You basically are just identifying the structure of the table. And then it does all the hard work for you. Next slide.

MICHELE LANDIS: I wanted to see if there were any particular questions on tables. I know there had been earlier. Do you want to take those now, David? Or do you want to wait till the end?

DAVID HERR: We certainly can if somebody has a table question.

MICHELE LANDIS: Sofia, can you help us out there?

SOFIA LEIVA: Yes. I did have one question come in that says, sometimes the links in the table of contents don’t work in PDF, though they work in the source document. Are there steps that the author can take to ensure that links remain operable?

DAVID HERR: Yes. Table of contents– if it works in the source document, it can be set up properly in a tagged PDF to work correctly. I’m guessing there’s something specific in that document that’s throwing off the tagging. And if you’re doing it maybe in Acrobat, there’s another step you have to do. I’d have to see that offline as far as exactly what you’re doing. We can certainly answer the question and give you a tip on that. So after the presentation, if we get a list of questions like that, we can come back with the answers, get your contact information, and help you out.

MICHELE LANDIS: Perfect. Sounds good.

SOFIA LEIVA: Another question we had are, what table tools do you recommend?

DAVID HERR: In our case, if you do this in Acrobat, it’s cell-by-cell, putting in the proper information into each cell so that they’re marked correctly. Using CommonLook PDF, you can tag tables in 30 seconds, complex tables in 30 seconds, by answering a couple of questions.

Actually, it’s what we’re showing on the right-hand side here, where you would pick what type of table it is. And then you would tell the tool how many columns there are and how many rows there are. And then you would identify the heading level, the header cells. And then it would then auto-populate, auto-tag that whole section of the document. And then you could go through it and listen to it and see that it’s working properly.

So there’s certainly tools on the market that will make this much faster and quicker. And again, check out commonlook.com. We can certainly help you guys out.

MICHELE LANDIS: Yeah. What I would say from the A360 side is if you’re using a table, like maybe a shipping rate table or maybe a financing rate table, like if you’re at a bank or something, and you’re putting those into a website, what we offer is access to a knowledge base that shows you in the code how to set things up properly.

And one of the first questions is, as David is articulating, do you really need this to be a table? Or are you just using that for display purposes? And so the A360 knowledge base on a code level when you’re developing, say, in WordPress or if you’re doing something on another type of code stack, it will give you directions on how to do it correctly in the code.

I think also what we’re talking about, David, here is if the table came from Word originally or it came from a Google Doc originally, there are tools with inside of those software that you can help structure the table correctly. I’ll go ahead and move on. And then we can follow up later on any of those deeper questions.

DAVID HERR: Yeah, absolutely. So then after you’ve gone through the end of this, there’s going to be some cleanup that you’re going to need to do. And first of all, it’s really good to know how assistive technologies work. If you don’t have a screen reader, it would be good to get one. There are some free ones out on the market that you can just download and then listen to your documents to see how they perform.

But if you understand how assistive technology works, then it’s going to make it a lot easier to apply best practice decisions to how you make your documents accessible. For example, empty tags– Adobe, when you tag a document, will sometimes just have empty tags for content that was there, then it was deleted. But it’s still there, sort of in the document, even though you can’t see it. So it gets tagged. And so you want to remove empty tags because they’re going to be confusing to a screen reader.

Adding a document tag so it knows what it is– this is a document. Bookmarks so that they match the heading levels in the document so that it’s easy to navigate. And then running an accessibility check against the document. In the next slide, we’ll talk about that.

So testing– you’ve now tagged your document. You’ve gone through all the steps that we’ve talked about. And you’re feeling confident that you’ve got a good document that would work well with a screen reader. So how do you verify that it’s standards compliant? How do you verify that it works well with a screen reader?

One thing you can do is use it with a screen reader. If you have somebody in your organization that uses a screen reader, that would be an ideal way to see that the work that you’re doing is quality and that it’s meeting the standards. Just have somebody that uses assistive technology actually try out the documents and see that they’re seeing that, yes, they can navigate it, they can find what they’re looking for, that it’s meeting all of that.

If you don’t have somebody that uses a screen reader, you can download a screen reader and try it yourself. The problem is it’s not the same experience because you have your mouse. You might use your mouse where somebody who is blind wouldn’t use their mouse. And so you might do something that they wouldn’t do. And that’s not really proving the point.

But there’s accessibility testing tools out there that you can use to test PDFs. CommonLook has one that’s free. And then there’s the PAC 3 tool that many people are probably familiar with. But what these tools do is they run through the checkpoints. And they test the document, the tag structure. They verify that you have alt text. And they verify that the document’s format and image– the reading order is correct, things like that.

Now, in our case, our tool will actually– whoever tests the document will actually ask for the things that the computer can’t determine. So I believe with the PAC 3 tool, it will look and see if there is alt text. But it can’t confirm the alt text is valid or not.

In our case, our tool will say, yes, there’s alt text. And then it will actually show the person that’s testing the document the alt text for them to say, yes, that is descriptive. That’s describing what the image is, so that when you pass it, you pass it. So you can use these free testing tools. And you can get a good understanding. Does the document meet PDF/UA or WCAG 2.1?

Unfortunately, I just see somebody asking about InDesign. There isn’t a tool that I know of for accessibility testing within InDesign that I’m aware of. So right now, unfortunately, there is not. So let’s go to the next slide, in the interest of time here.

And this, again, is another busy slide. And I’ll go through this pretty quickly. But many people faced with a document accessibility issue will be looking at, geez, we just discovered we got 10,000 PDFs on our website, and they’re not accessible. And legal’s telling us we’re going to have to fix this. And this is becoming a big problem. And how do I deal with 10,000 documents, which means 30,000 pages of content that need to be fixed?

So we’ve created this multi-phase document accessibility plan. And it really goes around these five steps. You need to figure out the extent of the problem.

So as I just said in that example, I got 10,000 documents. And what do I do with 10,000 documents? You don’t have to do them all at once. And you don’t have to do all of them, necessarily. But you do need to figure out what you have. Why is it there? Does it still need to be there?

Maybe what are the files that are accessed most common when users come to my website? If our budget file is the most commonly accessed file, we’ve got to make sure that one’s accessible first because everybody’s using that file. And then we can go back and look at the documents that are older.

Or maybe legally, they still have to be on the website. But we can do those later because they’re not accessed very often or not at all. But we’re going to want to get them. So you want to assess the situation.

Then you’ve got to fix the problem. And you can fix the problem. You can outsource it. You can do it internally. You can do a hybrid approach, where you work on some documents internally and some documents you outsource. We’ll talk about that in a couple of minutes here.

And then the last two are being proactive. So you need to look at, how do we train our staff? How do we teach accessibility in our organizations so people author documents with accessibility in mind, and they’re not just continuing to add to the problem?

You’re going to want to train your staff. You’re going to want to train the people that are uploading to the website. Maybe they test the content before it’s put up on the web instead of just publishing what people are sending them. And you have a process to fix that.

And then, finally, you need a way to monitor it. Because it’s great to go fix your website. It’s great to go get everything up to speed. And then if you are continually adding to the problem with new documents that are being added to the website that aren’t accessible, you’re not getting anywhere. You’re just going backwards. So having a way to test your website and then find out that you’re continuing to either publish successful content or you’re taking a step backwards is critical.

So many times, people will outsource their remediation. They get this large project, and they have to do it quickly. And they’ll outsource it to an organization. And I just wanted to cover a couple of things you should consider if you’re going to take that approach. Go to the next slide, and we’ll talk about that.

First of all, the problem with PDF accessibility is the WCAG standards or the PDF/UA standards are constantly being expanded upon. They’re adding additional accessibility requirements to the standards. And there’s always been a little bit of, I’ll do it this way, you’ll do it that way. That’s how we’re interpreting the rules.

So you really want to make sure that you’re getting what you’re paying for and that you really have documents that are truly accessible. So you’re going to want to make sure that you get some kind of an accessibility report from whatever vendor you use. You really want to make sure that they can prove that what they’ve done is tagged the documents and that they meet the standards.

Here at CommonLook, we’ve had to redo the work from other vendors over the years that a government agency paid a bunch of money to somebody to do some work, and they really didn’t do a good job. And then they have to go back and redo the tagging because it wasn’t done correctly. So you want to make sure you get some kind of a report. You want to make sure they guarantee their work. And it’s really, really important.

So just with that, I’m going to turn it now over to Michele. And we’re going to talk about why all this matters.

MICHELE LANDIS: Thank you, David. We just have– I want to be real conscientious of time here. We want to talk about why we’re doing all this, the equitable access for people with disabilities. There are four main types of disabilities that we focus on, not only in our compliance work in the two, three divisions of our company, but also just in an effort to be good humans and protect the civil rights of all humans.

Those people with low vision or other types of vision disabilities, including total blindness. Those with mobility or physical disabilities. These can be temporary. You could fall off the uneven bars and break both of your wrists, unfortunately, and have both hands in a cast. And you might need a different type of keyboard-only access versus using your mouse or mouse tracker.

Or, obviously, they can be permanent. There are cognitive disabilities. And there are also auditory, or those that affect our hearing. Again, these can be temporary.

I will tell you a little bit of insight. I’ve been teaching continuing legal ed classes on this niche area of business compliance for a number of years. The cognitive requirements, cognitive disabilities, or accessibility features and enhancements and success criteria in the proposed 2.2 version of WCAG will include more cognitive things. So as we learn how better to make the digital world work as easily for those with disabilities, cognitive will be an area that we’ll add some criteria to.

So again, the World Health Organization, the UN, many global organizations focus on digital accessibility. In the United States, we focus on the WCAG guidelines, some specific state laws and requirements, like the California Consumer Privacy Act and the Unruh Civil Rights Act in the state of California. More states will be adopting stricter, more explicit legislation on how to meet accessibility standards, not only for the privacy notifications, like the cookie notifications on the bottom of websites, but for tracking information and all kinds of things.

As you’re looking at this holistically with your organization, the compliance laws and standards– they really help mitigate legal risk. We’ve always been focused at A360 about a proactive approach, understanding what the requirements are, the proper methods of testing and remediation, which incidentally do not include an overlay or a widget or a plug-in.

There’s some recent structured settlements and a ton of information coming out about those types of approaches. Today’s webinar is not about that. But I want to make sure that you understand there are certain plaintiff attorneys that actually look for overlays. They’ll screenshot them and include them in a lawsuit. So please educate yourself. Refer to your own legal team for advice and action there.

But what we’re talking about is really making sure not only are the digital products and PDFs within them, for example, compliant with laws, but they’re also highly usable. So not exactly the same thing– if you can’t get to full compliance, please work on removing any total barriers or total blockers and any critical issues out of your digital properties so that you are as usable as possible for those with disabilities.

David, as you said earlier, there’s a massive quantity of documents that are added to websites each year. One hot area I can tell you– again, I hate to bring the stick back into this. But any of you focused or any of your organizations focused on ESG, the Environmental Sustainability Governance, there’s a new report, then, that you annually produce and put on your website. Inevitably, that’s typically a PDF.

Any investor information, investor websites, those with stock prospectus and those types of things, are being hit at ever-increasing numbers. And so be aware of those types of things, including onboarding personnel into your organization.

Are your HR benefits– not only was your HR portal– is that accessible for somebody to apply to work at your company? But what about all the forms you have them fill out for their health care benefits or their 401(k) setup or elective things? When you change benefits or get a new provider list, are those things being provided in an accessible manner? A lot of things I think that haven’t really occurred to everyone out there.

But we’re really grateful that you spent the hour with us. It went by super fast. David, thanks for all of your deep knowledge on PDF accessibility. We want to open it up to any questions. We’re happy to hang out until we get these answered. Thank you.

DAVID HERR: Absolutely.

SOFIA LEIVA: Yes. Thank you so much to you both. This is an incredibly informative webinar. And we have had a couple of questions come in. And the ones that we can’t, we’ll be sure to compile them and send them over for any feedback.

So the first question I have here is, I have issues turning Canva PDFs into accessible PDFs using Adobe Acrobat. Do you have a platform you prefer to make the PDFs before you make them accessible in Adobe Acrobat?

DAVID HERR: So you’re referring to a– read the question one more time. I’m sorry.

SOFIA LEIVA: Of course. I have issues turning my Canva PDFs into accessible PDFs. Do you have a platform that you prefer to use?

MICHELE LANDIS: I’m going to just– first of all, I love Canva. We use it. We struggle, too, with that. So we’re hoping that this reaches them because we would like nothing more than to continue to use it.

So I’m not in a position to really recommend a different platform. You’d be surprised how many have not yet addressed it. But I will be the ultimate optimist. I’m going to tell you that I hope they do, and I hope a ton of others address it.

I’m certainly happy to ask my customer success managers in our services team what we’re coming across in our audits as far as another option, David, if there’s anything that you can think of. They’re generating really cool marketing pieces, like we’ve both done so often before. What do you think?

DAVID HERR: I’ll have to talk to Paul or some of our tech folks and see if anybody– if there’s anything they know about that. So we’ll take that one offline.

SOFIA LEIVA: Great. Thank you. I have another question here. Sometimes when you auto-tag PDFs, it removes some mathematical symbols. Would you know how to fix this?

DAVID HERR: Yes. Math is not completely supported in PDF at this point. It’s going to be in some of the new updates to PDF/UA-2 and, I think, PDF 2.0.

So right now, the only way to take a math formula and properly tag it for accessibility is basically to create a figure tag and then have alt text for that math symbol or that math equation that can describe or read out what that math equation is. Because yeah, the tagging will not– it can’t be properly tagged when you just tell Acrobat to tag the content because it doesn’t know how to read it.

SOFIA LEIVA: Thank you. The next question we have is, does the PDF Read Aloud feature perform the same way as other screen readers?

DAVID HERR: It does not. In fact, I know a lot of people will use that and say, well, I listened to it in Read Aloud, and it worked great, so it must be fine. And the truth of the matter is you’re going to miss a lot of accessibility issues if you’re only relying on that as your test.

SOFIA LEIVA: That’s great to know. Thank you so much. The next question we have is, are both bookmarks and tags needed? Can you use one or the other?

DAVID HERR: Bookmarks and tags. Bookmarks are just a good authoring feature when you create PDFs. But if you don’t have tags, then it’s not going to be accessible by definition. So they kind of go hand-in-hand. If you bookmark, you’re going to then want the tag structure to describe what’s in the bookmark so that it makes sense. So without tagging, it’s not accessible.

SOFIA LEIVA: Thank you. The next question we have here– what is the right way to ask those with a disability in an organization if they can provide their input on their needs?

DAVID HERR: Michele, you want to take that one? The best way to ask people in the disability community for their needs– what’s the best way to do that?

MICHELE LANDIS: Yeah. If you’re not using a vendor that employs people with disabilities and seeking community support, I would reach out to any groups like Lighthouse for the Blind. We know a couple of others, David, that we partner with.

So if you don’t want a vendor that employs people with disabilities, like A360 is so proud to do, then community sourcing– there’s also some school for the blinds in every state and major metropolitan area. Again, I have no idea where you’re located. There’s also– you know what? I just came across this the other night. And I’ll try and find it again and send it to you. One of the side hustle companies, if you want to call it that, is employing people with disabilities to do user testing.

So again, the big difference is you’re going to get somebody that has a disability that uses assistive technology. And they could tell you, I got it to work, or I didn’t get it to work. I wouldn’t use that as a basis to make any business decisions, however, because lay people with disabilities testing things and telling you pass, fail, yeah, I could get it to work, I couldn’t is very different from having your product assessed with the specific success criteria by people who are skilled in testing for accessibility.

In other words, you might get feedback that leads you to believe that your product isn’t working. And the reality is it is working for the majority of people, or could work for the majority of people. But that tester just didn’t have enough knowledge or experience. So I’d be wary of that. In other words, don’t assume that everybody that has a disability is an accessibility tester.

SOFIA LEIVA: Thank you. The next question we have here relates back to tables. Is it OK to leave a cell blank in a table?

DAVID HERR: Off the top of my head, I believe it is if there’s no data in the cell. But our PDF accessibility training team might tell me that that’s not correct. So we’ll have to take that one offline to make 100% sure.

MICHELE LANDIS: Good question.

SOFIA LEIVA: Thank you. The next question I have here is, if I have a fully compliant web page with WCAG 2.0 and I save it as a PDF document via a Print action, can I be sure that my result is fully accessible– will be a fully accessible PDF document? Or in some cases– or in some cases is there– yeah. Will it be fully accessible?

DAVID HERR: So you’re taking compliant HTML, and then you’re using a Print function to print it to a PDF. So it’s not going to bring over a tag structure. It’s not going to create a tag structure. You’d have to open up what you created from your browser from that compliant website to a PDF. You’d have to open it up in Acrobat and then add tags. And then you would have to tag it. So it wouldn’t be accessible out of the box.

MICHELE LANDIS: Correct. In other words, what you’re doing is you’re basically scanning a website. So think of it– when you print to PDF, you might as well just take your camera and take a picture of it. That’s about how accessible it would be.

DAVID HERR: Even though your website was accessible, that’s–

[INTERPOSING VOICES]

MICHELE LANDIS: Yeah. Completely different, yeah. Same world, different planets, I think, is how that phrase goes. Yeah. I hope that helps.

SOFIA LEIVA: Thank you. Yes. So I believe we have time for one more question. And I have here, are bullets in unordered lists marked as artifacts? Or does a list label tag announce at all?

DAVID HERR: You guys are getting me on the technical questions.

MICHELE LANDIS: Yeah. Formatting with bullets, I think, is the question, right, David?

DAVID HERR: Yeah. And I do believe the bullet itself is artifact. But again, Paul would tell that we have to be 100% on that one. I believe they are to be artifacts. There’s no reason to hear on the screen reader that this is a bullet. It’s just going to list the list. So I’m pretty sure the bullet itself is artifacted. But again, we can answer that one offline.

MICHELE LANDIS: Yeah. And then just think about, too, is your goal full compliance? Or is your goal usability? If your goal is usability and readability, all of that content is going to be delivered just as I would read it as a visual reader. If you need it to be 100% compliant and you want it formatted in a list, then you take it to that next level.

DAVID HERR: Yes. Somebody that’s down in the bottom of the screen, NVDA will announce a bullet as a black square, which is just confusing. That’s not going to help people.

MICHELE LANDIS: Yeah. Yeah. My cofounder Aaron Cannon would say, you get used to your own screen reader. There’s also settings within your screen reader that you can adjust to handle formatting things and how you want them read out. So make sure that you delve into that as well.

Again, define your goal first– readability, all content is delivered, none is bypassed or obstructed. And number two, if you want full compliance. So happy to follow up. Those are excellent questions.

DAVID HERR: Absolutely.

SOFIA LEIVA: Yes. No, thank you so much to you both, David and Michele, for such an informative webinar. We had a lot of really great questions. And you provided so much great insight into how to create accessible PDFs. And we really appreciate it.