 All right, hi everybody, thank you so much for coming today. I know it's 4.30, and I'm probably your last session of the day, so I'm happy to get started on time, and I'm really happy to see so many of you here. When I was thinking about what I wanted to present at DrupalCon, I was having this challenge with a project that I was on, and I wasn't sure how much interest there would be in it, or how universal the challenge would be, and so I'm excited to see so many of you here today. I'm also excited to be back in person. I was at DrupalCon Seattle in 2019, which I know is the last in-person event, and despite everything, it feels really good to be back in person, so thank you so much for coming to this session today. As the title suggests, we'll be talking about ways to audit PDFs for 508 compliance at scale. I'll talk about what happens when you have a lot of content that is nested within PDFs, and then your job is to make that content 508 compliant in Drupal. It's something that I'm still working on, and I've learned a couple of things that I would love to share with you on the topic today. So, to start, my name's Lauren Maffaeo. I am a service designer at a company called Steampunk. We do technical projects and assessments for federal government agencies. I live in the other Washington, Washington, D.C., and we work with all government agencies to do everything from database redesigns to front-end user interface updates. We also practice human-centered design first and foremost, so I'm part of the design and strategy practice, and we really take a participatory design approach to every technical project that we take on, and that will become important later on in this presentation. I am also under contract to write a book for pragmatic bookshelf on data ops and data governance, specifically how to build and implement a data governance program from scratch if you don't already have one, so if that's a topic that you have knowledge about or interest in, I'd love to connect with you at some point during the conference. I'm also in my third year as a volunteer for opensource.com, as one of their community correspondence and total. I've spent over 10 years in tech and four actively involved in various open-source communities. I started my career as a reporter covering the tech sector in London as it was rapidly growing, and I've since gone on to have various roles in tech myself. So as I mentioned already, I'm here to share with you some advice that I gained from a Drupal project that I'm currently on. It's an ongoing project, so I will keep the client's identity private, but we've learned some valuable lessons about auditing content at scale to prep for a Drupal migration. And specifically, the big takeaway that I have learned is that it's really important to design Drupal sites and content for 508 compliance from the start, regardless of the content format. So I'd love to share with you what we've learned today. This was a pretty big and exciting project. It was a small team, so they're in phase one, we're about six to eight of us full-time on it, including three designers. And we were tasked with auditing the content and information architecture for our clients.gov website. This website is written in PHP, and we were tasked with repairing the content for migration to Drupal 9, which will be the client's first ever CMS. We were tasked with ensuring that all content meets 508 requirements once it's in Drupal, and we need to account for all of the content in both HTML and PDF format right now before we eventually do the migration in the future. So I mentioned 508 compliance on my past slide. It's in the title of this talk. And if you're not familiar with it, you might be wondering what it is. It is a legal requirement. The U.S. government is required by law to make its digital content accessible to everyone. And so someone who is deaf, for instance, shouldn't be prohibited from listening to a meeting recording just because they can't hear. And likewise, someone who's blind should be able to get the information that they need from a website no matter what format that information is in. And so this is a quote about what is required of federal agencies. Under section 508 agencies must give disabled employees and members of the public access to information that's comparable to how other people would get it. You've probably heard of accessibility in the tech world and 508 compliance is a big part of that. I really like this quote about how access to the internet by everybody is a crucial aspect of it from arguably the father of the internet. And you might be thinking that this is applying to a niche group of people, but according to the World Bank, one billion people globally have at least one disability and that's 15% of the total human population. So again, 508 compliance is a way to make sure that all of those citizens can access the internet regardless of their disabilities. Before we continue, I'll give the caveat the disability spectrum is very broad. For this presentation, we'll talk about accessibility in the context of screen reader technology and making sites accessible to folks who are deaf have hearing loss and are blind. And so I mentioned that this has been a really exciting project. It's been truly design led and the opportunity to audit a really big site that shares a lot of important information before its first ever migration to Drupal is a really exciting career opportunity. But it's also a little scary because once my design team and I started auditing the current sites content, we quickly realized what a challenge this would be. There are clients primary way of sharing information was through PDFs and it had been using that format for decades. That's a big barrier to 508 compliance which I'll talk about soon. This site also had a lot of content. It had 5,000 PHP webpages, 75,000 PDFs and it didn't really have any existing hierarchies so there weren't any real taxonomies behind the information architecture. And so it was very, and the search functionality wasn't very good as a result of that. So they had a lot of valuable insightful content and it was very difficult for users to find. And so that made our work difficult because we were tasked with figuring out what they had and that before we could even talk about what a migration would look like or what designs would look like on the new site. And this got even more complicated when I realized that 508 compliance for HTML is different than for PDFs. So the Department of Interior has a lot of really good information about 508 compliance and HTML really is the gold standard when you're talking about that because HTML is the expected 508 compliant content format for screen readers. It's also quicker to update than a lot of other formats. It's responsive across desktops, tablets, small tablets and mobile and it's better for multimedia than if you were to, for instance, embed an image into a PDF or a PowerPoint. Conversely, 508 compliance for PDF is a challenge. It's the hardest format for 508 compliance. PDFs are challenging to update. They're not easy to make responsive on other tablets and phones and they're not the expected default format for screen readers and so screen readers don't always know what to do with PDFs. And so that means really that if PDFs are not designed for 508 compliance from the start, making them compliant retroactively, you can do it, but it's difficult and it's manual and so you think about doing this with information in 75,000 PDFs and my team and I had to get creative about how we were gonna make that, all of that information accessible to people on the Drupal site. So we started out, we just finished phase one of this project and it is still in progress so the actual move to Drupal will take some time but we completed a few things in phase one that did really help prepare the content for compliance and help us design their Drupal 9 site with 508 in mind. The first thing that my designers and I did was we went in and made an as is information architecture diagram in a tool called Mural. I really, my design team at Steampunk really relies on Mural. I really enjoy it and I think it's great for collaborative workshops. You actually don't need a Mural account or to download the software onto your computer to access the Mural boards and so they're great exercises if you're looking for an opportunity to have a collaborative working session and so it was actually very easy, not the audit itself, but capturing that information architecture in Mural and so my colleagues and I in design had a lot of co-working sessions where we would go in and make note of the content as it existed on the site. That was also important because in doing so we realized there was a lot of PDF content on the site but you wouldn't necessarily know that if you were just looking at these individual PHP pages because they were lacking icons that showed you when content was not in HTML. So we actually made a key, like a legend within Mural that noted where this PDF content lived so that we could audit that now and then decide what to do with it as we moved closer to Drupal. We also hosted a lot of human center design workshops with our client stakeholders and so this took several forms. We hosted a workshop once we finished auditing the information architecture where we asked our stakeholders where they thought the content on their website should go. That had several benefits and several, the rationale behind it was that we wanted them to think a little more critically about what made sense because typically in government what you tend to find broadly is that sometimes they build services that are unintentionally or not built for their teams and then that content doesn't really make sense to people who are outside of the organization and when you're a government site that is built to serve the public that becomes a challenge and so having that session with them where we asked them to imagine where their content should go was very helpful. We also hosted a stakeholder mapping workshop really early on with them because it's again a big agency. We knew that this site migration will affect many different teams at the agency and it will affect how their information that they put out in PDF format or otherwise shows up in Drupal. So we wanted to get very clear early on with them about who we should talk to and when so that we knew that we were prioritizing the right people in our user interviews and our work. We also collected data on their site from Site Improve and Google Analytics and this was very helpful because one thing if you own a website and have looked at analytics you'll probably find that the majority of your traffic is going to a pretty small section of the site. That was true in this case as well so once we looked at the statistics for where people were going we saw where the biggest opportunity was to focus on improvements and once we had collected that secondary data we started prioritizing user interviews and eventually usability testing on the wireframes and mockups that my UX colleagues built. We also prioritized participatory design which I mentioned already and this is a specific type of design practice that actively engages all stakeholders in the design process both in the organization you're working for and the users themselves and it prioritizes processes and procedures not style. Typically when we think of design we think of just UX work, just wireframes and mockups but again steampunk practices, HCD from the very beginning to the end and that involves a lot of service design work which is what I do and really the ultimate goal is to give everybody a vested interest in a product or services success because it's much harder for someone to reject or be apathetic to a tool that they helped co-design and so we took the attitude that if we were involving the right people at the right time through participatory design we would get a lot more buy-in a lot sooner and that could starve off challenges in the future especially we're trying to avoid technical debt and get the right people involved and the right feedback captured before we start building which is supposed to happen fairly soon. So for us, participatory design took a few forms. We wanted to make sure that we were interviewing people who had accessibility needs from the start and that we were including them in the design process and so we as part of my user research for this project I interviewed some users of the site who were deaf, blind and hard of hearing so more specifically one person that I interviewed is blind and also deaf. So my user interview with her was through an interpreter but she was able to communicate with me completely through her interpreter and then we also interviewed a woman who had had hearing loss throughout her life and so she was not deaf but she was hard of hearing. She was also really helpful because she taught me a lot of nuances about designing for instance for hard of hearing users versus deaf users. She said for instance that if someone is deaf English is typically their second language, American Sign Language tends to be their first and so that comes up when you're talking about things like closed captioning on a website and so those are things I wouldn't have necessarily known if I hadn't included her in the interview process and we also got lucky with who we included in the interview process because these women did not just have lived experiences of accessibility needs, they had expertise auditing digital websites for accessibility so the woman who had had hearing loss throughout her life she had spent over a decade auditing websites for community colleges in North Carolina to make sure that they were in compliance with 508 so she was an expert on the topic along with having that lived experience and so her expertise was really valuable to us. We also included them in usability testing so the rough order of things is that we would conduct the user interviews, we would capture the results and report out on the results of those interviews to our stakeholder team during biweekly sprint demos and then we would incorporate that design feedback into the wireframes and mockups that my UX designer colleague built and so we included these folks not just in the user interviews but then in usability testing to ensure that what we were designing was going to be compliant on the new site. So this took, and this took a few forms in terms of the results of the participatory design. As mentioned, we did present their recommendations at sprint demos and we were pleasantly surprised to find that the site is actually already quite compliant. There are definitely things to improve upon but the overall feedback from this group is that it was pretty good and actually they were already using site improve to audit and crawl the site for accessibility regularly and the score was quite high so the qualitative feedback validated the data that we had. We also, as mentioned, prioritized the feedback from this group in our Adobe XD mockups and in our JIRA backlog. We also, in the future, when we start building out committed to 508 testing pre-production so we have a QA team at Steampunk and their job is to make sure that I do smoke testing on all of our content and products before they go to production so that's something that we will test for in advance of the new Drupal site and long term what we're thinking and what the client really wants to do is rethink the entire content delivery experience. So this is a long term goal that's going to take years to achieve. It's going to extend way beyond the Drupal website when it gets there but as mentioned they've historically delivered their content through these PDFs and it's left them with a pile of digital content that they're not totally sure what to do with and so in the future the idea is to move away from that. The idea is to have that content when it's delivered be on the site more interactive and take a different form that is 508 compliant so it's again another example of how we really tried to design this site to be compliant from the start. But that still leaves us with a challenge. How did we solve the PDF problem? Because again we had 75,000 PDFs that currently live on the site. You have all of the content within them, images, words, data points that you need to then migrate over and this I should say is post audit. I mean they had already, before we started this project the client had already gone through their content and gotten rid of stuff and so the 75,000 was what was left and so there was still a lot to manage. And so we have some ideas about how to handle it in the future and again this is an ongoing project so these are just that ideas but here's what we're exploring as a way to make the content in those PDFs accessible and at least more organized to more users. We're considering making a PDF repository where all of the PDFs would live. Again currently they are all over the website. Sometimes you will have a PDF that is in the center of a PHP page and then there will be a URL to the exact same PDF in the left hand navigation of that same page and there's no icons showing that it's a PDF and so there's a lot of discombobulation and so we're considering making a repository of PDFs so that people know where to go to find that data and that content. We also are exploring ways to provide optional word and text versions per PDF. This is something that again came up from one of the user interviews that I did where that source said that for someone who is blind text files are actually a better way for Braille readers to consume content and so providing alternative formats for PDFs can be a good solution for compliance. As mentioned, we want to add icons that denote any non-HTML content so that people know what they're getting and our client also has staff on site who are able to give content in different formats upon request. We obviously don't want to over promote that because the idea is that we really want to make this Drupal site as self-service as possible and so it should really only be a last resort that people are reaching out if they can't get content in a PDF that they need but we are considering if we do that make this PDF repository an option for giving the content details for somebody who can possibly help. So in terms of what I've learned and some things that I hope will help you if you're in a similar situation auditing PDFs are a few things. As mentioned, I think it's really important to consider 508 from the start of whatever content you're creating whether it's HTML, PDF or another format and I would really encourage you to consider the best format for your content and I think that really starts with knowing what your users use. So for instance, if they are downloading stuff as PDFs often but you're offering CSV as the only download option, there's a mismatch there and so there is a time and place for PDFs but I would argue that it's not as common as it is often used maybe and so I would encourage you to be very thoughtful when you're building your Drupal site, when you're adding new content to your Drupal site to really think about why you are offering content in certain formats. That's also important because you want easy editing access. You want to limit ideally the amount of cooks in the kitchen with who can edit this content but you also do want to be able to make changes if you need to and as you heard already, editing PDFs is difficult to do. Once you are in the process of designing pre-migration you really do want to practice participatory design by collecting feedback from users who have accessibility needs so that you can make sure that you are building a product that is truly built for them. You also want to be testing for 508 compliance pre-production to make sure that you're in compliance and you want to make sure that you are doing regular scans and audits for compliance and there are tools that will help you do that. I keep mentioning site improve because that's what our client uses. I hadn't used it before and I do find it very helpful and user-friendly and it does crawl websites. It has a pre-determined amount of requirements that it's scanning websites for and so it will automate that process for you. And again, I sound like a broken record but what I've learned is that retroactively making PDFs 508 compliant is hard. Doing it with 75,000 is almost impossible and so then you have to really get creative about how you're going to deliver that content in a way that is more helpful for people. Having said that, like I said, there are times and places for PDFs and you can design them to be accessible from the start so that's the good news and there are some tips. Indiana University has several tips on their website for how to make PDFs accessible to screen readers using Adobe Acrobat Pro. We use it in my day job and so if you're working with PDFs, it's almost a guarantee that you will be working in Adobe in some form or fashion. So there are a few things to keep in mind when you are building PDFs to make sure that they're in compliance. The first thing is that you want to convert text that is an image to selectable text and you can do that using the series of steps below. You also want to make sure that you're denoting your headers so you want to add tags to the PDF that indicate the heading structure and you can do that below as well. You might have heard of alt text and adding alt text to images. Alt text helps screen readers understand what is happening in an image so it's basically an image description and so you want to add those where possible so that if your PDFs have images that people can understand what's going on in the picture even if they can't see it and to add alt text, you can take this series of steps here to add it. You also want to set the reading order. The reading order tells screen readers which order they should read content in for users and this again is something you might not think about. If you don't use a screen reader, it's not something that I had typically thought of but screen readers typically read from left to right and so if you set these parameters you can actually tell the screen reader which order they should read in to help the person using it. And finally, you can set the language for a PDF and you can do that through here. So again, it's a difficult challenge auditing PDFs for 508 but it's certainly not impossible and if you do want to build accessible PDFs there are ways to do that. Thank you. I think we're relatively early so if anybody has questions or wants to talk afterwards I'm happy to take them, yep. They don't click the content in the PDFs. Yeah, so for folks who couldn't hear, it was a comment about auditing broken links in PDFs especially long PDFs. Did you say it was a thousand pages? Wow, okay. Wow, yeah. That's, mm-hmm, yeah. Right, yeah, so that's interesting. I know that on my client side we do have somebody internally as a stakeholder who is focused on 508 compliance and so my assumption and hope is that along with the QA engineer on our side as we keep building that she on the stakeholder side knows what to look for but I think not every agency has that and so yeah, it's also a question of what are you even auditing for? I mentioned earlier that site improve will crawl your website to check for 508 compliance but again, that relies on you putting in the correct parameters in the first place so then it becomes a question of what are you auditing for? But yeah, no, it's a, and I will say too, I just expected that there would be some program to, you know, it's 2022. I expected there would be some way of crawling PDFs like you can crawl a website to automatically make changes as far as I know there isn't. If there is, I would love to talk to you but based on what I've heard, that's not the case and so again, that's why it's so important to design for 508 from the start because if you get into a situation where you have to retroactively edit these it could be a lot of manual labor as I understand it. Yep, go ahead. That's the hardest thing in government is changing the culture. I mean, you're totally right. This is a challenging problem but it's a solvable problem. The much harder part is getting people on board and in this particular case, it gets more complicated because I mentioned already that they don't have existing hierarchies or information architecture. They also have a lot of pages on the site that are managed by different sub-bureaus and there's no content standardization across those pages on the site and so everyone who owns the site as a director kind of has free reign to do what they want with it. That means that the quality is really different across those pages. Some of them are really good, some less optimal. There's no uniformity and so I can tell you that we are prioritizing taxonomy changes and updates as soon as possible. I know that our developer has said he wants to figure that out ASAP because it's really going to affect all of the ways that he builds out the site and so I will say, I think this is also, again, I'm biased as an HCD person because I work for a firm that practices it and I am a service designer but this is again also why it was really important for us to start doing these workshops with key people really early on because we knew that could be a problem. Actually, as I understand it, a prior contractor tried to do this exact project and if I heard correctly, it was something about not involving the right people at the right time and so basically they did six months of work, they got to a meeting with someone, that person was like, I hate it and the project kind of died and so we wanted to make sure that we were taking to use jargon, an iterative approach and that we were involving them from the start because the progress on that culture front is slow but it is possible but it's slow. Yep, yep. Yeah and our developer is also very familiar with Drupal roles and responsibilities and content types which I think is also super important. I imagine sometimes you get on these Drupal migration projects and the person isn't familiar with the CMS and so that can become a challenge but I feel like we're really well positioned to move that forward but 100% as soon as they start to build, that's where the tough conversations about content types and culture will start. Yep, there's, yeah. Yeah, so the comment was about Adobe Acrobat Pro having a built in accessibility tool and also being compatible with screen readers. My question about Pro is does it, like it will tell you what to change but you still have to go in and manually do it, right? Yeah, okay, so this is wishful thinking on my part. I was like looking for something that would just like make the changes for me but go ahead. It's like well it's gonna cost you 60 bucks an hour and it's gonna take 200 hours or hey, why don't you just build this on a content page in Drupal in 15 minutes? And when you start to do that, it's like oh yeah, maybe this is a better way. Yeah, and I don't wanna be, I mean that's a great point and I don't wanna rag on government agencies for just defaulting to PDFs because the reality is there are reasons why they do the things they do. I've worked with agencies before where they are legally, they are required by law to deliver content in a certain way and so it's not even necessarily their preference, it's what they historically have had to do but a lot of those laws were not written when content was as digital as it is now and so then it gets complicated so there are reasons why they do the things they do but again, if there's no order to things, if it's just kinda left to continue in that format then it can become a really big challenge and that's the thing is it's not that it's a hard challenge in and of itself, it's the scale that is the hardest part but yeah. Yeah, I remember, I mean the big one is if I might be mis-speaking but I think the New Jersey state website is still built and running on cobalt and that was a problem in 2020 when a lot of people were applying for unemployment and other benefits and the site kept crashing and they needed developers and a lot of developers working today were not born when cobalt was a thing really and so yeah, it's a very multi-pronged problem and again, it's a solvable problem but it can create a lot of headaches and a lot of confusion about even where to start because for a couple of weeks I was like how do I begin with 75 PDFs that I can't automate the process of making compliant, yep. Yeah, no, that's a great question so we took the attitude that we wanted to call out because that was the other thing, I mean my immediate thought was okay, 5,000 PHP pages, 75K PDFs, how do we even begin to account for all of that and so we took an approach where the UX designers that I work with really highlighted the key areas of the site and then narrowed it down to secondary and tertiary pages and then we had about six stakeholders in that card sorting workshop and what we did was we didn't want their answers to influence each other and so we were actually able to host a session in mural where we gave each of them their own mural board so they each had a unique URL to their own board in mural where they would complete the exercise on their own and then at the end we came back to talk about the results and that was again really productive just because again I think a lot of times in the government too you inherit these things, you inherit these massive websites, you inherit this technical debt and even if you, a lot of people I don't think stop to again think about the why even if they do there's not much they can really do about it until there's an initiative to change and so the opportunity for them to even think that way it might sound really basic but that's actually somewhat novel to them. Now having said that we definitely, my design team and I saw some people reverting back to old habits like we, like for instance we did not have any quantitative or qualitative data that the new section should be as prominent as our stakeholders wanted it to be and so then there are questions that you know there are always gonna be things about that and I think something I had to make peace with as a service designer is that ultimately those things are not my decisions to make I have to do the best I possibly can to give the best advice I possibly can and to facilitate that collaboration but ultimately the decisions are theirs to make and I think that's how it should be because we're not, we're consultants really we're not part of the organization and we will never know their culture as well as they do and so giving them that freedom to kind of play around with what they have and then hopefully empower them to make those decisions again, those workshops don't solve everything but I do like to think that the fact that we did them early on helped and the stakeholder workshop also helped too because again big agency, everybody has varying degrees of involvement with the content on the website but everybody's content will be affected and so talking to the key people on our project to figure out who we should engage when that only took about an hour or two and that was I think very helpful in terms of helping us make progress throughout phase one. There was a, yep. I believe it does and that's what makes it complicated too is that the requirements for those different file formats is different and so that's again why it's a challenging issue because you need somebody who knows that nuance of HTML compliant versus PDF compliant and things like that but I will say the fact that you would offer that PDF content in text files is, I mean that goes, stuff like that does go a long way but again it's not something that you would necessarily know to do at the outset. I mean I was like who uses text files but people do, I mean people do and so it's something that you have to seriously consider. Yep, yep. So in a perfect world you will have somebody, you will have a QA engineer who can go in and they understand what to look for. I know that's a rosy answer because not all of them have that expertise but I do know that it's something that we practice on another project. I was on at Seampunk, I know that we didn't deploy anything to dev before it had been tested by our QA engineer and I know that she does regularly test for 508 compliant so ideally your QA can go in and take stock of that but again that's a rosy picture because I know that not every organization has a QA person or that QA engineer doesn't have the 508 expertise. I will say that because governments have to be 508 compliant their websites are actually a really good resource for figuring this stuff out so when I was preparing this presentation the Department of Interior has a lot of really good content. Like I said Indiana University has a page where they talk about making PDFs accessible so finding reputable .gov and .edu sources for 508 compliance can go a long way but ideally you really want to have somebody involved who knows what to look for. Yep. Start with the most popular, the PDFs are never accessed and even if you can't say that all your PDFs are compliant you can at least say that 90% of the PDFs that are actually used are compliant start with those. Yep. PDFs that you put on the website because they're compliant. Set in Drupal, set up the media library as one of your media types PDFs set up to the workflow so when it's saying your reports that we've published it has to be there. Yeah, no that's super important. So the last point was about using the PDF setting in Drupal to make sure that everybody who uploads is able to and that it does pass compliance and I completely agree with the prioritization point you made especially if the thing is that if you're dealing with content at that scale you have no choice but to prioritize because again you can't manually audit 75,000 PDFs and even if that had been my full-time job for six months on this project I don't know if I would have finished and so you have to start by looking at what's the most popular, what's the most useful and site improve is very helpful with that because we saw very quickly that 90% of the most popular pages were in one section of the site and so I mean to your point most people don't even access the majority of content on a site and that's standard across the board. Once you go in you'll see very clear patterns about where people are going, what they're using the site for and then when you conduct your user interviews ideally what they're telling you should explain those numbers. They don't replace each other because I think if you just look at the data then you're making a lot of assumptions about why that behavior is happening but if you can interview some users to figure out why that content is so helpful then you can make a lot of progress because yes the reality is the majority of content is actually never looked at to begin with. Yep, that's helpful. Oh nice, wow. And so it's accessibility and it's accessibilitychecklist.com and what's the name of the podcast? Chatschat podcast, okay. Got it, yes so I attended so Dexter Castro is one of the hosts and I went to a webinar early in this project that he was doing on PDF accessibility and again I was looking for, I was young and naive and looking for a tool that was going to fix the PDFs for me and so he is very helpful. There's also a Facebook group that Dexter Castro runs that is specifically on PDF accessibility and I'm blanking on the name of it but if you are on Facebook and you search Dexter Castro PDFs or Dexter Castro PDFs accessibility that group should come up and people will post their questions about PDF accessibility and 508 compliance and that group is a good resource for those questions if you have them, yep. So TYTO is the name of your company and you run accessibility courses full day and half day, that's awesome. That's great, yep. Equidox, like E, Q, U, I, D, O, X? Okay, cool and they scan, they're another tool that scans PDFs for? So Equidox is like an automated checklist before you would upload to tell you what to fix. Oh, nice. Well and something you just said actually gave me an idea for something that you mentioned earlier which is just the governance aspect and the culture because if you're using a tool like Equidox that requires licenses then most organizations aren't going to want to give everybody a license and so then actually I'm wondering like if you implemented a tool like that in theory at least that could solve as long as you're getting the right people licenses to post that could actually cut down on giving everybody the ability to post. It's just an idea but then when you said that I was like oh, maybe that could help solve the challenge. Yep, yep, yep, yep, sorry, go. Exactly, yeah, right. Yeah, AI is notorious for especially image classification focusing on like the context instead of the subject and things like that and so you're right, it wouldn't even in that case solve all your challenges. So yeah, like I said, we have not solved the challenge of how to make every single 75K PDF compliant but there are ways to move it into the future where it is compliant and more accessible and then sorry, you were gonna say one more thing? Yeah, wow, so if you write a script you can actually like convert the PDF content into XML and then like make it compliant that way. All right, I think that's officially the end so thank you again for it, thank you again for coming. I really appreciate it, thanks.