 I always want to count down. Welcome to this afternoon's session on Content Accessibility in Drupal. My name's Simon Shackleton. I'm the director of Doghouse Agency, and we are very pleased to be sponsoring today's session. Presenting today from Solstice Digital is Philippa Martin and Danielle Schefler. So first of all, Philippa is a content writer and engagement manager with over 25 years experience in content writing. It's a lot of experience. Danielle is a product manager and business development lead for the role within accessibility as a practitioner. Without a 15-year experience, Danielle has developed accessibility practices in multiple organizations. Over to you, Gus. All right, so as Simon stated, I am Danielle Schefler, current product manager and business development lead at Salsa and former accessibility practice lead on a consulting basis. I started out with accessibility in around 2006 or so. I was a Java developer and at that time, there wasn't a lot of talk about accessibility, but I was working as a contractor for the federal government and just really interested once I found out that sites had to be accessible and what that meant. And that really just started me on the road to learning more about accessibility development, design, content, all things, and I'm very excited to get to share my knowledge with everyone. So, Phillipa. Oh, can you hear me now? Yes. Sorry. Okay, I came from a marketing comms background and ended up specializing in online writing in the early days of the internet. So I followed all the early usability testing by Nielsen and a bit later came across the accessibility standards that applied to content. In terms of writing, there's actually a lot of crossover too between writing best practices for usability and for accessibility, which means that often when you're making sure your content is accessible, you're also improving it for other people as well. That's me. So today we're going to talk about obviously the Web Content Accessibility Guidelines. We'll start off with a brief introduction even though I'm sure most of the people in the room today know all about WCAG. And then we're gonna look at the specific guidelines that cover writing and also the guidelines that cover multimedia. And Danielle's also gonna take you through some of the Drupal tools that are available to improve content accessibility. So in terms of WCAG, W3 sees Web Content Accessibility Guidelines and we're currently on version 2.1, provide an excellent and industry-approved standard for website accessibility. And accessible websites can be viewed and easily understood by everyone, which is why they're so important. So one of the things that we wanted to cover because I think a lot of you have probably heard A, AAA, or sorry, AA, AAA and aren't maybe entirely sure what that means. So level A is really the smallest amount of effort that you can do and really while it has an impact, so we certainly don't want to negate anything there, it does have the lowest impact on the presentation side and backend and just business in general for your site or application. Level AA, which really a lot of people hear mostly about because as Phillip has said, while WCAG 2.1 or you might hear WCAG 2.1 is really the latest standard while there is 2.2 and 3.0 coming up soon. 2.1 helps with responsiveness and just really more disabilities in terms of cognitive motor really takes a look at that piece 2.0 and 2.0 AA I should say is really where a lot of the regulations across the world are really focused and so level AA, just so you understand what that means really has a very high impact on users, whether it's WCAG 2.0 or 2.1 and of course has the higher impact on that presentation layer code, all of those things and it's why a lot of businesses choose to focus there. Some of it is because it's a regulation but of course really we're not doing this just because it's the law, we're doing it because we wanna make sure that everybody has an equivalent experience as much as possible. And then the other third level is level AAA and those requirements and guidelines we will talk about later on as well, but they tend to be for very, very specific user populations, some of those and it goes really more into development as opposed to the content side that we're talking about today can be very difficult to adhere to, W3C even mentions that themselves, this is an hour language that's actually from W3C and so with that, that is the reason why you don't see as many asks for that or why there isn't as much chatter I should say in the global community about AAA. So instead of just talking about these different levels it's good to give examples. Again, we have the user impact on the left side and then on the right just giving a few examples of how things kind of go from one to the other. So we'll talk about this guideline 1.3.1 info and relationships later on in the presentation but just generally it's saying that there should be some sort of structure right to your page and to your site. I say page because accessibility is reviewed per page it's not done on a whole site level you do have to look kind of template by template and so with that it's saying you have to make sure that you have headings there's navigation and a footer you wanna use bullets and lists those types of things. So that's really the first part and that's level A when you get down to double A that's when you're saying things like 2.4.6 for headings and labels. So it's not just that you have a heading or that you have a label it's very purposeful it's descriptive it really has a bit more impact. And then even though AAA might be talking a little bit more about paragraph text and things like that does apply to other pieces of the page as well. So could apply to headings or things that are in bold with the list, et cetera. But making sure that the reading level is at an appropriate level. And Philippa will explain a little bit later what that means but you can see kind of how we go from level A to level AAA based off of what those standards and guidelines are. So I will turn it over to Philippa to get us started about some of the specific guidance. Yeah so looking at the first level A one in terms of the WCAG it's 1.3.1 and Danielle had mentioned it before the actual specific guideline is that information structure and relationships conveyed through presentation can be programmatically determined or available in text. So from a text point of view it's things like ensuring that each heading looks like a heading. Obviously that comes across into design and front end of course. And also doing things like when you're using lists making sure that they're the proper ordered or unordered lists using description lists to enter into the WYSIWYG editor with your private start and end tags as well. So the next one WCAG 1.3.3 sensory characteristics. So instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape size, visual location, orientation or sound. So what exactly does that mean? Cause right, that's a whole lot of information there. So basically it's saying, you know don't use something like, you know click on the chime in order to move to the next page or click on the green arrow to go to next or go to the middle of the page to do X. It's the fact that not everybody will have the ability to maybe understand those directions because of a cognitive disability might be a visual disability because they, you know aren't able to maybe see the content as well or at all. It could be that there's an auditory issue and so they won't be able to hear the sound. So it's something where, and we see it on form fields, right? Where a lot of times, you know instead of right using say just a red outline for an error, we also have text that displays what the error message is. And so it's not saying that you can't, you know use some of these characteristics. It's just that they have to be in conjunction with something else to really help, you know everybody be able to, you know operate the page or to get the information that they need. Back to me now. So the next one is page title. Web pages have titles that describe topic or purpose. So this is WCAG 2.4.2. And basically what it means is that you need to make sure that all of your page titles have that unique and descriptive title so that if someone reads that page title they have a good understanding of the information they're going to find on that page. The good one about this, what I mentioned that a lot of these WCAG are actually also good web best practice anyway. So with page titles, you have the added benefit of actually providing people who are scanning readers. Obviously if you, you know they scan the page title, that's a very important element. People will usually first read the page title. And the other thing is obviously a good descriptive page title that's also going to really help with search engine optimization. So here we've got that as I said sort of that win win where you are making your content accessible but also providing benefits to all users. The next one is WCAG 2.4.4. And that's around link purpose in context. So with this one, it's a bit of an unusual one. Danielle and I have spoken about this a few times but with this one it says you can use click here if you've got context around it so that people are aware what they're going to click on. However, with this one there's another one that's the next level up from A which is so easy to do with this one. So I would even recommend although this is level A you can meet level A by just ensuring you have context like you may want to read the article on blah blah blah by clicking here. There's an easier or a better way to do it as well. The next one is labels or instructions. So this obviously largely goes to forms. So you wanna be able to have instructional text at the beginning of the form so that people are aware what they need to fill in and also instructional text for each field so that they are aware what fields there are what are the required fields, et cetera. Okay, so we're starting to get into level AA now. So WCAG 1.4.5 images of text. So if the technology is being used can achieve the visual presentation. Text is used to convey information rather than images of text except for the following customizable or essential. So things that are considered essential are things like logos. Really hard to use text as a logo. And so W3C, the guidelines understand that. The thing is that we know that there's CSS it is pretty easy to make sure that we're using text instead of an image but the reason why we really don't wanna do this is for multiple reasons. Some of it is SEO. Some of it is because of course there's responsive design and different devices. We know that images can generally be resized based off of the screen but if there's text in that image or as the image itself, not as easy to resize that. There's issues with translation. There might be the case where somebody's browser isn't loading because of a slower internet connection or something's going on and they aren't able to get that image to load at all and it might be important content. So that's really where we want to make sure that we're just using text if we can. And the next one is headings and labels. And this one 2.4.6 is just to say that they're descriptive that they specifically describe the topic or purpose. So for example, and this is where we can get, there is a little bit of subjectivity here. Is this heading descriptive of the whole page or of the section of the page? So there is a little bit of subjectivity there but obviously the main thing is that when you're thinking about headings for your page that you're really focusing on trying to keep them nice and short and succinct but also making them descriptive. And the same for labels. So for example, labels from forms, et cetera should also be really descriptive and let it make it clear what the purpose of that heading or that label is. So the next piece is around images of text but this time no exception, right? So again, when it says no exception there really is an exception. There's still an exception when it comes to logos. So making sure that if you're not taking this out of context because of that but in the piece for regular images of text where we say at a lower level it does say that if it is able to be customized, it's okay. In this case, it is not. When we get to WCAG 2.4.9 for link purpose, link only this is exactly what Philippa was talking about with level A. So because of the fact that with screen readers a lot of times they can or not a lot of times they can pull out a list of links to help people navigate a little bit better. If you have a whole bunch of click here and read more not only is that generally not the best usability because of ambiguity but also I'm sure all of us, right? If we were using a screen reader it would be very confused if we're listening to links and pulling things out and just hearing click here, click here, click here, read more, read more, read more, view more, view more, view more. And so if you've seen some of my talks previously at Drupal South and Drupal Gov you know that I've given some methods out to help programmatically to make sure that we can take care of that. But again, also from just a content perspective and writing in a WYSIWYG editor, et cetera, or just having a content editor or author who is able to assist in creating some of those or some of that link text or suggestions really wanting to make sure that everybody's getting full context. I think this is where Oh, sorry, go ahead. I'm sorry. And so this is where I mentioned that it's really easy with this one to go from that level A to AAA for a content editor just to write in that very specific. And that's why I said I have, you know, literally for 15, 20 years I've been trying to, you know, single-handedly get rid of click here but they're everywhere still. Although they are becoming less now, which is great because it is such an easy one to change. It makes it so easy for people who have their websites to get them from A to AAA at least on those links. And so it's a very easy implementation. And our next one here is 2.4.10, which is section headings. So it's a little bit more, I guess, a higher level of compliance than the early one that we talked about with headings and labels. But it's again, making sure that obviously, as well as those titles being descriptive, that you're actually using the headings to organize the content. So that means, you know, you might have a page and you might have five H2s and a couple of H3s. So those next level down of subheadings. And it helps to organize the content. And again, this is another one where you get that win-win because there's been a lot of great research, even some recent ones by the Nielsen-Norman group. I'm sure that any people listening who are into UX or design will be very familiar with Nielsen-Norman. But basically, they've done some, a lot of research in the past and some more recent ones on eye-tracking. And it's quite clear that most people, because they're scanning a website page, they do scan those headings. So if you can break your copy into those meaningful headings, it will really help the users. And again, helping users, every user, and also making sure that you get that AAA compliance for accessibility. The next one is 3.1.3. And this just relates to unusual words. So basically, if you've got a lot of jargon or very text-specific words or other words that are specific to an industry, that you have a way that the person can get a definition. So that may be a link to a definition or it may be having the definition within the content itself. And again, generally for any form of writing, any writers in the room will know that we're taught from very early age in terms of corporate writing and writing for the online medium to make sure that we try and get rid of those unusual words and use some of the simpler words so that anyone can read the content. Similar abbreviation is very same. A very similar thing that if you have an abbreviation there that you either have the expanded form or that you have a meaning of it or definition of the abbreviation available somewhere as well. The next one's a really interesting one. 3.15 is reading level. So with this guideline, it's actually saying that your reading ability should be lower secondary education level, meaning that anyone with a lower secondary education could read and understand your content. And obviously that's quite low. I'll just pop to the next slide. And just in terms of how to do that, well, I'm gonna come back to some of that reading level at the moment, but just, I also wanted to, before we move on to that, obviously talking about the WCAG guidelines, it's good to have an accessible version because obviously there's quite a lot of detail. If you actually go into them, there's a lot of information on each of these guidelines that we've covered. But what does it actually mean? What's the easy or the accessible version? Simply choose your page titles carefully. By carefully we mean writing descriptive, succinct but descriptive. Write contextual links instead of click here or read more or more information. Use descriptive headings on your pages to organize copy and to show hierarchy. Those are read out, that hierarchy is read out by screen readers, so that helps people also identify the organization of the copy. Keep instructions and error messages clear and easy to understand and where you need instructions, do them in the form fields, make it clear for people what they need to fill out. And then the second one, back to this writing for a lower secondary school education. And in fact, although WCAG says lower secondary, so that would be sort of year seven to eight, the Australia's Digital Transformation Agency says year seven. So a lot of people will be saying, how do I know if what I've written is year seven or year 10 or what it is? There are actually a lot of tools, some free, some not. This one that I've got here is a free one. So Danielle's driving, she'll just open that up for you. And as you can see here, you can put in some content. This is some, you know, when we prepared earlier. And so have you clicked the readability there? Yes, it's down here is what it had showed me. Yeah, I actually can't quite read that one on my screen. But when you click the readability, it actually tells you what year level it is. And so therefore you can sort of see, okay, this is what year level this is. This is too high. So I need to start changing my copy in a way to make it more accessible. So that can be done simply by, in this case, I've got, in this example, I've got one that's got, oh, here's our readability, sorry. One, just cutting one sentence into two. So it's as simple as that, that's all I did. And it can bring it down significantly. Okay, just back to the presentation now. In terms of how to keep that reading level as low as we can, it's really a matter of doing things like choosing simpler words, keeping your sentences short with a single statement per sentence. So as I said, even splitting one longer sentence into two or three sentences, using the active voice, avoiding jargon, which as I mentioned, also is one of the WCAG guidelines. And also making sure your writing is well structured and to the point. Now, obviously all the things on here, we could do a whole presentation on those, but that's not what we're here for today. So I will move on and just show you some of the quick examples and let you know that you can actually get quite a long list of replacement words. So this is a very quick example of, for example, approximately can become about, endeavor can become try. So this is getting rid of some of those longer words and using shorter words instead. And on the government style manual, which is used by obviously governments, but also most corporate organizations will use it within their content areas. And you can find a whole list of words that are sort of longer, a bit more verbose and how to replace them with those easier words, which will help your readability as well on the reading level. Okay, over to Danielle again. All right, so we're gonna talk a little bit about multimedia in general. I know we have a little under 10 minutes. So going to go through these very quickly, but WCAG 1.1.1, non-text content, I'm sure a lot of you know this as alt text. So we wanna make sure that there's descriptive alt text for every non-decorative image. So one of the things, for example, we see in manual testing is, or I'm sorry, in automated testing is, yes, you have an alt tag, no, you don't. This really is making sure that in order to pass, it's something that's very descriptive. So someone who maybe can't see the image or the image isn't loading, that they really understand what is in that particular image. And we do show that alt can be empty for decorative images, right? Because sometimes there are images that are just there for visual appeal. And then the other thing to mention with this is that we really need to make sure that charts and graphs have a long description or if it's something very basic, it can have alt text, but just making sure that you're not trying to have that chart or graph stand alone and provide the information solely that way. Because again, if it's not loading or if somebody can't see it, then or maybe there's a cognitive disability and maybe they're not sure how to process the information, having something to describe it is extremely important for providing that equivalent experience. So audio only and video only. I know this is a lot of text information. So this is really to make sure for everybody who wants to go back and read it after we're finished. But essentially audio only, it's just making sure that there's something available so that people who maybe can't hear it, understand all of the text, all of the music, all of the sounds, that there's some sort of audio description available for them that really kind of tells the story of that media. And then the same thing in terms of video only, we wanna make sure that there's a transcript of what's happening when it's audio and video together. Again, we wanna make sure that there are sounds. It's clear who's speaking. It's one of those things where you have your sights and you closed your eyes, for example, that you would understand what was happening on the video or if it's audio, if you had something that you wanted to access but your computer was on mute, if you don't have a hearing disability that you would be able to understand. And again, same thing with cognitive disabilities, et cetera, wanna make sure that everybody is able to accurately process the information. So captions, I think most people are aware of these, even though they come, I'll say out of the box, right? And a lot of third party providers, it is still extremely important for whoever is in charge of those videos. So if it's a video editor, if it's your content person, whoever it is, making sure that those captions are accurate. I actually had tried to turn on our captions through Google as we started. And I think half of it when Simon was speaking was incorrect. That is exactly why you need somebody to go back and make sure that those captions are accurate. Again, this is talking about a full text transcripts and audio description, just very quick story that I wanted to mention about this. I actually found a good example as we were creating this presentation of The Lion King for those of you who have seen it in the beginning when Rafiki takes a Simba from his mom and goes to show him to the rest of the animal kingdom. Some people might be like, okay, Rafiki picks up Simba and shows him to the rest of the animal kingdom. That is not right when an audio description or media alternative does. It really was talking about how Rafiki picked him up, how he walked over to the rock ledge, how he lifted him up, that the zebras had their hooves going and that the antelopes were bowing down. And all of those details and those sounds and everything else are extremely important to put into the content. And so again, that's why as we talk about some of the Drupal tools, it's super, super important to just keep that in mind that all of those tools that we have are not going to find some of these things. And so it is very important from the content side that those are included. So again, this is very similar. This one I wanted to touch on very quickly is extended audio description. I did put an example down here for everyone to read at a later time, but it's essentially just an example of a professor who's sketching and explaining a physics problem. And so having something available where, because he's speaking so fast and he's drawing that he erases and he starts the next thing is making sure that there is a pause in the video and that there's more description and more audio and that somebody who needs it is able to really gather all of the information. And then it started again. And so this is part of AAA, but right there are instances where this is needed as this example shows. And then this one, the media alternative, it's not just a transcript. It's not just an audio description. It's really just full play by play of every visual and auditory piece that's going on in a synchronized media. So it does become very, very long. But again, remember that there are specific user populations that might need this. So where are we in Drupal? I know Phillipa and I talked about a lot of this, but I think it's really important in terms of the content and understanding that piece to understand how everything comes in from the Drupal side. So this module, if you have not heard about it, is like one of my absolute favorite accessibility modules. It's called Editorially. And again, this is something that is automated. So it's not something again that will cover everything manual, but it is very important and very useful for content authors and editors. After they go in to add or edit their content in Drupal, what ends up happening after they click on Save, they get similar to what is a preview button. And then they end up getting either everything passes, they see alerts, warnings, maybe a little bit of both. And then very, very, very specific information here. And so this is really helping everybody understand exactly, not just what the problem is, but why, but really helps further our accessibility education, which is super important team. So I think it's just really important that this is coming out in the community and that as we get to D10, hopefully as we get even further than that, that we continue to have more tools like this. It's not just about, or I'm sorry, it's just about content though. It's not trying to replace your wave or, some of you might use acts from DQ by itself. Some of you might use Lighthouse, which has acts as its core. It is not meant to replace that. It's just, this is very, very specific. And then also, as you can see, there's even pieces here that talk about, here's the heading and, or sorry, here are headers. And then goes through just step by step, all of the different pieces. One of the things that I did wanna show as well is all of the different kind of tests and checks that it does. So we can see that it follows that info and relationships, non-text content. It's looking at some of the other things we talked about with links. But again, I'm gonna stress it again as if I haven't said it enough that it is very, very, very important to remember that this is automated and that, yes, it will check your alt text but it won't actually check that it's completely accurate and super helpful. Same thing with captions, things like that. And so again, I truly see that there's been a lot of work with editorially. We're going to see I think even greater opportunities within this space, within D9 as well as D10 and there is a lot more accessibility work that is happening within the community. We're not trying to make more automated tools. There are so many out there. So know that if, especially from the content space, you don't see three, four, five more modules coming in with editorially, that's because right at a certain point, again, there's only so much automated testing that you can do before you have to do the manual piece. But this is a module that I would pretty much recommend. Everybody, if you are working with content authors and editors or personal site, whatever it is that you focus here. And then the last one to talk about before we get to questions, just very, very quickly, is site improve. I think a lot of you might know site improve as an SEO service. They do a lot. You can see that they have page analytics here, but they do also have an accessibility piece as well. Please note that for this site improve module to work, you generally have to have a subscription to site improve as well. So it is a little bit limited and why I would suggest more of editorially. But other than that, just really quickly to point out, you can see broken links. They even do misspellings, different types of errors. And then you can see SEO here as well. So keep looking out in this space. And last thing is if you would like to contact me or Philippa or reach out to Salsa, here's our contact information. I will just leave this up here for 30 seconds. And I think we are ready for questions. Fantastic presentation, guys. Very consistent number of attendees, which means that obviously everyone's very, very engaged. There's a lot of insightful information in there. So congratulations, well done. Guys, any questions? Just throw them to Q&A portal. We've had a couple of questions come through. The first one is from Robert Tran. So what is the best practice for dealing with accessibility on images and graphs? So I know that's quite a talk about the subject. How do you make graphs and charts visible? Yeah, who I could probably do a whole presentation on that. I think it's really just making sure that the information that you have is in the right formats. Sometimes alt text is not gonna be enough when it comes to some of these charts or some of these graphs. And you might have to have a whole paragraph of text or something right where there's a, somewhat of like a transcript for your graph and your chart in order for people to understand. So I hate sometimes using the phrase, it depends, but in some cases it depends on how much information you have. But if a long description, if you feel like, oh my gosh, I'm gonna need five paragraphs to explain this because it's really complicated research or something of the like, then there are options of the transcript. Is it something where you make a descriptive video that has captions and do you need an audio description instead? It's really just making sure, let me back up. It's really all about making sure that users can get that information in an equivalent manner. So any of those options will work. It just depends on the complexity of what you're working with. Yes, I mean a lot of modules, especially in Drupal these days, obviously have the ability to review or look at the actual raw data set. So do you think that's generally a good accessible way of actually presenting data visually people wanna engage with the graph, but really impaired people can't engage with the graph. So is presenting the raw data accessible or do you have thoughts around that? Generally, yes. Again, it's kind of hard to answer without being able to see every individual case. But yes, generally that should work, but it varies. Yeah. So just on, I guess the WCAGs, what 2008 I think the guidelines were initially published. So doing my quick math has about 13 years ago. The Australian government, my understanding of the Australian government has used WCAGs to sort of inform policy around the Disability Services Act. So over the last 13 years, how has WCAG evolved as a standard? Yeah, I think that's a great question. So I think the good thing is that, we've seen 2.1, right? And as I had been able to throw in a little bit is that, it really opened up for a little bit more of thinking about mobile and thinking about more disabilities around the cognitive piece and a little bit more about motor. So 2.2, I know that they keep pushing it back, but should be available hopefully early next year. And so we're starting to see even more changes there. There will be a huge change in WCAG 3.0, those standards are already starting. You're going to be getting away from like the AAAA, AAAA. It's not just necessarily going to be, you pass, you fail. There's going to be a whole restructure, which I think will really help open up accessibility. And in terms of the understanding and the education, you don't have to be like a developer that understands every single piece of how a site works in order to focus on accessibility. And I feel like that's where we have issues now. Or I mean, look at how many standards that Philippa and I talked about today, right? There's so many. It's really kind of breaking that down a little bit into a much more understandable way because the disability community is not only getting a lot more focused, but I think a lot of people are really starting to understand that accessibility isn't just for disabilities. I mean, so many people in the world, like your big numbers on the iPhone, right? Or people who use captions when they're say working out at the gym, right? And they're watching a video or whatever else, they're useful for everybody. And so we are seeing that really big shift, which I think is great. I'm actually really excited. And I was just gonna say on that as well, I mean, there are things that, for example, that reading age, there's been research that's been shown that even people who are PhD educated, they still, when they're online, enjoy reading things that are written for that year seven, year eight age because it's easier and faster. We're often, you know, rush online. It's just the way things are. And I also wanted to comment in terms of how it's changed. I think it's also important to note that although it has changed a lot, there are also some things that have been in there from the start. You know, there are guidelines in terms of content that as I said, I've been following since the early days. And so I think there is a lot of stuff that has changed and that has grown, but there's also stuff that has remained consistent throughout that time. And that's a testament to how important it is to make sure that the content and other areas, of course, but from my perspective, content is meeting those. I'm also aware that, oh, sorry. I'm also aware we don't have much time left. And just in case we don't get another chance, I also wanted to thank everyone for coming along and being involved in this session. You know, obviously accessibility is something that Danielle and I are really passionate about. And my focus is more the content accessibility. But yeah, I wanted to thank everyone for coming along and to thank also Doghouse for being the sponsors for this slot as well. So just in case we get timed out. Well, it's 38 seconds left, I'm not quite sure. We can probably try on the question, but probably not. If you want to, so just quickly, writing accessibility content. So you've touched on SEO before. So how does SEO relate to accessibility? It doesn't necessarily relate. It's more that one of the things in 15 seconds. So, you know, one of the examples I gave was the page title. A page title, if it's really descriptive, it meets accessibility requirements. But if it's descriptive, it's also going to help your page come up in a Google search, because if that's what the person's looking for, it's a good match. Oh, one second. Fantastic. And I think we're out. All right, guys, that's what we've been extended. Thanks again. Very informative session. There's a lot of information in there. And, you know, these presentations do take a fair amount of time to put together. So, you know, thanks for sharing. Thank you. Thank you. Thanks. All right, thank you, everyone. Have a good rest of the conference. Bye.