A Practical PDF Remediation Demo: Samantha Merrett  🔗 **Source:** [A Practical PDF Remediation Demo: Samantha Merrett](https://www.youtube.com/watch?v=Eve9lbc5zDQ) > [!note]+ Document Notes > --- > tags: ["pdf-accessibility", "document-remediation", "wcag", "screen-readers", "adobe-acrobat", "inclusive-content"] > author: "Samantha Merrett and Amber Hinds" > source: "YouTube" > reference: "https://www.youtube.com/watch?v=Eve9lbc5zDQ" > date_created: "2026-07-22" > --- > # 🏷️ A Practical PDF Remediation Demo: Samantha Merrett > ## 🧭 Table of Contents > - References > - Summary > - Main Content and Notes > - References > - Paraphrase > - Newsletter > - Action Items > - Hypotheses > - Methodology > - Questions > - Future Research > - Implications > - Learning Styles Assessment > - Accessibility Assessment > - DEIB Assessment > - Logical Validity > - DARVO Analysis > - Conclusion > - Refactor Appendix > - Template Library > ## 🔗 References > - [Original video](https://www.youtube.com/watch?v=Eve9lbc5zDQ) > - [WCAG 2.2](https://www.w3.org/TR/WCAG22/) > - [PDF/UA overview](https://pdfa.org/resource/pdfua-in-a-nutshell/) > ## 📝 Summary > **What happened:** Samantha Merrett demonstrates how to decide whether a PDF is necessary, prepare Adobe Acrobat, inspect and repair tags, headings, lists, tables, figures, artifacts, reading order, bookmarks, and document metadata, then test with automated tools and a screen reader. > **Why it matters:** PDFs often preserve visual layout while losing the structure assistive technology needs. A repeatable repair and testing process can restore access, but remediation is costly compared with fixing the source or publishing HTML. > **Stakeholders:** Disabled readers, public-sector publishers, WordPress site owners, document authors, accessibility specialists, procurement teams, legal teams, and organizations publishing policies or forms. > **Risks:** An Acrobat checker can pass a document that still has a bad reading experience; edits can corrupt tags; a fixed-layout format can resist zoom and reflow; paid tooling and specialist labor can become access barriers. > **Bottom line:** Ask whether the content should be a PDF first. When PDF is required, repair semantic structure and reading order, save versions often, rerun automated checks, and complete manual screen-reader testing. > ## 📖 Main Content > ### 1. Challenge the format > The most accessible PDF may be no PDF. Check whether print fidelity or legal form preservation is necessary and whether HTML or the source document meets the user need. > ### 2. Build the right workspace > Acrobat Pro exposes tags, reading order, bookmarks, accessibility checks, and document properties. These tools must be visible before repair work starts. > ### 3. Repair semantics, not appearance > Headings, paragraphs, lists, figures, tables, links, artifacts, and language metadata tell assistive technology what the content means. Visual resemblance is not enough. > ### 4. Reading order is a human judgment > The editor must decide a logical sequence, then verify that the tag tree and reading-order pane match that intent. > ### 5. Testing needs several layers > Use Acrobat and PAC for automated signals, then inspect tags, resize and reflow, and listen with a screen reader. Save copies because Acrobat undo is limited. > ## 🗒️ Notes > - A successful source-document conversion is a starting point, not proof of an accessible PDF. > - Artifact tags hide content from screen readers and should be used sparingly. > - Bookmarks matter for long documents and are easy to miss in basic checklists. > - Visual defects such as contrast and broken charts should be fixed in the source before PDF repair. > - The demonstration centers Acrobat Pro; alternative tools and organizational access to licenses need separate study. > ## 📚 References > - The transcript is the primary record of the demonstration. > - WCAG 2.2 supplies outcome criteria; PDF/UA supplies PDF-specific technical expectations. > - Tool behavior should be rechecked against current Acrobat and PAC versions. > ## 🗣️ Paraphrase > 1. PDFs can be accessible, but conversion from Word does not finish the work. > 2. Before spending hours on tags, ask whether fixed layout is truly required. > 3. Set up Acrobat so tags, reading order, bookmarks, properties, and accessibility checks are available. > 4. Use semantic tags to express structure and remove empty or misleading tags. > 5. Add useful alternative text and mark only genuinely decorative material as artifacts. > 6. Check tables, lists, headings, language, title, bookmarks, and reading order. > 7. Automated checkers find some defects; manual inspection and screen-reader use find the rest. > 8. Save frequently and repair visual source problems before final PDF work. > ## 📰 Newsletter > ### The best PDF fix may be an HTML page > PDF remediation is less like pressing an accessibility button and more like rebuilding a document’s hidden skeleton. Samantha Merrett’s demo starts with the right question: does the content need fixed layout at all? If it does, the work moves through tags, reading order, figures, lists, tables, bookmarks, metadata, and testing. > **WordPress angle:** WordPress publishers should prefer accessible HTML for web-first content, offer an accessible PDF only when the format serves a real need, and keep the HTML version equivalent and easy to find. > ## ✅ Action Items > ### DevRel > - Publish a WordPress-to-PDF decision tree and a remediation lab with a broken sample document. > ### OSPO > - Fund open PDF checking and repair tools so accessibility does not depend on one paid desktop product. > ### Community > - Invite disabled document users to review the publishing checklist and compensate their expertise. > ### WordPress teams > - **Core:** Improve media and document metadata surfaces without claiming WordPress can certify PDF accessibility. > - **Core Performance:** Measure user-visible cost before proposing a performance change. > - **Core AI:** Test the claim in a disposable WordPress workflow with explicit permissions and evidence. > - **Core Program Team:** Route cross-team work to named owners and a release milestone. > - **Mobile:** Check the equivalent task on small screens and with mobile assistive technology. > - **Playground:** Publish a disposable reproduction or teaching lab when the claim can be demonstrated safely. > - **Community:** Turn the strongest lesson into a contributor discussion with affected users represented. > - **Training:** Teach HTML-first publishing and a PDF remediation decision tree. > - **Marketing:** State the user benefit without turning an example into proof. > - **Support:** Add a diagnostic question when the source exposes a recurring support failure. > - **Design:** Check focus, hierarchy, error recovery, comprehension, and alternate interaction paths. > - **Documentation:** Document how to offer equivalent HTML and PDF versions with clear link purpose. > - **Photos:** Use inclusive media with accurate alternative text when visuals support the lesson. > - **TV:** Publish captions, a transcript, and chapter markers for any related recording. > - **Polyglots:** Flag terms that need translator context and test text expansion and right-to-left layouts. > - **Accessibility:** Maintain a manual PDF test guide tied to WCAG 2.2 AA and PDF/UA. > - **Meta:** Check whether WordPress.org discovery, metadata, or contributor tools need a change. > - **CLI:** Automate only deterministic checks; expose dry-run output and clear failure states. > - **Hosting:** Translate operational claims into access controls, logs, backups, and tested recovery. > - **Tide:** Add an automated check only when it is deterministic and low-noise. > - **Openverse:** Use openly licensed supporting media and preserve attribution and descriptions. > - **Themes:** Test the result in both classic and block themes when presentation is involved. > - **Plugins:** PDF generators should preserve source semantics and disclose which checks remain manual. > ### The WPCC > - Set an enterprise baseline for PDFs attached to WordPress sites, including ownership, testing, and replacement timelines. > ### FAIR > - Require federated documents to expose language, structure, licensing, and accessible alternate formats. > ## 🧪 Hypotheses > - HTML-first publication will reduce remediation hours and access defects compared with PDF-first publication. > - A source-document checklist will prevent more PDF defects than post-export repair alone. > - Automated checke Amber: Welcome to WordPress Accessibility Meetup: From Inaccessible to Inclusive: A practical PDF Remediation Demo with Samantha Merrett, Senior Accessibility Specialist at the Ministry of Justice in the UK. A few announcements. If you haven't been before, we have a Facebook group that you can use to connect between Meetups. You can find that if you go to facebook.com/groups/wordpress.accessibility. You can find upcoming events and past recordings in one place if you go to equalizedigital.com/meetup. Everyone always asks, "Is this being recorded?" And the answer is yes, it is being recorded. We are doing an experiment, and we are going to do the captions for this video in-house instead of sending them out to a captioner. Our goal is to get the time down and have this recording available for you in a day or two instead of two weeks, like they typically are, so watch for that. And the best way to get notified when the recording is available is to join our email list. We send out news, event announcements, and you can get those if you go to equalizedigital.com/focus-state. You can also tune into our podcast, accessibilitycraft.com. If you prefer to listen to recaps, we do put those out, and you can find that in most podcast players. If you have any suggestions for the meetup or you need any additional accommodations to make the meetup work for you, you can contact us at [email protected]. If you're new here, I realize I did not introduce myself. I am Amber Hinds. I am the CEO of Equalize Digital, and we are the organizer of the WordPress Accessibility Meetup. We are a mission-driven organization and a corporate member of the IAAP, focused on WordPress accessibility. We make a WordPress plugin called Accessibility Checker that helps you find and fix problems on your website. We also have online courses for NVDA and VoiceOver screen reader testing, as well as selling accessibility, and we do accessibility audits, remediation, and consulting. You can learn more about us at equalizedigital.com. I wanna shout out our sponsor for live captioning today, and that is 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 that their pros can spend less time on monotonous maintenance and more time building their businesses. You can learn more about GoDaddy if you go to godaddy.com. I always ask if you are willing, on whatever social media platform you are on, to give them a quick shout-out or go comment on their page and say "Thank you for supporting the cost of captioning at WordPress Accessibility Meetup." That helps to encourage them to continue covering this and sponsoring it so we can make these meetups accessible to everyone. Mark your calendars for some upcoming events. The next two events will be in August. The first one is Creating a Digital Accessibility Program in Higher Education with Jesse Loesberg, who works at Berkeley University in the United States. He is going to talk about what their whole process was for making the university accessible after they got in trouble for not being accessible on the web. So it should be very interesting. That will be on Thursday, August 6th at 10:00 AM Central. And then on Tuesday, August 18th, in the same time slot, we will have Tanveer Khan presenting Accessibility Testing: What Automated Tools Will Never Catch. I am very excited to introduce today's speaker, Samantha Merrett. Samantha has spoken for us previously and did a phenomenal job, and everyone asked, "Can she come back and talk more about PDF accessibility?" And we are just so pleased to have her back. Samantha is a Senior Accessibility Specialist at the Ministry of Justice, where she leads strategic initiatives to embed accessibility across digital services. With over 7 years of experience championing accessible documents and inclusive design, Samantha has developed cross-government training programs, created hands-on learning spaces, like the MoJ Accessibility Bar, and co-organizes the Document Accessibility Community of Practice, a network spanning 65+ public sector organizations. So I am so excited to welcome her today. I'm gonna stop sharing and let Samantha take over. We will be using the Q&A panel, and I will come back at the end to pass along any questions for her. So if you have questions, because we do have a lot of people here today, it is helpful for me if you could please put those in the Q&A section. So thanks so much, Samantha. I'll let you take it away. Samantha: Thank you very much. Hello, everybody. Welcome wherever you are in the world, whether it's morning or afternoon, a good day to you. So thank you for joining today. As Amber said, we are gonna be talking about PDF accessibility today. Last time I came, I just talked about documents, more generally, but there was obviously a real feeling in the room, the virtual room, that PDFs were a problem that people were looking to solve. So I said I would come back and talk about how we can help try and solve that problem maybe today. So I'm gonna talk about sort of a problem document, which in this case is a PDF, and we're gonna try and work to make it a usable PDF. And I'm gonna walk you through some of the things that you should be doing to try and make sure that your PDFs are as accessible as they can be. I don't think I need to add too much more 'cause Amber did a really lovely introduction for me. But, just as a visual description, for everybody on the call, I'm a woman in her 20s. I'm wearing a pair of glasses. I've got blonde hair, which is in a bun today. There's a picture on the slide of me hugging my beautiful pet dog, Bella. She's a big dog. It's a big cuddle. She's a blue Staffordshire bull terrier, and she's got her paws on my shoulders. You will learn throughout this presentation that I'm a big fan of dogs, and I do litter them out throughout the presentation just to try and keep it as fun as possible because we are talking about PDF accessibility, which at times can feel a little deep. But we will try and keep it engaging and, kind of work with you guys to understand some of these concepts. I will visually describe everything I have on my slides. I've included some screenshots to talk through how we do things and where you can find certain tools, but I will absolutely describe where those things are and tell you what menus, et cetera, they live in, so that everybody can understand where we're at. I'm gonna cover as much as I can in the time we have, but I also don't want to overwhelm everybody and just basically talk at you for, say, 50 minutes and you go away thinking, "That was all great, but I don't even know where to start." So we're gonna break it down into different sections. We're gonna talk about why PDFs are maybe misunderstood to start with. Then I'm gonna talk about Should it even be a PDF, and maybe consider that question before we even delve into remediation. And then we will dive straight in and have a look at some of the accessibility fixes. We'll talk about what makes up a PDF, how do you tag it properly, what are those tags? How do you remediate some of those issues that sometimes pop up and people say, "I don't know. I don't know what that means. What's gone wrong?" And hopefully we can dig into that a little bit. So hopefully you will leave the session today thinking, "Okay, I've got a few top tips I can take away," and look at some of my PDF documents maybe and see if you can make some changes to improve them. Before we start, let's just define when we're saying PDF over and over again, what is that and how do we often use it? So on this slide I've got my first dog picture. It's of a brindle-looking dog looking at the camera with one ear poking up as if he's looking for an answer to the question. So quite simply, a PDF document stands for Portable Document Format. It was a universal, or it is a universal digital file format developed in about 1993. It displays documents in a very fixed layout. So the purpose of it is that documents look the same across any operating system and any device, and that was kind of why they were created in the first place, to ensure there was that consistency, and they were kind of locked in time to ensure they couldn't be changed regardless of what, how that user might be kind of, looking or understanding that information. I think from my experience working in the UK government, there has been a lot of misunderstandings and some kind of myths, that have developed over time. PDFs very much have been the kind of normal style of creating documentation in government. Everything is a PDF document. Every policy we create, every letter we send out, everything we publish on our websites tends to be, or at least in the last… I think we've seen a shift in the last five years, but before that it was always PDFs as the default. And then some of the things when I talk to people about, "Oh, we could make this PDF accessible," people often say, "Oh, no. PDFs, you don't understand. They can't be accessible. PDFs never work with screen readers, so there's no point even trying. They just don't work." And, "Oh, don't worry. It passes the checker, so it's accessible. So I've done kind of what I need to do." And then people say, "Oh, I've converted to… I've converted it from Word or a Word document, so it's automatically accessible, isn't it? 'Cause it just carries over all the things I've done in Word to make it accessible." Some of these are partially true. For example, if you are converting a Word document to a PDF and you have put things like alternative text in your Word document and you've put your headings in right, some of that will carry over when you convert it to a PDF. That much is true. But it doesn't make your PDF document automatically accessible and ready to publish. I wish that was true. It would make, I'm sure, some editors' lives a lot easier. But unfortunately there's always some manual checking you need to do when you do that conversion process to make sure it works correctly. PDFs can be accessible. Hopefully, I'm gonna prove that to you today, and PDFs can work with screen readers, of course, if they are accessible. And as with all automated checkers, we cannot rely on them to give us a comprehensive compliance check when it comes to accessibility. So the Acrobat, for example, in Adobe Acrobat, it's a great checker. Checks for a lot of things. It can really flag some important things. But it's not gonna tell you everything, so again, you need to do some manual checking and some manual remediation to make sure you're ticking all the boxes. Before I start fixing PDFs, one of the questions I ask my editors or people that have provided the information to me is, "Should this even be a PDF?" And I tend to walk them through quite a simple decision tree. So I ask them: Does it need to be printed? Is the layout that you've got there, is that preservation critical? Do you have to have it in that format, or it might be breaking some kind of legislation, for example? Have you considered any other format? So could this be an HTML document? Could you put it… Could you leave it in the original file format and not convert it to PDF? And would a Word document or similar meet the same need? I like to try and understand who I'm talking to in terms of the users we're creating this for and how they're gonna use that, because that will determine whether or not we think we should be using a PDF document. So we always try and break it down. The simple reason I ask these questions is because PDF accessibility is quite complex. I'm not gonna sugarcoat it and say it isn't. There's quite a lot to a PDF document. It doesn't mean that it's impossible to do, but before we kind of go down that road and spend a lot of time doing it, I always just like to make sure we're doing it for the right reasons. Could we be spending that time making a Word document accessible that will still meet the same need for the users? So often with teams, I say actually the most accessible PDF is often no PDF at all. But, as with lots of things, most of the time the answer is yes, we do need a PDF. We need it tomorrow. What can we do? Within government, we tend to use Adobe Acrobat Pro to make our PDFs accessible. So just to be aware for everybody, that's a licensed version of that software. And if you don't have a license for that particular piece of software, then the accessibility tools and some of the other tools I'm gonna talk about today are not available in it. That does not mean that Adobe Acrobat is the only thing you can use. That's what we tend to use in UK government for doing ours. It's what a lot of my guidance and screenshots will be based on today, but it doesn't necessarily mean you have to use that. There are other softwares available, things that I haven't personally used, so I can't give you any recommendations on what's… on which one can do what, but I am aware there are others out there. Things like CommonLook PDF, Equidox, axesPDF, PAVE, PDF Accessibility Viewer are other things I'm aware that exist that you can, again, they're kind of free web-based tools, some of them that you can do some accessibility work in. As I say, I'm talking today very much from using what's available within Adobe Acrobat Pro, but I do know there are sort of similar tools, and they do similar things in other versions of software as well. I only bring this up because I often work with colleagues who are like, "I can't find the accessibility toolbar in my software," and it's because they're in Adobe Acrobat Reader, and it just doesn't have that functionality. So you do need the Pro version to do some of this stuff. Whenever I'm working with someone and we know we're gonna be working on an accessible document, we always start with the source document, which I'm sure anybody who's worked in accessibility before or knows anything about this space will have probably heard this in various other contexts before. The source document is always the best place to start. On the slide, there's an image of sort of a terrier-looking dog wearing a trench coat with leather gloves and holding a magnifying glass. I like looking quite deeply at my source document before I get to the PDF stage. It's much easier to fix accessibility issues at that kind of, you could say source document level or maybe a template level if you're working through, like, corporate templates, for example. Most applications provide options for making your source document accessible, and the more accessibility work you can do there the better. For every accessibility issue that remains in your source document, it's likely to be multiplied when you convert it to PDF. For example, if you have no headings in your Word document, it's likely to bring all the other headings out of order when you convert it to PDF. It might not detect them properly, and then you might end up with more headings out of order than you originally planned for. It's also important that you follow the correct procedure when you're converting your document to a PDF. I'm not gonna advise today that you convert PowerPoint presentations to PDFs. I personally don't like that. I find it very difficult to make that final output accessible. I always encourage people, if you're gonna convert to PDF, most of the time make sure it's from a Word document or some kind of word processing document. It's the most, it's the most… It's the easiest way to make a PDF document. Any other kind of document type can get a little bit messy when it comes to making it accessible. And the good thing is, a lot of the word processing software has all the features you need to make sure that source document is accessible as it can be. And I'm sure you've been to webinars before where they've told you about adding alternative text, making sure your link text is good, adding in proper heading orders. All of those things are absolutely brilliant when it comes to making sure your PDF is as accessible as it can be. When you are converting to PDF, make sure you do not click the print to PDF option. On this slide, there's a picture of a small dog looking shocked, holding its paws up to its ears, and the words, "Oh no," written at the bottom. The amount of times I will work with colleagues who, with good, with all good intentions of like, "Oh, I've got my PDF ready." I open it, and there are no accessibility tools or tagging in there whatsoever. They've simply printed it to PDF, which means everything they've done in their Word document, for example, is not carried over to the PDF version. So if you're gonna do anything, always make sure you do a File and a Save As. Make sure you're saving it as a PDF. Make sure you're turning on the accessibility features and tagging when you're in your saving options, which you'll see when you're saving it from any word processing software, so that you're carrying over all that hard work that you spent all that time doing in your Word document into your PDF. Also helps you when you get to PDF, you're already halfway there. So just remember that when you're converting from your source document. So what actually makes a PDF accessible? Lots of things make a PDF accessible, but a PDF should have searchable text. I should be able to scan it like I could do any other document and find things in that PDF. Fonts should have been used. Accessible fonts should be used so that I can extract characters from it, and that it can be read and understood by technology. Probably quite important, most important in this list arguably, is structure and tags. PDFs should have tags so that it can be read and understood by assistive technology. It should have a really good, clear reading order, so the reading order should be nice and clear and logical. Of course, that's down to you as an editor to determine what that logic order looks like, but it definitely should have good reading order. And as with all accessible content, regardless of where you're doing it, all image content of course should have alternative text. Just like in any other application you're working in. Starting off, before we even open up our PDF and start worrying about accessibility, let's set up our workspace to make sure that we're ready to do this work. In order to do some accessibility work in Acrobat, you need to have sort of certain sections of the interface visible to you or available to use. Now, if you've never used Acrobat before or you've never used the Accessibility Tools before, it's highly likely they're not gonna be there by default, so you're gonna have to go and find them and add them to your Toolbar. The first thing I would say you do is you add the Accessibility Tools. Normally, they sit on the right-hand side of your screen if you're looking at it, or they're in the toolbar on the… That's normally at, on the right-hand side of your screen. So there's two ways you can find it, either from Tools, which will be at the top of the screen in the Menu Bar, or More Tools in the Tools Pane. Where ever it is you decide to find it, it's normally, if you're looking at it visually, a sort of purple icon, kind of the established accessibility icon. A purple, a person inside a purple circle. That's the Accessibility Tools. If you find that, you can add it to your Toolbar. There's a quick Add button on the bottom. The screenshot on the slide, I'm in Tools. I've found Accessibility, and I just click Add. Once I've added it to my Tools, it will be there forevermore. I don't have to do that every single time I open Acrobat, but the first time I do it and I wanna add it to my Toolbar, it's quite important I make sure I can easily access it rather than having to always go to the Tools Menu every single time to go and find it. Accessibility is, of course, very important. But there are also other things you might want to add to your Accessibility Toolbar to make sure all the options are available. Normally, by default, things like Bookmarking, Tags probably are gonna be there, and like Attachments and things like that. But there are certain sort of, Tools within accessibility that might not be there by default. I would say some of the more important ones to make sure you've added are the Content option, the Order option, and of course the Tags Pane. If you open up your Accessibility Tools and any of those are not there, you can choose your Navigation Pane and then go to View, Show/Hide, and in your Navigation Pane there'll be a list of all the things you can add, and you can just add or remove whatever it is you want to add and remove. As I say, for me, Content, Order, and Tags would be my top three that I'd put in there straight away. Bookmarks are also very helpful to have in there. Everything else, I would say you can leave out for now and just keep your Pane nice and simple if you'd like to. But again, it's just to show that some of these Navigation Panes are set up in different ways in different people's Adobe Acrobats. So if you wanna set it up for your own needs, feel free, but you do it view… via the View, Show/Hide, and then choose your options in the Navigation Pane. And once you set up your Acrobat, you're kind of ready to get to work and start doing some remediation fixes. There are kind of two things to kind of do first off the bat before you even start with the contents of the document itself. And again, these two are no different to any other document type, but people often forget this when they're doing it in PDF format. When accessing a document, the first thing people come across is the File Name. It's really important that we make the File Name unique and descriptive because it helps people understand what that document is about and whether they're opening maybe the one that they thought they were opening if they're opening it from a web page, for example. As I say, this is no different if you're doing it in Word or PowerPoint, we would give the same advice. Normally, assistive tech will read the File Name when the document is accessed. We tend to keep the File Name and the Document Title quite similar. They're normally related, but not exactly the same. But it depends on the context. If the file name and the title are the same, sometimes it might lead to a little bit of confusion, but it's not the end of the world. When you are adding a title at your File Name, you change the title using the document Properties Menu. You'd normally find it under File. You'll see Document Properties, and once the dialog box opens up, the first box on the Description tab should say Title, and you can type into that box whatever it is you think is suitable. You can also add an Author. Now, that's up to you as the editor whether you think that's helpful. We at the Ministry of Justice, for example, would normally just put in Ministry of Justice.We don't put people's names in, and we don't put specific team names in because for most people in the general public, it doesn't mean anything to them anyway. They'd just like to know the document's owned by the Ministry of Justice. In a similar thing, Document Title is also very important. So under Initial View, the Initial View tab within your Document Properties, it will show the Document Title. This might be different to the File Name, so just bear that in mind. The purpose of this technique is to show how a Descriptive Title for a PDF document can be sort of specified for assistive technology. Document titles identify normally the current location without users having to kind of actually read the page content itself. Again, just make sure that they match or at least they're similar so that people know they're opening the right document in the right space. That's the simple bit, right? Setting your File Name, making sure your Document Title are correct. The next thing about PDF documents are Tags. If you're a web developer or you've already kind of done any of that work in the past, you might already be familiar with tags in some context, 'cause they're kind of the basis. They're similar to the basis for HTML code. A tag basically tells, in HTML language, the browser or a screen reader what type of content something is. Most text is tagged as a paragraph, so that has a P tag. The main heading on a page is tagged with a H1, a heading one tag, and then subheadings could be H2 and so on. So very similar to how you might put headings into a Word document. The tagging system is very similar. In a PDF, tags perform a very similar role, except that they don't actually affect the content on the page. On a web page, if tagged content is missing, it will not display. whereas in a PDF it will still be there, but screen readers, for example, might miss that content or not be able to access it. Actually, tags are pretty critical to PDF accessibility, 'cause anything without a tag will get missed completely by assistive technology users. So it's really important that things are tagged, and of course, it's important they're tagged correctly. The first thing you need to do before you can create any tags is to create what they call a Tags Root. Now, you'll notice a theme with kind of trees, because they often call this the Tag Tree. So your tag tree needs a tag root to grow, right? I didn't choose that language. That's been chosen for me, but it kind of makes sense. I can see the logic. I've got three small screenshots on this slide. The first shows the Tags Pane with a message that says, "No Tags available." That means I need to create a Tags Root, because at the moment I've got no Tags and I've got no Tags Root to grow any Tags from. The second screenshot shows where you can do this. In the Tags Pane, you select the Options, and there's a Dropdown, and then you select Create Tags Root. The third screenshot then shows the outcome of that when there are no tags available, but I now have a Tags Root at the top. So I've started kind of my tree. I've got my basis where all my Tags are gonna grow from later on. Now, if you are starting from scratch with the mediation, you might have to do this. However, if you have converted from any other source file, it is more than likely this will already be there for you. This is just for people who open up a PDF and their Tags Pane is completely blank. Just remember, before you start adding Tags in and, kind of, selecting text, you need to make sure you've got a Tags Root to start you off. Now, I've said there are many different types of Tag. These are kind of the main ones. Paragraph, as I've said, the P tag, that's just for normal text. Your H1 and your H2, they're your heading level ones and twos. We're quite familiar with those with kind of heading orders in other context. Your Figure Tag, that's obviously for images. Your L Tag is for lists, so an ordered or unordered list. Your LI Tag is your list item, so that has to be embedded within an L Tag. Again, we will talk about that relationship in a second. And you also have a Link Tag, which is for hyperlinks, and they are normally embedded within a P Tag because normally your link text is in a sentence, for example. So your Link Tag kind of goes in with that P Tag. There are other Tags, of course. You've got Table Tags. We're gonna talk about those separately because there's a bit of a hierarchy with those and how you have to order them. So we'll talk about that in the next couple of slides. But, hopefully, you can kind of see how everything in a PDF gets allocated some kind of Tag depending on what it is. Now, you might be thinking this all sounds like a lot of work at the moment, and it's all a bit complex. There are features that allow you to do things like Auto-tagging. If you do, in Adobe for example, Acrobat kind of like looks at your layout, looks at your structure, looks at your content, and then determines whether it or not it can be read. And then it will auto-tag things depending on what it thinks you've got in your document. There, just to sort of flag, it will not produce an instantly accessible PDF on its own. It's a kind of one and done solution. Sometimes I might auto-tag to get me halfway there, and then I'll go in and manually remediate everything else. Sometimes I auto-tag and it basically, if it hasn't been designed well in the first place, it doesn't Tag things correctly, and actually it's more work to try and unpick the auto-tagging than it is just to start from fresh. It depends on the size of your document, how well it was designed in the first place, and kind of how good a job auto-tagging does. But it's important to know that you can do that, but don't rely on it and think, "Oh, I'll just auto-tag and then I'm done." Because unfortunately, yeah, it is prone to errors and it's not particularly reliable in that sense. But, if you are very new and you're kind of starting off blank with no Tags, sometimes auto-tagging will get you kind of halfway there, which is helpful. That's your basics. Let's have a look at some issues together. We've talked about Heading Tags. Headings are very important for screen readers. I'm sure anyone who's done any accessibility webinars before has probably heard that lots and lots of times. The Heading text, of course, needs to be meaningful, and hopefully the document's been designed in a way that works. We're not worried about the content really at this point. We're just worried about how it's been tagged. The levels of Heading are quite important. Of course, Headings and Adobe Acrobat use a word called Nesting, and they say Headings should be nested correctly. And that basically is something we're probably familiar with in the accessibility space, in that we shouldn't be skipping Heading Levels. A document should only really have one Heading Level One, or one H1 Tag in this case, and that should be your main Title. And then, obviously your subheading should follow on from that. If you're checking accessibility and you run the Accessibility Checker, and it says Nested Headings Error, 9 times out of 10 that means it thinks there's an irregular order to those Headings. Maybe it thinks you've skipped one, or that you've put a Heading Four before a Heading Three, which doesn't make sense in the order. Just go through your Heading Tags and make sure they are in a logical order and that they make sense. That's the most likely reason for that error, and the simple way to fix it is to make sure they're in a logical order. I would say Heading Tags are one of the things that we get right most of the time because we're familiar doing it in other contexts, and doing it in a PDF is no different really. Of course, linking to that is logical reading order, and as we've said, that's really important in a PDF. Logical reading order in a PDF refers to kind of the sequence in which the content is read and interpreted by assistive technology. Ensuring that your reading order is correct is essential for PDF accessibility, and of course, it's logical reading order. That's very much determined by you and by the content in that document. You can decide what order that needs to be in. Remeber, anything that doesn't have a Tag will be missed, but the good thing about your reading order tree is that you can drag and drop content as you wish. So you can also use your keyboard to move things around if that's how you prefer to navigate. It's very flexible. Even if you've… even if it's been designed in a particular way, you can amend the reading order to read it in a completely different way if that's what's needed. I always say to people, it's part of the Accessibility Check, but it's a manual check because Adobe can't determine what logical is in that circumstance, as it can't in any other context either. It's up to you to ensure that you've done that correctly. We will look at reading order, and what that means a little bit later on. Linked to reading order, but slightly separate are something called Bookmarks. We might all be familiar with Bookmarks in a physical reading book, for example, we put it in to know where we've stopped and where we wanna start again next time. Bookmarks in a PDF document are sort of similar, but they're more about allowing people to navigate to specific sections of your document quite easily. I always like to think of Bookmarks as my Table of Contents really, or as a navigation menu that helps users or readers quickly jump to areas of interest, so they don't have to scroll or search manually. They can just select the Heading that works for them and read that section. I would say they're especially useful in long, complex PDF documents, but they are great for just improving overall accessibility and user experience. For users who are using screen readers, Bookmarks can help them navigate quite quickly. They can also kind of get a bit of an overview of the document as well by using Bookmarks. In Adobe Acrobat Pro you can create Bookmarks by there is a whole Bookmark Panel, which is normally somewhere near the top of your Tools bar. If you select the Bookmark option, you can see what Bookmarks are in your document, so it will list them out in a list. You can then navigate through that list and kind of understand what Bookmarks have been added. If there are any missing or any you don't agree with, you can just select a Bookmark and delete it. There is a bin icon at the top of the Bookmarks Panel, so you can just delete that if you want to. If you want to add any Bookmarks, I would say the best way… There's two ways you can do it. The first way is you can navigate to the page you want to add the Bookmark, and once you've got that, that page on your screen, you can go to your Bookmarks Panel and just say Add Bookmark, and then it will add that Bookmark to the Panel for you. It will add it directly underneath, so it will just add it as your kind of the latest one at the bottom of the list. You can then drag and drop these Bookmarks in any order that you want, so you can add them all and then order them later. That's absolutely fine. The other way you can add a Bookmark is, say for example, if it was a Heading that you wanted to Bookmark, you could select the text like you were if you were changing the font size or color in Word for example, and then click Add Bookmark. And again, it will add it to the bottom of the list for you. So Bookmarks can be linked to specific pages, they can be linked to specific Headings, and they can be even linked to specific positions on a page. I would be a little bit wary about the position on a page because sometimes the orientation then for the user can get a little bit confusing. Linking them to specific pages and/or headings is probably the best way to use a Bookmark, but it's important to be aware that there are other ways you can also use Bookmarks just to flag. But again, they- they're all added in exactly the same way. If you're gonna add it to Bookmark to a specific passage of text, you just select the text and then Add a Bookmark in your Bookmarks Panel. Bookmarks are really important for accessibility though, so make sure they're added in. List Tags. I said I'd come back to List. A List is simply a container with items inside it. And each item has two parts, the bullet and the text. And it is just as simple as that, but it always sounds and looks from a tagging perspective so much more complex than it needs to be. So just, I always think of it as a box, okay. My box is my L Tag, it's my list. That's the outside, that's where I've got everything inside. And then inside my box is a slightly smaller box, and that's called my list item. And then inside that box, a bit like Russian dolls I suppose, are two little boxes. One says LBL, which stands for label, and one says LBody, which stands for list body, which is my text. Most lists, if they've been structured correctly, will have a bullet of some kind, whatever shape or icon that might be, and text that accompanies it. That's the standard way to structure a list. So you need to add a Tag for the bullet and a Tag for the text for that bullet. Each list item will have two items. It will have the label and the actual text of that bullet. Lists should be structured in a way where at the top you have your L, that's your list Tag. That's kind of, in Adobe language they call it parent and child. So your parent is your list, and then within that they have a list, their oldest child, which is their list item, and then two younger children, their label and their LBody. I don't mind whichever way helps you remember this, whether it's the box analogy or the parent and child relationship. It doesn't matter as long as you understand the structure of a list. You will see a pattern where a lot of tagging is kind of tags within tags to kind of build up a tree. That's kind of how they work, to give it proper structure. And once you've kind of understood how each item is structured, you kind of get to grips with it, because it's very repetitive. But, it's getting your sort of head around what each one means to begin with that can be a little bit tricky. But that is quite simply how you, kind of structure a list in a PDF document. I suppose in a more simple way is alt text for Images and Figures. Again, of course, you need to make sure you've got alternative text on Figures in a PDF. So every image will need a Figure Tag, and every Figure Tag should have alternative text. There are various ways to add that. If your Image has not been tagged already, you will need to go and make sure it has got a Tag of course. Once you've tagged your Image, you can select Properties, and then under the Tag tab there is an Alternative Text field, and you would type in there whatever it is you would normally type in there as if you were doing it in, say, a Word document or something similar. You can also fix it directly via the Accessibility Checker Tool in Adobe, so it will flag there's obviously no alternative text, and it will… if you click on it, you can then select and type in your alternative text in a very similar way. I would say don't let it get to that stage, and just check every Figure Tag has some kind of Alternative Text by going into the Properties of that Tag and looking at the alternative Text Field. There are Artifact Tags. Artifact content is ignored. So marking elements of the document as Artifacts means that those elements will be completely ignored by screen readers. The purpose of doing that, is to exclude kind of like non-essential or decorative content that like doesn't contribute to the overall meaning or structure of the document. I tend to use that very sparingly because I don't really think much of my document is decorative at PDF stage. Most of it's in there for a reason and I want it tagged. But it's important to know that does exist as a concept if you don't want to Tag anything and you don't want to leave it empty. Artifacting content can help improve kind of like reading experience, of course, because it reduces like the amount of cognitive load in there. It also ensures that only like relevant and meaningful content is announced. But it's, yeah, just I would say artifact- using artifacts and kind of tagging is, not always the best thing to do because you want to make sure that most things have been tagged and will be communicated to all users. I always make sure if I've got any like empty P Tags. So you can open up a Tag and see what's inside of it by literally by selecting in your Tags tree. If there is no content in there, I just get rid of the empty ones. They're probably just spaces in there that have been converted across that you don't need. Sometimes you can artifact like Headers and Footers if they're there, or page numbers if you don't want those included. They're good examples of where marking things as an Artifact is helpful. But again, that's probably one of the only things you can, you would… only times you might use artifacting in a way that I think works well. Okay. Table Tags are a little bit more complicated, but they really do… For anyone who is familiar with HTML code, there's a real strong resemblance here to HTML code. It's very, similar to kind of the List Tag structure, but there are four different Tags for Tables, whereas there were, actually, there's four different tags for lists, as well. But basically, if we're gonna use the box analogy again, our table, we've got a big box, and that's our Table Box. All other Tags must be nested within our Tables. They all have to sit inside our Table Box. That's our top one, so that's our Table Tag. Inside that are our TR, or our Table Row Tags. Each row of my Table needs a TR Tag, which is a table Row Tag. And then inside that one, there are two different Tags I can use. I can use TH or TD. TH is Table Header, TD is Table Data. So it will depend on what's most appropriate. If I'm thinking of a normal table that you might have, so the top row of your table is your header, and then after that are all just data rows, one after the other. A very simple structure for that might be Table Tag at the top, Table Row underneath, and then say it's got three columns, I would have three different Table Header Tags that each respond to each one of those columns. My next row down, maybe the first column is also a Table Header potentially, so I can mark that as a TH, and then the following columns are then marked as TDs because they're just Table Data. They're not header cells. And then it is basically, is… Depending on how many rows you've got, you repeat that same pattern over and over again. Table Data cells are normally just the main content in your table, and that's kind of the way to differentiate the two. But again, if you run an Accessibility Check and you get any errors, it might be that you've not put your Table Row Tags in there underneath your table. It might be that you've got too many Table Header cells for kind of what would be logical. Normally, you might have your top Table Row as your Header, and then, as we say, one for each column maybe under the first column of your table. But after that, everything else should be marked as a Table Data cell. It sounds more complex potentially than it is. But if you were to look at a, or use a normal table and replace on or right next to it what you think each Tag would be, you can kind of see how this is a kind of a normal structured table. It just makes it sound more complex when you've got kind of the Tagging and the Symbols next to each one. But if you follow a simple structure, you can make sure a Table is accessible. This is why we also say to people not to merge cells, split cells, create like an irregular structure in a table, because then tagging it becomes a bit of a nightmare, and it's very difficult to tag that in an accessible way. So that's why we like tables that have a nice, simple, easy structure to follow because tagging it then becomes a lot easier. One of the final things I'll share is Tagging Links. So multi-line links often present, if you have got any multi-line links, often present a bit of a unique challenge. If you have got any multi-line links, I would say it can be quite beneficial to delete any tagging that's already there, and basically just start again. And make sure you just tag the entire link all together. 'Cause sometimes if you've got multi-line links, so what I mean by that is a link that spans across multiple lines in your document, maybe it's quite long. Hopefully it's not, 'cause that's not particularly accessible, but it could be. I would normally just select the entire link and put it under one tag rather than having it broken down, because it's a bit disjointed otherwise. The way you Tag a link is you would select the text that you want to Tag. You would right select or go into your Options Menu, and there will be a Create Link option somewhere near the bottom of that Menu. And then you make sure you understand where that link is. You might put your URL in, or you'll tell the PDF software where that link's gonna take somebody, and then it will automatically Tag that link for you Quite an important component of accessible Links in PDFs is the additional alternate text. It's not essential, but it can be helpful. It can provide additional context for the Link. Of course, we're aware of Alternate Text for Images and in other contexts, but we've probably not heard of it for Links before. But screen readers often read visible link text, but replacing the screen text with something meaningful and alternative text can make it a little bit more accessible really. It's not essential, but it can be helpful. When the Link Tag has a blank alt entry, screen readers will ignore the value of any visible text objects, and use the alt entry. So it's important to make sure that you put something in that box, so that there's some context there for screen reader users. Again, that's in the Properties. So when you're adding… When you've added your Link Tag already and you've got that all set up, if you select your Link Tag and go to the Properties, you'll see the Alt Text box option there. Again, it's a slight difference with PDF software that you wouldn't do in other, format types when it comes to documents. Now we're nearing kind of the end, so I'll end with some tips about checking PDF accessibility and how you can kind of do that in a way that works. Inspect the Tags Tree. On the slide I've got a small dog wearing kind of round glasses and a hoodie looking as if they're typing on a laptop. Normally, what I do when I am checking a PDF accessibility, I'll open up my Tags Pane, and I basically what I call walk the Tag Tree. I often use a keyboard, and I use my Arrow Keys, and I go from the top of the document, and I simply press the Down Arrow and go through my Tags Pane. And what I'm really doing there is making sure the structure's correct. I'm checking that everything has a Tag. The Tag it's been assigned is correct for the content in the document, and that it's in an order that makes sense and I'm not jumping around from place to place around my document. If those three things are there, then I'm happy that at least my tagging looks to be relatively accurate and logical for what I need it to be. That's the first thing I would do. Obviously, I would use the Accessibility Checker. I know at the start I kind of gave it a little bit of a bad name, and that's just because I don't like it being used as the one-stop check and that's it. I like to say that it's one step in kind of remediating and checking PDF accessibility. Of course, it has its place, 100%. One thing to say is that when you select running an Accessibility Check and it says Full Check, there's normally a checkbox that comes up and it says checking, and then it'll give you a number of 32 issues. Just make sure you're checking 32 of 32. It basically means you're checking everything in the document. Sometimes like five of 32 will be there, and that means you're only checking five of the full 32 it can do, and that's just a waste of time. You might as well check absolutely everything. What I do like about the checker is that it will often then bring up your issues, and then it will offer you the opportunity to basically select the issue directly and go to that point in the document to fix it. So you can pretty much do it, go through the fixes there and then, which is quite handy. Especially with things like adding alternative text, it's really handy for doing that. Again, I would do that when it comes to running an Accessibility Checker. It will, I think, look for, like, Proper Semantic Structure. It will look for Alternative Text for your Figures. It will look for Metadata, so it will look for your Document Title and your File Name. And it will also look to make sure that the Language selection is correct, as well as, like, other accessibility checkpoints. So it definitely checks quite a bit, but it will never replace kind of doing a manual check of the Tags Tree as well. I did touch on this earlier, but like the Nested Elements, I think this is the one that I hear the most from colleagues who are kind of trying to work in this space and do some PDF work. They just keep saying, "It just says nested, but I don't know what that means." Pretty much that nested word gets thrown at pretty much any error in a PDF document. Most of the time is the Tagging structure's slightly off, which is why I always start with a manual walk of the Tags Tree, 'cause I can pick up a lot just from having a manual walk through it. But Nested often means that the structure of the Tags is maybe just slightly out of line. So if you get that error under whatever Heading, so this one, the screenshot on this slide is for an Alternative Text fail, but it could be for Headings, it could be for anything. There will be underneath where the error comes up, it will say how many there are. In this example it says element one, so luckily I've only got one issue. But it could say element 25. There could be quite a few on the list. So I click on the first one, I'll select the first one in the list. Once I've right selected it, I'll see an option that says Show in Tags Pane. I select that option, then it will take me to where that is in the Tags Tree. So it'll take me directly there so I haven't got to find it. It will automatically show me where that is and it will highlight it for me. In this instance, there is a Figure Tag within another Figure Tag, which that's not an accessible best practice. I can't have two Figure Tags embedded within one another, that doesn't work. Quite simply, I just have to move that Figure Tag from sitting outside that so it just sits directly underneath it rather than being nested underneath it. So I move it out. Actually, I also realize that Tag is empty. It has no information in it, so I'm just gonna delete it. Once I've deleted that Tag and if I was to rerun the check, that error should disappear. It was basically just telling me, "That's not normal. You don't normally nest one Figure Tag inside another. There's a problem here. Can you go and fix it?" I've done that, and it's checked. Just double check. If you're getting nested problems, check the logical order 'cause there might be something out there. We've already talked a little bit about the issues with the checker. I've got a brown dog here pulling a bit of a silly face as if he's a bit disappointed. But there are obviously limitations with it. as with all checkers, it can't check accuracy of alt text, so remember that. And it will overlook things like hyperlink issues as well. But I won't drone on. We know that we need to do our own checks with it. If you do wanna go one step further, I unfortunately can't do this 'cause I'm on a Mac, an Apple Mac, laptop. But if you are on Windows, there is a pack, it's called PDF Accessibility Checker. It's free to download for Windows users. You can test your PDF through that. I actually prefer to do that if I have the opportunity because it's just like another automated check that picks up a few more issues, so I like to run PAC for my PDFs if I can. It's an option for anyone who can do that. Some top tips, just take it from someone who's done many hours of PDF remediation over time. Acrobat is prone to crashing, as I'm sure lots of other softwares are, so just save your work frequently. There's also a dog on this slide with a headset and microphone looking like they're working from home, which is quite funny. Acrobat's undo function is quite limited, so save a copy of your work quite frequently. Sometimes when you're deep into kind of remediation, you're moving things around, yeah, you can't undo things that easily, so just make sure you save. And if your document has any kind of like visual accessibility errors, by that I mean like color contrast problems or like graphs and images that have not been pulled through correctly, you can't amend those in Acrobat, so go back and get the right in the original before you start any PDF work. Take it from someone who's had to do lots of things again because they've not saved or she can't undo what she's done. Final things for you, if you don't take anything else away from today, check your Reading Order Pane, rerun the Accessibility Checker, and check everything with a screen reader if you can, 'cause of course that's gonna give you the best idea as to how accessible your PDF is. If you are interested in kind of document accessibility and you wanna know more about this, you wanna ask questions, there is a group on LinkedIn, it's called the International Document Accessibility Group. It's an extension of our public sector one in the UK, but it's open to everybody. Doesn't matter who you are, what your job is. If you wanna know more about document accessibility, feel free to join. I can put links in the chat. yeah, there's no, no cost. It's completely free. It's just a place for people to share best practice, very much like we're doing today. Feel free to join that if you're interested. Apologies, there's a lot less time for questions than I had envisaged, but hopefully that information was helpful. But, I will take any questions in the last few minutes. Amber: Yeah, no problem. Thank you so much. This has been a great presentation. I will also note, this is one of the first times that I've heard someone really highlight Bookmarks as being important for accessibility. I'm gonna run through the questions that everyone has, so make sure if you have any, put them in the Q&A, and we'll see how many we can get through in a few minutes. Can we go a couple minutes over, Samantha? Samantha: Of course. Yeah. Amber: Okay. But I was curious, on the Bookmark side, is that required for PDF/UA compliance, or is it just a best practice? And do you recommend them even on, like, a one-page document? Samantha: I wouldn't say for a one-page document they're necessarily required. They're very much a, a nice-to-have. In terms of PDF/UA, that's interesting. So we don't work to PDF/UA, but yes, they are actually a mandatory requirement for PDF/UA. Yeah, you need to add them in wherever you can. Amber: Okay. Samantha: Normally, they'll be pulled through if you have Heading Tags and things, they'll automatically be populated, but it's worth checking they're populated correctly, of course. Amber: Great. Thank you so much. All right. I'm gonna try and go through these. I'm gonna look at things that have upvotes. So if anyone wants me to pay attention to questions in particular, just 'cause we don't have a ton of time, go upvote them if you're able. So we were wondering, can we get a copy of the slides? Samantha: Absolutely. Amber: Would you be able to send that, that we can include with the recap? Samantha: Yep. Amber: Perfect. Okay. So Jennifer wanted just some clarifications. If you make a source doc accessible and then print it to PDF, it won't make the PDF accessible, correct? You still need to remediate the resulting PDF? Samantha: Correct. Amber: Okay. This… Some of these might just be fast, so we'll get through a bunch. Let's see. And I think that answered the same question that Nick had that a few people voted on, which is if you convert a Word Doc to PDF, you still need to go in and make changes and all of that. Samantha: Yeah. Just, look, so don't print PDF, of course. That's a bad thing to do. If you've saved it as a PDF, that's the way to convert it. A lot of it will have carried over. I'm not saying you have to start from scratch. It's not the end of the world. But a lot of people say, "Oh, it's all right. I've converted it from Word, so it's good to go." We can't guarantee that, so you always have to manually check. Amber: Okay. Do you happen to know if someone is creating documents with Pages, do you have any experience with that? Like, how that works? Does that give you an okay or similar setup like using Microsoft Word would? Samantha: Yeah, I think so. I think doing it from programs like that. I've worked in other programs where it's been fine, but kind of the same rule applies in that as long as you've designed a pretty good source doc, whatever that source doc might be, other than a PowerPoint presentation. Yeah, your PDF is pretty good, but always worth checking that it's got Tags applied. Amber: Okay. so I know a few people touched on maybe some other tools in the chat, so I would recommend going there. Denise had said, "What if Adobe Acrobat Pro is too expensive for our council?" Which is hard. Have you ever been in a situation where you've had to, like, justify paying for the license of a tool, or do you have any recommendations for that? Samantha: That's a great question. Yeah, I basically do my research. So I do, like, a mini discovery, and I look at all the tools out there, I look at all that's available, and I look at what I want to do in them and how much work I've got to do, and then I just basically judge on the best tool that's available and put that to my procurement team. We've had Adobe for quite a while now. It's kind of an established thing. But appreciate it is, yeah, it's not a cheap tool. As I said, there are other tools out there, that you can use. Some are free, web-based ones. Other do require, like, a minimal fee that's maybe a little bit cheaper. But it's worth just doing a little bit of research and then making sure that when you make the case for whatever you decide, that you kind of base that on strong evidence because you've assessed what's out there, would be my piece of advice. But I know everyone's different. It's hard. Amber: Yeah. There was a question which I think is pretty quick: as far as headings, do the same rules, like, on the web apply? Meaning you should only have one H1 per document. Samantha: Yep. 100%. Amber: Okay. And then, also on the topic of headings, Nick had asked, "Do H5 and H6 exist in this context?" They also asked about UL, like unordered list versus numbered lists. Is there anything different in the tagging of those? Samantha: No. So your numbered, for example, would be your label. So label could be anything. So in the example I gave, it was my bullet, but my bullet could be a number, it could be A, B, C. It could be whatever it is you've got there. And the first thing about, yes, you can have headings five and six. So you can call your tags whatever you want, you just change the number. Of course, things like that get a bit complex, but you can absolutely have them. They exist, so they should be tagged as well. Amber: Okay. Yeah, so basically that's why you have the label tag in list items where it's saying, "This is what my label is," and it could either be not an emoji, but like a character, right? Exactly. Like an ASCII character or something, Samantha: Yeah, it could be a guide- Amber: Or an actual number. Samantha: Yeah. Yeah. Absolutely. It could be whatever your label for your list item is, that's essentially what it is. So yeah. Amber: Okay. Someone wanted to know: how do you set the logical order for multiple column content? Samantha: That's interesting. So I would just say whatever way you want to read it. So normally for multiple columns it would be top to bottom the first one, and then top to bottom for the second one. So you would just set it in that order. So making sure when you kind of tab through that you're tabbing through in that order. It depends which way you want to read it. If you're reading it across the page, that is interesting. So I would say just reading each column down would probably be the most logical way. So just make sure that your order reflects that, in terms of the way that it's displayed. But, yeah. That's an interesting one. Amber: Okay. How about headers and footers? And I know you touched on this briefly when you were talking about making things artifacts. I was interested 'cause you were saying maybe page numbers are an artifact, and I was thinking, "Isn't that useful for people to know page numbers?" But then it was occurring to me that they might get the page number anyway from the screen reader- Samantha: Exactly that … Amber: So they don't need it. Samantha: Yeah. Amber: So can you talk a little more about headers and footers and how you would know whether you should artifact content or not in those areas? Samantha: Yeah. So you're right about page numbers. That's exactly why I suggested that. For headers and footers, it's obviously context-dependent on what they say. So we tend to avoid, I try and tell people to avoid headers and footers wherever they can, 'cause if it's important, put it in the actual body copy of your document and then you don't need a header or a footer. So normally if, in our document, if one exists, it's things that are repetitive or it just says Ministry of Justice or something that is irrelevant, it's just there because someone wanted to put it there. So in that case, I would artifact that content. But footers are an interesting one because footers normally include things like footnotes, which of course you would want to tag. There's a footnote tag for anyone who's interested. That exists. Again, you would need to do that slightly differently. Now, I won't get into footnote tagging at this point in the webinar because we won't go there, but normally they're links and things like that, so they have to be structured slightly differently. But, I would say just assess the content in the header and footer. If it's repetitive, maybe keep it on the first page and then artifact it from then on. Whatever you think is most appropriate, but it doesn't need to be repetitive on every single page. Amber: Good to know. Thank you. S asked, "Will the Tab key also work on PDFs to navigate from one active link to the next?" Samantha: Yes, it- Amber: Like you use on a webpage. Samantha: Yes. Amber: Okay. And I think we've already answered about numbered lists. Hold on. Let me just look through. A re document subject or keywords valuable to people using assistive tech or is that just meta information? In the other things that exist in the document properties panel? Samantha: Yeah, it's a great question. it's subjective. I think it's metadata, personally. I think, again, I'm not a screen reader user myself, so I'm not gonna talk for that audience. But, as far as I know from people that I've worked and tested with before, the document sort of title and file name are the most important things, and everything else is a sort of bonus. I wouldn't spend too much time adding it in unless you need to for your sort of organizational policies when it comes to metadata and things. Amber: Do you know of any tools that… I'm kind of riffing on, Bjorn asked a question about if the source is an accessible HTML document, can we save that as an accessible PDF? And I know we've talked about this internally, because of course I think the answer is if you're just using the browser save as PDF, it's probably not gonna be tagged at all, would be my guess. Do you know of any tools that allow you to, or that automatically can convert HTML pages into accessible PDFs? Samantha: No, mainly just because I don't work with those kind of things, but it doesn't mean they don't exist. I'd test a few. I'm sure they probably do exist. It feels like something that, yeah, is quite, like, kind of basic in some respects, I would say. But yeah, I think you're right in terms of printing a web page to PDF.It's basically like sending a Word page to PDF. It's printing it to PDF, so it's not gonna be accessible. But there might be ways you can, do it. So sorry I don't have any recommendations, but it's a great question. Amber: let me see. Francois asked, "Should you use a screen reader to test the resulting PDF, or is that something you do?" Samantha: Yeah. Yeah, I do that. I will do everything I said, run it through PAC if I can, and then test with a screen reader as my last thing, because it just gives me that final seal of approval and I feel then satisfied to send that out in the world. But that's just me being a little bit of a perfectionist as well. But I do think it's good practice. Amber: Yeah. I agree. I will also say, I don't know if you've had this experience, but the keyboard shortcuts when you're using Adobe are different from on the web. And so there's definitely a learning curve to figure out how to get a screen reader to read a document to you in Adobe. Yeah. Samantha: Yeah. I 100% agree, and it doesn't help when I try to test with three different screen readers just to give a kind of as best a, kind of overall compliance as I can, which then again does complicate things. But once you've got the hang of it and you've done it a few times, you kinda know what you're doing, so it's worth learning the first to then know forever. Amber: Okay. We are almost at 10 minutes over, which is when I'm gonna stop, but let's see real quick. Do you know if InDesign is pretty good at tagging when exporting to PDF? Samantha: Yeah. The Adobe family are pretty good keeping themselves in check. So yeah, most things that are designed, again, obviously 100% depends on the original design, as with all these things. But if it's been designed correctly to start with, then the resulting PDF, again, is pretty good. Again, not perfect. Check it. But, it's probably better than a lot of things, I would say. Amber: Let's see. Do you know any workarounds regarding optimization plugins that strip PDFs from their structural metadata, including accessibility on upload? Samantha: I do not. That sounds like an issue, though, that I would not wanna not have to face. Amber: Yeah. So I, would say if you're using something like WP Smush or one of those WordPress plugins that try to optimize all of your uploads, usually you can exclude certain file extensions. So I would, by default, just exclude all PDFs from, like, minification or smushing or trying to make the file size smaller, because I feel like that's when they're gonna strip it all out. We're at 10 minutes after. I so much appreciate you being willing to stay extra. And there are a few questions that we probably don't have time to dig into. So where would be the best place if someone wanted to follow up with you? Is there a social media platform you're on more? Samantha: Yes, I'm on LinkedIn, yeah, I'm just Samantha Merrett on LinkedIn, so feel free to come find me. I will absolutely answer any questions anyone's got. Always happy to connect with others, so feel free. Please do. Amber: Great. Thank you so much again, Samantha. Thank you everyone for tuning in. Our goal this week is to get this recording out the same week, so hopefully you'll have that soon, and we'll make sure that we include a link to the slides as well. Samantha: Yep. Lovely. Thanks for having me. Amber: Thank you. Bye. Samantha: Thanks. Bye., A Practical PDF Remediation Demo: Samantha Merrett, youtube.com, 01ky54t98gw3derm0fvyvd2vzd.