 Hello, everyone, and welcome to the roundtable session. The roundtables at today's conference are brought to us by our sponsors at AMAZEE IO, Previous Next, Skipper and Pantheon. And speaking in this session today is Danielle Scheffler, taking us through incorporating accessibility into your project lifecycle. And this is one that I know that our team is very keen on hearing and looking forward to. So I'll hand over to Danielle now and take it away. All right, thank you, Dave, really appreciate it. As Dave said, I am Danielle Scheffler. I am the accessibility practice lead at Salsa Digital. And I'm very excited to speak with all of you today, both as part of this lightning talk as well as the roundtable. So in terms of what we're covering, I know that we are looking into talking about how accessibility fits into the project lifecycle. But there are several topics that we don't really get into sometimes in terms of, A, making sure everybody's aligned on what accessibility actually is, making sure we're talking about how the fact that yes, accessibility is the law. But we also want to make sure that we're thinking about it as accessibility first, focused on empathy, and also talking a little bit about terminology. A lot of times, we don't necessarily talk about what are the appropriate terms when we're talking about people with disabilities as well as people that don't have disabilities. And then I promise we won't get into the meat of talking about accessibility in the project lifecycle as well as going into just some key resources that hopefully you all will be able to take away with you. So in terms of what you need to know before you get started, if we look at this definition of accessibility, I don't usually read things directly from the screen, but I'm going to do it this time. It's the degree to which a product, device, service, or environment is available to as many people as possible on as many devices, so visual browser, screen reader, mobile device as possible. Notice that disabilities are not mentioned with this definition. A lot of times, right, that's where we're very, very focused, but really accessibility is accessible for all. It's making sure that we're trying to be inclusive. It's making sure that we're thinking about as many use cases that we're not focused on one piece of the population or one part of the population that is really for as many people as possible. And so it's something to focus on as we're designing and building sites and applications. So I talked a little bit earlier, gave a little bit of a teaser that we'll talk about how empathy is important. So the first bullet, I think shocks people a little bit, but we do have to admit that the world is still a bit ableist because we all come from our experiences. It's not intentional, you know, the majority of the time, but it is true. And I even think about something, for example, that I saw on LinkedIn last month and it relates to presentations. It's very fitting where somebody said, I really hate that people, you know, sometimes just read directly from their slides. I mean, it shows that they're unprofessional. It shows they don't know what they're doing. They're not prepared. You know, in some cases that might be true, but there were a lot of people that said, I agree, you know, it's not good. You know, you should just walk out of the session. I think somebody said if that happens and somebody finally came in and said, I know this is probably not intentional, but that actually is a bit ableist because you have to remember that not everybody who's attending your session might be able to see it well. They might not be able to see it all. They might have a cognitive issue. They might have a learning disability, you know, whatever it is. And so giving them as much information as possible does not necessarily mean that somebody is unprofessional or, you know, there's something wrong. And so it's really just making sure that we're thinking about things from that lens. The other piece, empathy, allows us to try on the emotions of other people without having to be in their shoes, excuse me. It is admittedly impossible to really understand if you don't have a disability. I have an invisible disability. I didn't know what it was like to have a disability until, you know, something happened to me that maybe have a disability. It doesn't mean that you can't empathize. It doesn't mean that you can't, you know, incorporate accessibility well. It's just, again, going back to that point that I made, you know, 30 seconds ago that we just really need to remember that we are shaped by our experiences. And that we really have to, you know, make sure that we're open to know that we need to learn and to grow. The third one, very important to me especially, people with disabilities are not inspirational solely because they have a disability. I actually did not put an example of what I'm about to talk about because I didn't want to, you know, spread this. But I think a lot of us have seen those memes, right? Where maybe somebody who has, you know, say two prosthetics for legs. And then it will say in big letters, like, what's your excuse? I mean, when I go run or when you go run or somebody else runs, right, they might not be told, oh, you're an inspiration just because you went outside and ran. You know, maybe if you're going and running like 100 kilometers, like, yes, okay, that's inspirational, right? But just going out and running might not really be inspirational because it's just a daily activity that we think about. Same thing, you know, somebody's not an inspiration just because they ran, you know, for example, because they have prosthetics. So thinking about things from that perspective, start with just enough accessibility as we know. I'm sure a lot of you have seen this, there's a lot to know. There's a lot of guidelines. There's a lot of standards. So, you know, we might be talking about things today at the round table or I might be mentioning things here that you weren't aware of. I'm so happy, you know, that we can all learn together. It's okay to start with like just enough, but then focus on learning more, right? That's how we get better. It's how we evangelize accessibility. We're just really making sure that we're focusing on those pieces. So along with that, we know that WCAG 2.0, AA is the law. WCAG 2.1 opens up a lot of other guidelines for mobile responsive, you know, cognitive plus 2.2 is coming out sooner than we may think. And 3.0 is actually being in discussion or sorry is in discussions now. So there's a lot there. So let's kind of move ahead and not just do what we need to. It's great if that's a starting point, but just thinking about going, you know, another step. And then accessibility overlays. I could do a whole session on this. I actually have before, but if you don't know what accessibility overlay is totally okay. I have an example, you know, here of this little icon. You'll see them a lot of times you click on them. It comes up with something like this. It says that they can make your site accessible with one click. If it's too good to be true, it really is. And that is just because of the fact that they actually often make things a lot more difficult for people with disabilities. They read over screen readers. There's a resource that I have later on in the resource section where I think there are 567 of us now who have signed it. It includes accessibility consultants, experts as well as people with disabilities that say that these are actually doing more harm than good. I am asking, please, if you are building a site to not use them. And if you know somebody who is using them, you know, like I said, I have some resources in the resources section to explain why it is not the best idea ever. And then very quickly to, you know, get into the rest of the presentation, do's and don'ts of terminology. I'm sure everybody here is unique and special, but there is no such thing as specially abled. If you don't have a disability, it doesn't mean that you're normal. It doesn't mean that you're specially abled. It just means that you are a person without a disability or you're non-disabled. Same thing with just in general, we always think about the person being the focus. It doesn't matter if they have a disability or they don't. So persons with disabilities, not the disabled. Same thing. It's somebody who is intellectually disabled. They're not mentally handicapped. There isn't something wrong with them because they have a disability. So I know I spent a good portion on that, but I think it's just really important, you know, before we even get into incorporating some more of the technical and the tactical pieces that everybody understands a lot of that piece or at least we touch on it first. So talking about accessibility and projects. So this is assuming that most people are doing agile. And so even though we will talk about discovery and development and kind of going from there, we will talk about ticketing and iterative process, et cetera. So the first thing is determine what accessibility guidelines you will follow. I know sometimes this is dependent on clients, et cetera, but that's the first thing. It's making sure that you know what those guidelines are. So is it WCAG 2.0? Is it 2.1? You know, are you meeting, you know, AAA for some reason, which is, you know, very difficult sometimes to hit. Do you need to meet authoring guidelines, et cetera. Make sure that you identify an accessibility expert. I know that sometimes with with procurements, you know, that can be really difficult to do. Again, something is better than nothing. But we really want to try to focus again on accessibility first and making sure that somebody who really has that deep knowledge is on the project. Define your tooling, right? Just like we would do with any part of the development process. So that could be wave. Some of you might actually know acts that's part of Google Lighthouse. Andy is one that's out of the U.S. that I absolutely love. It's open source part of the Social Security Administration. There are command line tools, Pali, so you can actually incorporate that into your dev process. So that, again, mostly covers manual might only get about 30% or so of issues. But again, that's yet another check for you. And then making sure that you're hitting on your manual testing. So that's keyboard, mouse, screen reader. So whether that's voiceover, JAWS, something else, just making sure that you have kind of those tools in your toolbox. The next piece is making sure that everybody is aligned on what your best practices are. So at least having the knowledge that they need around the guidelines that you're going to follow and what that means. So when I say everyone, I mean everyone. So right, of course, your accessibility expert, your PMS, your BAs, devs, designers, QAs, UX, usability might have forgotten a group of people, but just in general, making sure you're focusing on that. And then also educating the client on content accessibility, right? We know sometimes projects start to shift a little bit because of content. So because there's a lot to write generally when you're, you know, redoing a site. So making sure that you're starting very, very early in that education process. So if they are writing content, if they are rewriting that those best practices are already being thought of and in place. So design and usability. Yes, you can actually do accessibility in design and do some testing. So the first thing is making sure before design even happens, right? Generally, your designers and your UX experts talk, but you want to bring in, sorry, an accessibility expert as well. And usability expert makes sense too if they're doing testing. You then want to have the accessibility expert actually do an iterative review of the designs. So, you know, again, trying to use tooling when you have something that's not interactive, not the easiest thing. But at the same time, right, there are ways where you can, you know, of course, test color contrast. You can say, well, if we built it this way, you know, there's a risk, it's going to be very difficult. Can we try to design it in a different way or an accessibility expert might say, hey, developer, you know, X, we can actually design this and develop it, you know, in this way and here's some code and we can get that ready. So just making sure that that's happening as early as possible. And then hopefully you're able to do usability research and do usability testing on your actual designs. So making sure that we're including people with disabilities in the actual testing. So in terms of development process, I don't think I'm going to surprise anybody too much, but really just making sure during backlog refinement that acceptance criteria, you know, implementation criteria and solution direction and accessibility testing criteria are added. And when I say like ACs and solution direction, I don't mean like the typical pieces, right? I mean related specifically to accessibility. They should not be like way down, you know, down in QA and part of your UAT. It should be in the ticket as part of backlog refinement to make sure it is incorporated from the very beginning. At Salsa, we have a testing checklist. It's open sourced, have a link to that and the resources as well. We use it to make sure that all of the appropriate tests are covered, you know, having developers run that accessibility check. Hopefully they'll be able to do that right based off of the facts that we already talked about best practices with them in discovery. And then again, making sure that tests are run as part of the QA process. So testing, if you're using a design system, it might be on the components first, might not include the site content. So it doesn't mean that that's the only testing that you're doing. But again, that's at least putting, you know, those pieces in. And then in terms of final UAT, right? Just like we would do, you know, regression testing and final UAT with, you know, our QA process. We want to do the exact same thing with accessibility as well. So conduct a final audit on your components, your templates, you know, testing full pages. If your site has real content, that's great. But at least make sure it has representative content. Again, add tickets to be completed in UAT. As we know, not everything actually gets done in UAT, right? But that's where we start creating an audit document or an audit report. Again, have that open sourced as well where that link is in the resources. And then providing the report to the client. So I know that's a lot of information to cover in 15 minutes. I can tell you that I can talk about this for hours. If any of you contact me, I probably will. But that is really the main piece that I wanted to talk about today. And we'll make sure that we include, you know, all of these pieces in the round table as well and what you're interested in. But I know that I've gotten to our 15 minutes and wanted to point out for some of the resources. WCAG guidelines, the terminology that I talked about with disabilities, the overlay fact sheet. That's where I was talking about those accessibility overlays and why they're not the best idea. This explains why. I have the accessibility blogs. These are the ones that I've written. Of course, there are many others. But in regards to some of the pieces around empathy and barriers and testing and all of the accessibility gamuts, I should say, is included there. And then the starter kit that I was talking about that has the report template testing guidelines. We have how to write content for web accessibility. Those are all in there as well. So before we get to the round table, just wanted to see, Dave, if we have any questions at all. The live Q&A is open. And we do have a question here from Ian Humble. And so that question is, what important accessibility issues are on your radar that can't be checked or evaluated by online tools such as Wave or Axe? Yeah, that's a great question. And there are actually a lot, even ones that we think are able to be evaluated can't sometimes. So for example, we even know alt text. That seems like a really easy one that can be tested. Is it good alt text? Is it descriptive? Things like that cannot be tested. So even though something looks like it passes, it might not actually pass. There are things, especially this is a really big one on my radar. We see a lot of read more and learn more links. So something that a lot of people don't realize, understandably, if you don't use a screen reader is that screen reader users can actually pull out lists of links or headings or write major structural elements to be able to navigate through a page. And if there is not anything that gives that context, whether it's on the screen or through CSS, if somebody pulls that out and say you can't see the screen, all you hear is read more, read more, read more. Or learn more, learn more, learn. There's no context to those. I will say, and I hate doing this because I feel like I'm making a plug for myself, but I actually did a session last year at Drupal South. That was actually on the difference between automated and manual testing. And so in the resource link that I have in terms of, you know, blogs, et cetera, there is a link to that presentation. And again, I say that not to, you know, avoid your question. It's just it is one of those things that I feel like I could talk about for a very long time. But I do think the other important thing to note is that while automated testing tools have gotten a lot better, they do only catch about 25 to 30% of issues in general. And so there is, you know, that risk where if that's all you're doing, again, it's great, but it's not, you know, getting your full, you know, kind of guidelines and everything tested. Thanks for that. You talk about kind of weaving the accessibility considerations throughout the project lifecycle. In your experience, like, it's a little off-putting for some people who aren't doing that already. Yeah. So I think about the overhead, you know, project time is always compressed. But in practical experience, is there an easy way to start that and B, does it really bring an overhead? Yeah. I mean, I think it does bring some overhead. However, there's always a however, is the fact that we need to think about what happens in the future, right? If you don't add accessibility, for example, because of the monetary reasons, like because of the overhead, right? There eventually will be issues. Doesn't mean that you're going to get sued. I feel like that's what everybody, well, okay, I live in the US. So maybe it's a different thing, right? But you know, there is a concern. But, you know, it's the fact that people are going to come back and say, I can't access this or I have to do this, right? And we all know what happens. I feel like we all know, right? What happens after you have done a whole site and then right need to go fix everything after? I mean, you've basically just added, who knows how much like three times, four times, five times, you know, the original budget to go back and fix all of those things. So it's actually a lot cheaper to do it like within the project. The other thing is, and yes, this takes a long time. So I do not want to make it seem like it's a quick fix. But right, the more people that are trained, the better, because even if, you know, we never really want a single point of failure. But if you have like one designer and one developer, right, and one, you know, usability person and you have, you know, hopefully an accessibility person. But if you don't write, at least you have different people, then if you at least can combine all of that knowledge together, then at least that helps, you know, move you forward. But if we really want to look at somebody who's like, I don't do any accessibility now and I'm like, you know, you're talking about all this stuff and I'm like freaked out. Start with those automated tools, right, that that at least is something and then you just keep building that knowledge. So, you know, don't feel like you have to go out and like do every single thing that I talked about on those slides, right, this is coming from 16 years of accessibility, you know, experience and sometimes I miss things. It's just really like anything it's doing the best that we can. I see how I think it is just about doing the best that you can right and just keep pushing and keep improving. Yeah, absolutely. Yeah, just Alan Cole and Philippa Martin are here on the roundtable as well. Have you guys got any comments or questions? I guess not not specifically comments. I mean, we have it's certainly a way that we've been working recently on different projects and we've actually the three of us have been working on a project or working on a project at the moment where we've bought it into this project life cycle starting really early. And we have found it really useful to do that. So I guess it would be my main sort of comment on on a lot of what we've talked about today so far. To your point before Danielle. I've been on projects before where accessibility hasn't been taken into account during the development, and then it came back to us and they were like we've got an accessibility audit happening on the side. And it added so much overhead, like after the factor retrofitted and you have to double check with designers and say is it okay to change these things to make it accessible. So I think the overhead for building it into your process, as opposed to the overhead to retrofitted after the fact is probably a lot smaller. Yeah, agreed. And yeah, Dave actually yesterday Alan and I were talking about like, because we had never had a conversation about how I got into accessibility or how he got into accessibility. And, and I think hopefully this will be interesting to other people. It was by accident, like I didn't decide I want to learn about accessibility I was a Java developer, nobody get mad back in like 2005 or something, doing work with the US federal government. And, you know, we were building this, nobody really talked about accessibility back then right I feel like, I mean and I hate to say accessibility is like popular right but I feel like it's become a more discussed topic right over the last say five years but back then nobody was talking about it. And it was well your application is not going live until you know this is compliance right again as much as we can be but we want to try to hit you know this like 90 to 95% threshold. Yes, that adds so much overhead and we had to go back to I think every single screen and this was an application that we were building for like doctors and hospitals to enroll in Medicare so similar to write what's in in Australia, huge system. We probably had to redo, I would say at least 50 screens on an application, I mean the amount of money that we spent you know to Alan's point, doing that retrofitting where yes there would have been you know a little bit more to the budget if we had put it in place was just astronomical. I don't even know the figure and I'm happy I don't because I have a feeling it probably was close to a million, if not more. So yes, definitely something like just doing the best that you can and trying to fit in what you can. I'm curious when when do you raise the accessibility conversation with the client. Do they front foot it do they bring that to you, or is it up to you to kind of bring their thinking into that space. Yeah, I think it really depends. I will say one thing, I will praise Australia, like nobody's business, because here in the US, I feel like we really have to drive that now some people might be like, Oh yeah, we should do accessibility, but it's like the first thing to go. I feel like every client that I have worked with within Australia has said, we want to do 2.0. A lot of them say like you must do 2.1. You know what can we do what can we learn. I feel like it's something that people are very very invested in which is great. And, you know, a lot of times they're starting to understand why they need the budget. In order to, you know, I can't say but like make it happen right. It's not something that is, you know, done automatically, where they just assume it'll happen and it's just, you know, part of development at no cost and everything else. But it does make the conversation, I feel like a lot easier to drive. I know obviously Alan and Phillip, you've been working with accessibility in Australia a lot longer than I have. I don't know if you have any other thoughts or if you've seen anything, you know, change over the years too in in regards to the conversation. Well, actually, I thought I wouldn't mind using this to segue into how I sort of got involved in accessibility and just to explain the context for me is very much about content and writing. So I'm actually a Celsius content strategist, and I write content for our clients and also monthly blog we do. And I came into accessibility very much from a professional perspective as a content writer. And I guess I'm showing my age a bit now, but it's also to your point of how it's changed over the years. But I remember I started off my first marketing communications job. And it was sort of like, oh, there's this thing called the internet. I think maybe we need to build this thing called a website. And so I have sort of been able to see that that evolution. And so I think at first, you know, we all started from a content perspective from writing. It was just about, you know, that classic kind of old style thing of brochureware. And I wasn't involved in this project for this very first website. But a few years later, I did move into specializing in online writing. And through that, I actually started finding out a lot more about usability and that early work by Nielsen, which goes back a very long time as well. And so I was actually writing content for the online medium that was very much driven by usability and some of those usability studies. And then of course, also, you know, upskilling and getting more familiar with the WCAG, the guidelines when they were around. And there was a lot of crossover and there still is a lot of crossover. So yeah, my approach is very much from that writing content perspective. And so for me, it's really about the words and how to make those more accessible. And oftentimes the best practice for usability is also the best practice for accessibility. So that's really handy as well. And it certainly involved a lot. And I think to your original question, Dave, about getting people involved early and who's driving that conversation. I think possibly it might be a little bit different for us. It's also just because we have a lot of government clients. And so therefore what we're finding is that, you know, they perhaps have more vested interest in making sure their websites are accessible. So yeah, and I guess for Alan, he's a front-end developer. So maybe, you know, he has a different, he comes from a different perspective in terms of the team. I don't know if you wanted to talk a bit about that, Alan. Yeah, so I guess first I heard about accessibility. I did a semester at uni on web technologies and they talked about it there. So they kind of foreshadowed those saying, hey, this is something you should know about if you're building websites. And then for my first job, I was into a lot of brochure, sorry, e-commerce sites and brochure sites. And it never really came up. And so I sort of knew, I'm like, hey, no one's ever mentioning accessibility here. This is kind of free reign. I can do whatever. So that was fun. But then particularly with Salsa as well is a lot of sites I work on these days of government and it's a requirement to have accessible sites. So in that case, it makes it a bit more challenging, but it also what you're building, it feels more correct because you've built it out to the standards and you've got something to compare it to. So I think it helps with the product that you're building to incorporate accessibility into it because I feel you get a better product at the end of it. Right. I think, you know, from my point of view, getting accessibility, right, like so much about web is about getting the details right. And I like the point you made there, Philippa, about starting with the content and the messaging and good accessibility practice is just good user experience practice, right? Just got another question from the, sorry to talk over you there, Philippa. No, I was just about to say, yeah, no, that's exactly right. There's, you know, a lot of crossover from a content perspective. And I think from, you know, often from, from a design and development perspective, there can be, sometimes they can be different. What's accessible may not always look as visually appealing as what's not accessible, depending on, you know, the design parameters and the person designing, but it's, you know, certainly important aspects. And from a content, from a content writing perspective, it's actually quite simple. There are really only kind of five things you need to do when you're writing content and you're going to meet the accessibility requirements. So it's, yeah, I think it's a lot easier than people think. In terms of WCAG 2.x and WCAG 3, are there any main differences in terms of detail or intent that we need to be aware of looking forward? Yes, we are about to see a move in a shake in accessibility, which is actually really exciting. Because I think one of the things that's difficult, and I will say this even as an accessibility consultant and, you know, lead it salsa. I know people who have also been doing this for 15 or 16 years, sometimes 20, and we'll talk about, say, a standard. And there will be disagreements on what that standard means, because even though it's a standard, even though it's guideline, right? There's no, this is exactly the way that you need to code it or this is exactly what you need to do. Sometimes it is very clear cut. For the most part, it isn't. It's open to interpretation a little bit. We know that there are a lot of technologies, right? Like not everybody in the world is, you know, coding their sites or their applications in Drupal. And so there are different ways to do things. And so what I might consider, you know, a failure or somebody might consider a pass and, you know, there's, it's really binary. It's either pass or it's fail. Now granted, you know, WCAG 3.0 is still, like I said, in talks, I should say, like it's still being edited. But at least what they were talking about a few months ago, they were actually talking about these, you know, different levels similar to like the AAAA AAA. But it wasn't in terms of necessarily intensity. Like you could have something that wasn't necessarily pass, fail. It's almost like you get sort of an in between. You wouldn't have to worry about having a, you know, percentage for your audit. It's a lot more graceful, I feel like it's a lot more descriptive in terms of what people are thinking. And it's not as technology focused in terms of, you know, this is exactly what needs to be done. So even the guidelines as we know them now for say 2.0 and 2.1 will not be the same as what's in 3.0. And the other piece, right, because I sense that maybe if you do know the guidelines or you're just starting to learn them, you're like, oh, no, don't make me learn something new. But it's actually meant to be easier. It's meant to break the whole point of accessibility is to make things accessible for all and to be inclusive. That's the same thing with the guidelines. They're a lot easier for people to understand. And they're not written in a way where you just sit there and have to go, hmm, I'm about to read like three pages of documentation in terms of understanding how to meet this. Because I do feel like that's a big barrier for people. I think what the W3C has done is wonderful. I actually know people that, you know, are the ones who help create some of the guidelines and, you know, do the reviews. I have so much respect for them. But I do feel like it is a very big barrier to people when they want to understand how to meet something that they just have links and links and pages and pages to try to understand how to meet something and 3.0. I feel like is going to blow that out of the water and just simplify things greatly. So I mean, I'm actually very excited for it to come out. So I don't think it's going to be for another year or so. And I do actually still need to look into 2.2. I will be very honest with that. I think I just got so excited about three that I kind of skipped a step. So eventually I will get back into 2.2. And I'm sure there will be a blog post and another talk about that. But good things are coming to help people and to, you know, bring everybody in. I think it's interesting what you said, Danielle, there about the fact that some in some ways there's a bit of almost subjectivity over someone will pass it and someone might not pass it. And I think that applies to the content writing. So even though I said before, it's really simple. There are only five things you need to do. I guess there is also that subjectivity because, for example, one of them is to to write descriptive page titles. And so, you know, some that may be actually very difficult for for people to write, you know, a short descriptive page title. So while it's they're simple and it could be subjective, one person could say, well, this is short. It's only 20 words. And of course, other who would say, well, you know, sure, it's more like four to six words. But so there can be a level of subjectivity over that to where it's not necessarily, you know, the guidelines don't say the titles must be a certain number of. Words and, you know, it's not really that prescriptive. So yeah, I think there is that room for interpretation, but also, you know, to be honest with yourself as well and sort of when you are sort of deciding whether something is meeting those guidelines as well. Yeah, agreed. And, you know, it plays into content but goes back to an example that I gave before about like learn more and read more. So for me, if I see those, I'm like, OK, if somebody pulls that out in a screen reader, they're just not going to know. But technically, right, if you go like very, very technical, the guideline is for a link in context. So somebody could say if you have that right in a sentence where it's, you know, learn more about, you know, et cetera. And it's in a paragraph, they could say, oh, well, you know, that passes. Well, nobody really is going to know what the context is in my mind. So I actually, when I do audit reports and I know Philip and Alan have seen this where I actually generally have a section where I call out what's subjective and say, you know, accessibility analysts will look at this in a different way. And so, you know, you might have another analyst, you know, look and say that this passes. So just know that, you know, there might be some, some discrepancies there. But yes, I, it's always good to call those things out. But it is, you know, understandable when people do get a little confused as to as to what the right thing is. And I think to say to that, there is no necessarily right. There's try, there's learn, there's do, you might not always succeed, but that's how we learn. And then we do it, you know, again, right? And we go from there. Nobody's perfect. And that's good because things would be really boring. But we just, we do what we can and we just kind of keep building on what we know. That's another question from the audience here. You know, someone's confident that they're compliant from their technical side. And this is from Joe Taylor and the VicGov STP. The biggest problem is awareness and understanding across distributed authors. And this is a big trend we're seeing in our client base across the public sector as well. Everyone wants to push authorship out to the fringes out to the subject matter experts. But they are, you know, one more step removed from the project decision making. So have you got any hints and tips about how to bring them along on that accessibility journey and, you know, not wanting content and PDF for more, not wanting to post up docs, you know. I mean, I think it's about training. I mean, literally last week, I ran a session for one of our clients that specifically looked at what web writing best practice is and took them through that from both a usability perspective and a accessibility perspective. And so actually gave them the knowledge because obviously if people don't know what they're supposed to do, it's very hard for them to do it. So if they don't know how they can write in a way that's accessible and then other things like, you know, alt tags for images, which again can be part of the training. So, you know, I do believe that it's a really good idea to actually train content authors across writing, but with that lens of being writing content that's good for usability, that's good for accessibility and anything else that comes under the content author role such as loading images, et cetera, should be covered as well. Perhaps another question for you, Philippa. Is there an educational grade level or a reading level that you typically target in your content writing? I mean, particularly for government websites, I guess we do have that mandate for accessibility for everyone. Yep. So this is actually addressed in the WCAG 2.1 and 2.0. And it should be lower secondary primary, sorry, lower secondary. So that obviously means year seven to eight. The DTA, so the Digital Transformation Agency actually recommends year seven. So it's about, you know, choosing those really simple words, keeping the sentences short and simple so that you are writing for a year seven level. And in fact, I think in the UK, the UK government style guide, last time I checked their style guide, they were actually recommending even lower, they were talking about writing for a 10-year-old to read. So yes, that's sort of the level, at least I'd say year seven for Australia to keep in line with the Digital Transformation Agency recommendations. On the sites that you're doing, are you providing much dialogue or information around your accessibility considerations and approaches on the website itself? Like an accessibility page, or do you have that conversation with your audience directly and say, this is what we're doing, this is how you do it? So everything that we are creating is open sourced. So whether we are talking to clients, whether we are talking to, you know, their stakeholders, whether we are helping others, you know what I mean, throughout other agencies, we are trying to share the information as much as possible. I actually used to work for an accessibility company for like a short term. There are all of these products out there and everything else, and they're great. But I do feel like a lot of times, and understandably, right, it's a business. You have to pay for all of these videos, right, to learn more and to figure out what to do. Again, it's a business model. It's very complex. Somebody has to do it. But, you know, when we were talking at social, when I came in and, you know, started our practice, it was, well, I have this whole testing checklist and it's like really, really robust. Like, what do we do? And it was like, well, what do you mean, what do we do? We open sourced. And I was like, oh, good. Okay. I just thought that would be like not okay for some reason, you know, because again, a lot of people are able to charge. And I mean, I think it says something just about how important it is that we're recognizing, you know, that we need to teach. Like I use the word evangelizing. And, you know, it's not meant in like a religious way, right? It's meant to be the fact that, like, you need to educate other people. And once you know how to do the basics, right, you teach people on the basics. And once you know more than the basics, you teach more people on the basics. And that's how we really grow. I mean, my dream, and it's probably going to take another, like six months to a year, is to start creating an accessibility community of practice. You know, maybe it'll be amongst, you know, the digital agencies, right, that are part, you know, part of Drupal South. Maybe, you know, we can get government involved. You know, I know that there are some communities of practice already. Like the more that we can do the better. So I know that was a little bit more, Dave, than what you asked. But I still think it's super important for us to just make sure that, yeah, we're, we're sharing the knowledge. It's not something that we need to keep. It's not proprietary, share, share with the worlds. And, you know, that's why we're here. So I think that sounds fantastic. We're just coming up to our last minute here. So any other kind of final comments or anything else you'd like to say? I'll definitely hit you up about that accessibility practice in our region. Yeah, great. Yeah, absolutely. You know, I, I know that we've, we've stressed this, but it really is just getting started. You know, I, I know that some slides will be shared out. The recording will be shared out as well. Please also, I know that I shared my, you know, contact information as part of my presentation. Please feel free to contact me. And, you know, I can help route you to, you know, Philippa and Alan and anybody else who, you know, is able to assist. We care deeply about accessibility. We care deeply about, you know, being empathetic, of course, to other people. And just the fact that you all, you know, we're tending and asking questions just means so much and shows how important it is. And Dave, thank you very much for moderating. You know, I know that there's a lot of, questions from the live Q&A, but I know that you came with questions as well. And it's just been a great conversation to have. So just wanted to thank everybody for, for having us. And hopefully we can do this next year in person, but thank you so much everyone. Wonderful. Thank you. That was an awesome presentation. All right. Thank you. Everybody. All right. Bye. Cheers.