>>ANNOUNCER: Welcome to techinca11y, a webinar series dedicated to exploring the technical challenges of making the web accessible. This month, our presenter is world renowned expert in PDF accessibility, Adam Spencer. And now, our host and moderator, Michael Beck.
>> MICHAEL BECK: Hello everyone, and welcome to this February edition of technica11y. If we have any new folks with us, I'm Michael Beck, the Operations Manager at Tenon, stepping in for Karl Groves. We are very excited to have Adam Spencer of AbleDocs, one of the world's foremost experts in PDF accessibility. Hello, Adam.
>> ADAM SPENCER: Hey, Michael. Thanks so much for having me.
>> MICHAEL BECK: Of course! Adam is going to address one of the greatest misconceptions in the world of document accessibility, namely the statement that, “My documents need to be WCAG compliant.” He'll explore the similarities and differences in language that need to be understood when making PDF documents accessible and compliant for PDF/UA. Without any further ado, take it away, Adam.
>> ADAM SPENCER: Super. So, thanks again. And yes, some of you may know me from my previous life. I was head of accessibility services at Accessible-IT for the last nine years and in November, I stepped away from that position and moved over to taking over a new firm that was actually an old firm in Europe. So, we'll be making a much bigger announcement about that in the coming days and weeks. So, forgive me if our slides aren't as polished as they could be. Obviously, I'm sure you can appreciate that there's a whole bunch of things to do when launching a new firm, but it's business as usual. One of the things that I have always run up against when speaking about PDF accessibility is, “Why do I need to do this? Why do I care about PDF? What the hell is this PDF/UA thing and why can't I make them WCAG compliant?” I have spent a lot of time over the last decade making sure people understand the similarities as well as the differences and why it's important to understand what you need to be asking for when you're requesting your downloadable content to be accessible.
We'll walk through this and I always have a challenge with webinars because it always feels so one sided. But, I assure you we will definitely have time for questions and comments at the end. And if you have any that you'd like to write into the chat panel, by all means we can work through them afterwards.
So, I think where we need to straight is let's set the record straight. PDF/UA and WCAG 2.1 are not mutually exclusive. They are not mutually dependent, but they are always complimentary. So that always becomes a founding place for us. Asking for something to be accessible in a PDF content does not mean that it is not WCAG compliant. But what it does means is that it's compliant for specific format, and that's PDF.
So, why are we still talking about PDF? Well, this is always a great question, especially when you're talking to a room full of web developers. Contrary to popular belief, PDF is still very, very relevant. PDF technologies predate the internet. We've been working on PDFs since the ‘80s and since then it has now become really the document format standard and is still used today extensively. There are over a billion PDF's loaded to the internet every year. This is validated by Adobe on an annual basis, and that's where you've got to understand that you can't just be a web manager or content manager and say nothing is going to be PDF. And I will say this: I am not a PDF exclusivist, and I may be coining a new phrase there. But, one of the things that we're looking for is how people access content and it's often forgotten, and I think we get into a very rigid mind set about, “I'm good at this and this is what I'm going to do.” And we've obviously had that kind of struggle between the web world and document world over the last five years, six years about we have to eradicate all of our PDF documents. When the federal government in Canada was sued for discrimination against an individual with a print disability, their reaction was to remove all of that content. But that content is still very valuable. I always go back to a 300 page report. Can we make a 300 page report in HTML? Yes. Should we make a PDF report in HTML? And the answer is no. Nobody's going to read that type of content. That's why I'm not going to sing “Kumbaya” and hold everybody's hand about different formats. But it's important to understand the difference of the use of different technologies for different applications and different methods of communicating. If you’ve seen me speak before, I make the joke about not everything should be a PDF, a web page, or tweet. And that always kills in Washington D.C. or on the coasts, particularly with what's going on in the U.S. lately. So that's why, you know, we can't ignore the document problem or the document reality, I should say.
PDF's have been built upon a platform of trust of the content and that's an important concept to understand. When you see a PDF, we can validate whether that's the original content or not. That's why there's so many subsets to the international standard for PDF technology. Things like archiving. Things like accessibility. Things like engineering drawings. They're able to be trusted because of the way that the file is created. PDF is a very technical standard. It's not something that you just pick up and run with. And I think that's been one of the biggest challenges that people have faced when it comes to document accessibility. Everyone's looked for an easy button, and we're all guilty of it. But the reality is, it is a very technical piece of technology. And that's okay. But you need to understand what those differences are.
So, when we're looking at organizations who are generating PDF content, the reason they're doing it is many are old, and particularly in Europe, documents have to be saved for PDF/A, which is the archive standard in order to be posted online because of that element of trust. We're able to see that with documents. And one of the cool things about PDF is that all of these subsets, all these substandard, PDF/A, PDF/X, PDF/UA, they're all complimentary. They're pieces that may overlap and may not be fully compliant, but they don't infringe on the ability to either meet those standards or still access the content.
And one big thing that I always reiterate, PDF is not owned by Adobe anymore. It is not their product. They are obviously the largest contributor to the product development, but it has been an ISO standard. And starting 2004, there was effort from Adobe and the ISO to allow PDF technology to be an ISO standard. So, the International Standard of Organization is really built upon the global market understanding what it is we're talking about. So, we have the same language so if a PDF that's generated in the United States can be accessed by someone accessing it in Australia, Japan, India, it doesn't matter. This is what we call a PDF. Unfortunately, there are a lot of organizations that have bastardized it and make it in an open browser, let’s say, and I won’t name any names. I’m sure you’ve either had experience with it or come across challenges when accessing documents loading in browsers, very popular ones at that. But the standard is a living document. It's refreshed, well, we just published PDF 2 in the spring. And so there's a group of people who get together and work together through the year to make sure that we're meeting the needs of the document format as well as clients who come across new challenges or new technologies that we can include into PDF. So that's a really big thing to remember.
Everything related to PDF is based on its ISO 32000-1 standard. There are going to be a few numbers that I talk about today, but don’t worry. If it’s a PDF and it’s a compliant PDF, it confirms to ISO-32000, everything we do after that is a subset to the standard.
What is PDF/UA? UA stands for universal accessibility. It was a project started as early as 2004 where the reality was PDF content was inherently not designed to be accessible. It was designed to be printed and transferred from one machine to another, even pre-dating the internet, so that one print shop can see what a designer had built and have it print off perfectly well the next time. So when UA started being contemplated by Adobe and AIM, which is a U.S. group that works in conjunction with the PDF association, the goal was to increase accessibility of content within a PDF context.
PDF/UA is also an ISO standard, it’s 14289-1. We're currently working on Dash 2 and we hope to have that ratified later this year. It is not exciting to read by any stretch of the imagination. If you're ever looking for an easy way to fall asleep on a long flight, I highly encourage you to take ISO 32000 and 14289, and if you can make it past meal service, you may want to join the committee. We would love to have you because it's a very technical document.
And it's a normative technical standard. What does normative mean? It means that we're providing guidance for developers, typically developers, to better understand what it is they need to know when creating an accessible PDF. What PDF/UA is not a guide like WCAG itself. It's not really telling how to do it, it’s telling you what you need to do versus what you can't do, and I think it's a very important distinction. You raise a much more technical yes or no pass or fail kind of a standard rather than WCAG – and this isn't a criticism of WCAG – it’s more of a, “If you're running into this, you should be looking at that,” whereas PDF/UA is, “If you have this, you must do this or you should do that or you may not do this,” and it's very technical.
It also provides consistent guidance for achieving accessibility within a PDF context, and there are three pieces to the UA standard that's important. We're not just focused on the document itself. What we're focused on is how a file is going to be created and accessed, how a piece of adaptive technology is going to access that content, and how a viewer like Adobe Reader, Adobe Acrobat, Nitro Reader, even a web browser is going to present that content and it’s got to be presented in a consistent way. Again, we get back to that consistent experience from a user's point of view as well as from the technology's point of view. We want as many applications to be able to understand the file, interpret the file, access the content within the file, and provide it in a meaningful way, regardless of how they're accessing that document. And as I said earlier, it’s an additive spec for ISO-32000. So, again, a PDF/UA file to coform must conform to 32000. So, you can't have one without the other.
So, why do we need our own spec? Why can't we just leverage WCAG and say, “Bob’s your uncle,” and we'll use the 32 pieces of guidance that are provided by the W3C for PDF? First of all, PDF is not web content. I'm never obligated to post a PDF to a web page. I can create it on my PC, put it on to a USB key, hand it off to Michael, and Michael can read the file. It's a very different mentality to the way that the document is created. The other thing to consider is people don't really author web pages. When you're writing content, you're typically writing it in a different application, whether that be Word or Google Docs, or anything like that and posting it into a content management system. PDF is different. We leverage the design on the page, whether it's in Word, Google docs or InDesign, and then create or we distill a PDF file. So, that's one thing that's important, the way that PDF content is created is different than the way web content is created.
And those formats are not created equally. That's where we got to look at the differentiations between WCAG and PDF. There are different capabilities within each file type within each format, and those pieces need to be respected and understood in their given context. When we start to ignore those differences and try to harmonize it, the reality is that's not how people interact with content. You have to remember that, and I think that's gotten lost over the last five years and having seen the transition of who's making content accessible and who isn't; it's a very interesting life span of content. And I cringe every time I hear, “Well, we don't need our documents anymore.” Not every organization can say that. You obviously need to cull content, but rewriting content that already exists is a costly process rather than making existing content accessible.
So the people who were working around PDF recognize that those unique capabilities needed to be addressed in order to ensure equal access to content. Again, documents do things different than web content. And the people who we work with now, obviously want to make sure that we're providing the best experience for everyone, regardless of the type of AT you may be accessing the file with. Sometimes there's a whole bunch of subprojects going on on a regular basis, trying figuring out how to push the limits, what we can do within a document context.
And, “Authors, authors, authors.” The reality is, it became very easy for people to File > Save as PDF, and again, billions of these things floating around the internet and sitting on desk tops and we want to make sure that authors understand that they can make their documents fully accessible and fully compliant. One of the challenges is the guidance around that has been difficult. You can't learn PDF accessibility in a day, but, you can learn it in a reasonable amount of time, if you're prepared to be focused on making that happen, and I think that's one of the things that gets very quickly glossed over. It is hard. That's why services like AbleDocs exist. But, understanding how authors can generate content in different applications and still publish it in an accessible way is really an important piece to understand.
So, going head to head. We are friends, not frenemies. I have been stressing thing for at least eight years. We are not suggesting that one format should win or one format should die. I apologize, I’m in a departure lounge because my flight was late, so forgive me for the background noise.
So ,this comment of, “Friends, not Frenemies” is one we’ve got to embrace: how content is to be authored, how it's distributed and how it's going to be accessed and I think too often internal design teams, internal web teams, compliance officers don't understand the relationship between the two to be the two formats, so that they pick one or the other because of a single directive and that just a sustainable approach. We have to recognize that there is a much easier way forward, and bluntly, a much more cost effective way forward. We were working with a client a few years ago that was planning on removing all of their PDF content, hiring people to reauthor all of that content into HTML because they needed it on their web page, and it was going to cost them an absolute fortune whereas we can remediate the PDF content already there, make it accessible, make it search engine friendly, make it catalogable for a fraction of the cost, and it boggled my mind that someone would even consider that. But again, we internal advice we're receiving from constituents is we like web pages because we can access it on our phone. Sure. But you can also access a PDF on our phone.
So, this is a very, very important piece. PDF/UA and WCAG 2.1 have no conflicts. They're complimentary. By making your file WCAG compliant, that does not mean it’s not PDF/UA compliant, or vice versa. They're different considerations that PDF/UA looks at and WCAG 2.1 looks at. It's understanding those differences, and understanding those differences, that help make a more accessible document and that's something important to keep in mind and we'll get into what those details are in just a minute.
But keep in mind: PDF/UA doesn't address everything, and I think this is a really important piece. We don't address media. We don't address actions. We don't address scripting. We don't address design. And we don't address content. One of the things that the authors of PDF/UA are very conscious of is we don't want to tell someone what we can or cannot do with their own content. What we do is provide guidance around how people should be making that content accessible. And when it is a content consideration, we actually recommend referencing WCAG. If you don't know what to do for a video for accessibility, as an example, check what you should be doing in WCAG's guidance around media, particularly captioning and the rest. So, those pieces -- that's again why we've always found it quite interesting there was such a reluctance to embrace PDF/UA by the W3C, historically, as well as governing bodies or people in the industry. We're not saying that WCAG isn't valuable in a PDF context, but there's so many more things that need to be discussed above and beyond the 32 guidance techniques and that's really an important thing. And I can tell you that there's an initiative right now, that is happening as we speak, to unite the two and have WCAG directly reference PDF/UA, which is really exciting, and I would suggest, it's not just exciting for those who care about PDF, but exciting for all content authors because now there will be an easier way to better understand how to make all content accessible in a digital context or I should say more pieces of content accessible.
And I think that's a really great thing. There was a meeting that was held or a summit that was held in Edinburgh, Scotland at the beginning of December, where PDF experts around the world got together and discussed how we can build canonical references for this is how you make PDF accessible or this is how you make this piece of content accessible, and we're going to be publishing that in the coming months, which is really exciting because it allows people to understand, “I've come across this… what do I do with it?” And that's a really important piece. So, although the language may be a little different and although PDF/UA doesn't address everything, it allows us to have a common bond between the different format types and the different types of content that people are trying to put in. We laugh in our internal teams about the pieces of content that we receive and how authors are always trying to push the limits of what they can do, whether that's from a graphic or design standpoint, embedding new widgets into the format. It allows us to challenge ourselves and say, “Okay, how can we make that accessible?” There are a couple of us that were having a conversation in a meeting a few years ago about how we make 3-D CAD rendering live and how we also make it accessible. And the cool thing is, it's possible. It's not easy, but it's possible. And I like seeing what else we can do and quite frankly, that's not something that WCAG touches on. So, maybe we'll be able to bring something to the forefront when that gets hashed out.
So, the details. Time based media alternatives, test, sensory, and CAPTCHAs: UA does not address these items. We always recommend addressing WCAG. We can't have those pieces exist within PDF/UA. It just isn't how the format works. So we don't have that.
Audio and video content: we do include syntactical requirements. So, we tell you how to tag something, but we don't tell you what to do with the actual content. That's something that WCAG does something much better than UA and that is not going to change. We will never address what that content accessibility should be. And a lot of that has to do with the fact that we don't have audio/video experts or people with audio/visual disabilities within the committee to help form that guidance and we didn't feel it was necessary to reinvent the wheel. If it’s already being convered in WCAG, let WCAG continue to manage that.
Control device specific: we are control device independent. The way that content is accessed within a PDF is very much reactionary, not putting the focus from the page to the user. So, it's all about the interactive to the page rather than from the page, and that's a big differentiation. So, we don't cover any of that within our spec.
And design considerations: this is really interesting, and I will say that this is an area that is most challenged when content is made accessible. And there's two schools of thought here. When a file is presented to be made accessible by many remediators in the world, our job is to follow the PDF/UA specification. And often, unless otherwise specified by the client, that will be it. So, for example, low color contrast, or the type of content put in is an inaccessible piece of content. We won't come back and indicate to the client they should change this. Now, what I will say is, that varies country to country. That varies organization to organization. However, it's really important to understand where these changes can be made. PDF isn't like HTML where we can swap out a CSS script and change the coloring throughout the document. That needs to be done at source. Nobody authors a PDF document. You author a Word file or InDesign file or PowerPoint deck. And when you're looking at those pieces, you then realize how that content is being created in the authoring environment. That's where the change is made. Unless we're provided with the source file, which is often not the case, it's very difficult to make those changes within the PDF. There are tools that make it easier, there's no question about that. But, we can rely on different semantic equivalence.
For example, we can change the way that the page is presented based on certain print disabilities or user requirements. But, that has to be done in the viewer, not on the page. And this is a philosophical debate that goes back and forth. And I was actually having dinner with someone the other night and they said, “Yeah, we received a document back and the color contrast was awful.” And I said, “Great, you should have spoken to your authoring team and your design group and educated them on how to make a more accessible design.” And he said, “You know, that's a really interesting point because we expect that to be done later in the process, whereas in the document world, we expect it to be done much further upstream.”
So, I think this becomes one of the interesting debates, and I don't know that we will ever find true consensus on how that comes through, but that's always the conversation. And I will say personally, we're happy to make those alerts happen, but it becomes a much bigger challenge in a PDF context than an HTML context for those visual appearances.
So, what we look at is, for example, if there's a bar graph with very low color contrast or the sizing of the text is poor, we have been known to embed tabular content behind the image, which could be a much more accessible option rather than relying on low color contrast and grainy quality imagery. Although, a table can sometimes post challenges for some, it's actually a really easy way to access the content if the table is tagged correctly. And I think that's one of the things that we've seen over the years.
Just sticking on content, PDF/UA worked really hard to make sure that even complex content could be made accessible and navigated easily. There was a period of time where people providing training were saying simplify your content, make it easier, don't have complex tables. And I will push back on that quite strongly because it's not the case that content authors can do that. When you consider things like financial tables and annual reports, you can't simplify that table. In fact, it would be illegal to simplify that table because of recording requirements. But, people were providing that guidance because they didn't know how to make the table itself accessible or authoring tools weren't able to generate completely accessible structures. So, you're all of a sudden telling an author how to create content without understanding the way that the way that content can be presented to a user if some additional steps were done to the document.
That one always rubs me the wrong way because I always felt that it's important to make sure that people understood as much as possible about how compliant content can be, even complex content, rather than ignoring all of those pieces because it's hard or they didn't know how to do it. So, that's just something that I wanted to add in. And I'm always happy to have a conversation about design considerations any day of the week.
Dynamic XFA: XFA is an XML based subcategory that has been used for almost 20 years now that allows for dynamic forms to be created. So, things that are responsive to users' input. And they can be very, very accessible. However, they are prohibited in PDF/UA because we can't control them the same way in a PDF context. That being said, they are not prohibited by WCAG. And you can make an XFA PDF accessible in a WCAG compliance framework, but you can't do it in a PDF because of the way that the guidelines are set forward.
So, when do we refer to UA? Forgive me for all of this text. I'm not going to read this out. I'll make it available. I don't believe in reading out slides. [Chuckling]. So one of the things we really look for is interoperability, and it's that document of trust. We want to make sure that a PDF is always reliable in the way that it renders, the way that it prints, the way that it's viewed, the way that AT interacts with that content. And WCAG does not normatively address interoperability. It is always going to be our focus to make sure that regardless of what application is accessing the content within the page, we’re putting normative guidance around how that should be done. And then it's up to the developers to make sure that their software can do that.
Again, it is all possible. However, some organizations don't want to put the resourcing behind it, making sure that that's done. And I think that really does a disservice to users because the number of times that a user will open a file and it's still not accessible because the author in the group doesn't know what to do with it, is really missing out on that interoperability factor. Because it has been around for so long, PDF remains that go to for accessing content or distributing content because of how it shows up. I know that you're going to be able to see the exact same thing that I do or you're going to be able to access that content in the same way that I'm going to, and I think that's a really key aspect of why PDF/UA is so great and why PDF as a format is so great and really becomes a corner stone of what we're trying to accomplish.
Fonts: fonts are a fascinating piece of PDF accessibility, and not just from a design standpoint, but from an embedding standpoint. And that section 7.21 is so critical for the accurate conveyance of the author's intent with legibility. What we were able to do is smoothly render that content in any size which so important. And yes, there are some fonts that are still not available with that rendering, particularly in dialects. We have some of that challenge with Native languages because they not be TrueType and that may cause a legibility problem going forward. The other cool thing is that there's some AT that can interact with embedded fonts and convert those embedded fonts. People who may have dyslexia, they can then swap in a new font that would be easier to read and access your content in a way that's much more approachable for them than what the author intended. So, even if, a user put a serif font in place, which can be more difficult for something to read, a user can swap that out to a sans serif font and make it easier to access that content. I think that's a great opportunity for content authors to consider general accessibility or a broader accessibility when you've got the ability to allow the user to customize it in a way that works for them.
Headings as nav: most files have headings. And it's really the only feature that allows navigation within the document. The way that we navigate content in UA is really strictly based around heading structure. So, we're building that hierarchical order of content, and they've got to be logically ordered. And what that means is you can't go from heading 2 to heading 5. The context doesn't make sense for a user. So we're looking for an H1 to H2, 3, 4, 5, 6, in that order. And the cool thing in PDF/UA 2 is we can do it in a nesting way that doesn't limit the number of headings. We used to be limited to six. Now, we can effectively go unlimited with nesting, and that's a really cool thing that allows the user to pull up their heading levels and say, “Where do I want to go in this document?”
Some authors will not use a table of contents, for example. Maybe the document is only 20 pages and they feel they don't need that kind of navigation. But, a user of AT does. And so, by forcing, through UA, the document to use that structure to allow an individual to navigate the file using these structures, WCAG doesn't mandate that. So, and again, you can navigate using buttons and links and all sorts of other anchored referencing. But, PDF doesn't have that, so we've got that now. We’ve leveragde the heading structure for that type of nav.
Article threads: this is a way for users to think of a magazine article. Instead of having it go from page 1 to 25 and read all of the content before, one of the things that PDF/UA allows is for articles will follow the logical structure. So you can move through an entire story as a combined piece rather than having to try and navigate between, “See continued story at top of page 7.” We can tag the file to follow that rather than just the tag structure. We're following the logical structure, the semantic structure, rather than having to find that content somewhere else. So again, something really unique to PDF/UA and really based around the print world and I think you've got to remember that. That's where the foundations of PDF are. It's in that print world that allow us to have different pieces of content show up in a logical order, but we're going to be able to, on a digital order, not necessarily a logical order. So we're able to get around that within a PDF/UA content.
One big rule, and please take this away: failing WCAG 2.1 conformance with PDF/UA, you will violate UA...Sorry, violating UA file should be considered a violation of WCAG 2.1 or 2.0. The only exceptions to that are included. They are sections 7.4.2, 7.4.3, 7.4.4 and 7.12. None of those are required by WCAG 2.1. Those are the subsections I went through earlier. If your file is not compliant in the PDF context, it is impossible to be WCAG 2.1 compliant. Those are the pieces that you've got to recognize. I have in parentheses the XMP metadata flag and what I will say to that is this is a self-reporting piece of metadata that is added by an author of a PDF/UA compliant file that identifies the file as being UA compliant. That is not validated by anyone. That is self-reporting. So, a user can put that in and say, “I'm compliant.” However, that doesn't necessarily guarantee it. It's not like a PDF/A file format requirement. So, that's one thing to keep in mind. Again, I'm happy to go into greater detail about what the UA XMP metadata flag is.
The nitty gritty: if you're looking for a detailed framework, I wasn't going to go through the table side by side comparison of WCAG to PDF/UA, where those subsections can be found in each of the specifications. I thought may be sleep inducing. But, it is available and this was done [see https://www.aiim.org/Global/AIIM_Widgets/Community_Widgets/Achieving_WCAG] I want to say three years ago, four years ago now by AIIM. And you can see achieving WCAG and following the guidance of UA versus following the guidance of WCAG. A few pieces have been updated since it was authored. But it's a great resource to say, “Can I do this?” Yes. How do I apply? Do I apply it using the compliance provided by the ISO?” I thought that could be helpful.
And that's me. And we've got 15 minutes for questions and comments and dialogue, if anyone would like that.
>> MICHAEL BECK: All right. Thank you so much, Adam. First question we have is from Elizabeth. She wants to know if you have an example of a complex table and “fix” for it that goes beyond just header IDs.
>> ADAM SPENCER: I do. And Elizabeth, if you want to send me an email, I'll be happy to send you one. Part of the challenge is how you add those pieces in, and again, I'd be happy to walk you through that. I will say, and I try not to promote or discourage anyone from using any piece of software, all of the major PDF accessibility tools can do this. Some do it easier than others. [Chuckling]. So, that's one of the challenges that you may run up against. And again, happy to have that conversation.
>> MICHAEL BECK: Perfect. And then Isabella would like to know how to make maps accessible on PDF, like a visiual map on a brochure of office locations.
>> ADAM SPENCER: Good question. We do a lot of maps. I think over time we've probably done about maybe half a million maps in our time...
>> MICHAEL BECK: Oh, my.
>> ADAM SPENCER: Yeah, it's a lot. We have a client that is very map happy. There are really two approaches. And we worked with some users at the CNIB a number of years ago to try and best tag a map. And there were a few approaches that we relied on and one is obviously tagging the map as an image because it is an image. By PDF rules, we have to tag semantically. An image is an image. We don't have a map tag. The alt text approach, so, writing a description of that map is a bit of fine art. You have to give someone context for where things are, and that does take a little bit of understanding of the map itself, where things are, how could they be geo-located, how can they be referenced? So, we look at bounding area. So if you've got a large map, we're going to show a context. So, let's just use the state of New York. If you've got a state of New York but the office is located in Buffalo and in New York City, we would start by the macro level indicating that this is an image of the map of the state of New York and indicating that there's an office in Buffalo. We would look to add the actual address if we could, as well as the address to the office in New York, depending on what was being highlighted. We have also been known to add a much more detailed text description behind the image of the map to provide greater detail, particularly on schematical drawings on top of maps when you're looking at planning documents. They just need more notification to the user and putting that all in alt text is a really tough usability piece obviously when you can't navigate or pause or rewind that content in the alt text. That's why we like to use the text behind the map. Also, always making sure that you're identifying highlighted pieces, things that are identified within a legend, you're identifying those on the map as well. Always tag the legend, always tag the title, and give people as much context and if the map is very detailed, provide text behind the scenes and tag it.
>> MICHAEL BECK: Sarah asks: Is Adobe Acrobat really the only tool for editing PDFs?
>> ADAM SPENCER: Absolutely not, no. There are three really big ones. Adobe Acrobat. There's an organization called axes4. They have a tool that does a lot of advanced tagging work called QuickFix. You can also do PDF accessibility in a tool from CommonLook. They have a tagger add-in that leverages on Acrobat. Those would be the really top three tools. There are other subsets of those tools that make it easier, but, those are really the big ones. One thing is you cannot generate a fully compliant PDF file from source. It’s impossible. Microsoft can't do it. Adobe can't do it. There are things that can get you more accessible but you have to do a finishing pass to make sure that your file is fully accessible and compliant. Always look into those. Sarah was asking for that. Sarah, if you want a full list, I'm happy to have that conversation with you.
>> MICHAEL BECK: Perfect. And almost like a companion question. What is your favorite tool for checking and verifying PDF accessibility?
>> ADAM SPENCER: I have my own! [Laughter] A lot that comes down to because of the way we generate content and how many documents we make accessible, we need more advanced tools to deal with that. There has been tools to releasing, but our tool is a proprietary one. Previously, relied on QuickFix and the tools from axes4. I have a personal relationship with the guys there, but it's because of the tool there.
>> MICHAEL BECK: Okay. What about ebooks? How difficult it is to make them accessible?
>> ADAM SPENCER: It is not. Ebooks is actually really easy to make accessible. The question is, “What format do you want to keep it in?” Are you looking at keeping it in PDF or EPUB? And I don't want to be too commercial about this, but we have a tool that goes from an accessible PDF to fully accessible HTML and EPUB in about a click. So you have to decide how you want your content being accessed and read. So that's the piece that's really look at.
>> MICHAEL BECK: Is that a proprietary tool of your own?
>> ADAM SPENCER: It's a service that we provide.
>> MICHAEL BECK: A service that you provide, okay.
>> ADAM SPENCER: And actually, we haven't launched it publicly, but if you get in touch, we can run a demo and show you.
>> MICHAEL BECK: Okay. So Isabella, go ahead and get in touch with Adam, email@example.com. You can see it on the screen. He can have that conversation with you. Do we have any other questions? Nope. Oh, yes, yes, we do. Elizabeth again. Is there a resource that goes into detail about the structure tags, like what can be a child of what?
>> ADAM SPENCER: On the record, there is not. Off the record, there is, and if you send me an email, I will send it to you. [Chuckling]. The PDF Association will be publishing that, but currently, it has still not be ratified. So, I'm happy to send that along.
>> MICHAEL BECK: Excellent. This was fantastic…
>> ADAM SPENCER: And the rules can get complicated.
>> MICHAEL BECK: Oh, okay. That's good to know. In my previous life as a law librarian, we dealt with governments pushing more content out in PDF and them using PDF/A to make it official and just to make sure people haven't screwed with it. Authenticate it, that’s the word I was looking for. That was interesting for me to hear the technical aspects of that.
>> ADAM SPENCER: And all of the content we produce for clients in Europe has to be PDF/A as well as PDF/UA. So we don't have a choice.
>> MICHAEL BECK: I wish that some more domestic U.S. government bodies would do the same.
>> ADAM SPENCER: Agreed.
>> MICHAEL BECK: [Chuckling] So that's it, that about wraps up this edition of technica11y. Thank you Adam. Thank you to our participants for joining us. We'll have this episode up on our YouTube channel soon. If you missed something, be sure to check that out. Please, please, share this knowledge that we've been amassing with your colleagues. Next month, we'll have Luis Garcia, the senior product manager for accessibility at eBay on to discuss the various color-related WCAG criteria and how fixing one might create issues in other aspects of a site’s accessibility. That will be on March 6th, and we hope to see you all then. Thanks again, Adam. And thanks to Sylvia from ACS, for the captions. And once again, thanks to all of you. Enjoy the rest of the day.
>> ADAM SPENCER: One quick thing, Michael. If you're trying to go to our website, it is being launched under the new branding new week. So apologies for the sparse details on there.
>> MICHAEL BECK: There we go. Good to know. Thanks, everyone.
>> ADAM SPENCER: Thanks so much.