 Hi, how's everybody doing? So quick introduction to myself. For a second, Miles, I work for Blue Hosts, doing project management stuff. And I love WordPress. I've used it for a very long time. One of my favorite things about WordPress is it allows anybody to make something great. You can jump in with really any level of experience. And everybody can make something great. And the pessimistic state of WordPress is to democratize publishing, which goes along a little bit with the focus of my talk, which is web accessibility. Because the goal of web accessibility is very similar to the goal of WordPress. Giving people with disabilities equal access to information on the web. So this is a topic that I care very much about. And it impacts a lot of people in a variety of ways, some of which are kind of unexpected. The most common things that WordPress and other accessibility guidelines are caring about are people with low or impaired vision, blind users, color blindness, dyslexia, and impaired emotion, and cognitive disability. So those are the things that the guidelines are for. But the use cases of accessibility go well, well beyond that. But before I get into any of those things, I want to understand the room a little bit better. How many people already have a website up and running? How many people code a little bit? Awesome. And how many people don't? I'm going to raise my hand too, even though I did it for both. All right. So this is going to be covering a lot of things. I will be publishing these slides on my website, which is just chrisdavidmiles.com, and all of the information there. So I'll be sharing certain statistics and things like that about use cases for accessibility. But all of that will be up on the website. So don't feel like you have to take it down right now. So starting with dyslexia, this is actually just a cool thing that I found online. And the story behind it, from what I found, is that a JavaScript developer was hearing a description of what dyslexia was like. And it kind of reminded him of fast-on manipulation. And he wondered to himself, I wonder if I could simulate dyslexia-like experience. Obviously, there's different types of dyslexia. But if you could simulate a type of experience similar to dyslexia just using JavaScript. And this is what he came up with. Obviously, it's not exactly the same as having dyslexia, but it's kind of an interesting illustration of what it's like. BBC estimates one in 10 children experience some form of dyslexia. So a lot of different people. It's not just letters moving around, but there's all kinds of different forms of it. But this is kind of an interesting illustration of one of the ways it can manifest. Another really common thing is impaired motor control. 19.9 million Americans, which is 8.2% of the population, according to the 2010 census, would fall into that category. So if people aren't able to use a mouse, or at least not use a mouse in a typical way, they would fall into that category. It's quite a lot of people. So the question that often comes up with accessibility is why should I care? What does it matter? I'm talking about kind of an edge case, right? Or at least that's the perception. And a lot of times, you would kind of need to sell yourself on it, or your client, or your boss, or whoever it is, whoever's paying for the project to be done to invest the extra time, energy, whatever it is, into making sure that either your content, or your team, or your plug-in, or whatever it is, is accessible. So why should we care? Well, the first and foremost thing, and maybe this is a little bit of a virtue signaling, but the first and foremost is it's the right thing to do, honestly, to make sure that your content is available to people with disabilities is, I think, very important. But oftentimes, that is not enough for the people writing the checks. Sometimes we have to be a little bit more convincing. So the most common excuse that I hear for people who don't want to care about accessibility in terms of investing the development time into it would be really nice to have, I'm not opposed to it, but accessibility only affects a small percentage of people. So we're looking to cast the widest net, so it doesn't matter. But it's not true that accessibility only affects a small percentage of people. Actually, it impacts a much larger percentage than people might realize. And the use cases for accessibility go well beyond people with disabilities. But for the sake of argument, just for a moment, let's imagine that accessibility is only about folks with disabilities. And just look at the numbers for that. So accessibility by the numbers. Making your site accessible increases your audience by a lot. So first number here is 19.9 million people in the US have difficulty lifting or grasping. 5.2, or 15.2 million people have cognitive mental or emotional impairment. Next on the list, 8.1 million have some sort of vision impairment, I'm in that list. Next, 7.6 million have a hearing impairment. So all of those percentages, by the way, are a percentage of the US population gathered by most recent published census. So all of that together is 20.9% of the population. It is not a small number. So if you're thinking about the amount of money that might be invested in a pay for click campaign or something like that, which would have, let's say, a 3% increase in customer base, that would be a really big win for that campaign. And that's 3%. This is 20%. So if your site is not following accessibility standards or is inaccessible to one of these groups or all of these groups, it could be as many as 20%, one in five, which is huge. And this is just talking about people whose disabilities would show up on the census. So that's long-term. There's also a ton of short-term disability scenarios that I think are a lot more common and perhaps even a little bit more relatable to people without long-term disabilities. Things like tired eyes. How many people have a cell phone and have been outside at the same time? Okay, all of you then would benefit from sites where the contrast ratio is high enough that you can read your phone in sunlight. Thank you. Right? It matters. And it affects all of us, even if you have perfect vision. If you're really tired at the end of the day, and you have trouble focusing, even if you have perfect vision, this impacts you. Kind of an interesting use case. My dad is really into fitness and he's in really, really good shape. He buys me a gym membership every year that I never use. And he had surgery, carpal tunnel surgery on his right hand, so he couldn't use a mouse. It was painful, he had impeded motion. That meant that any site where it was hard to not use a mouse didn't get his business for the six months while he was recovering, which meant no riding along wars, none of the equipment he wanted to do, none of that got purchased because if it's a huge pain to navigate a site, unless you absolutely have to, people are just gonna drop off or find another site that's easier to use. Amazon.com nowadays is very, very good about following these things and you can navigate it with just the tab key, enter, and the space bar. But one quick test, if anyone, you know, a lot of you have your laptops out, which is awesome, if you just wanna go to your site and see if you can navigate it with just the tab key, enter, and the space bar. And if it's really tricky or if things are skipping around and you don't know where you are, that might be a sign that you might need to audit things for accessibility and we'll get into how to do that a little bit later. Another one that is kind of lesser thought of because it's not related to any disability at all is actually reading mode for browsers. Safari has this built-in, Opera has this built-in, and a lot of people have Chrome and Firefox extensions that will take a page and condense it down into something that looks more like a book. Kindles do this too. Well, in order to do that, you have to have HTML that this, you know, those sorts of programs can understand. So if you're using a header tag, just to make your font bigger, well, all of those programs are gonna think that's literally a header and they're gonna treat it like one. Screen readers will do the same thing, but it's impacting any sort of reading mode. So that's even people, no disabilities involved, but just using this thing. So as it turns out, technology that's designed to help people understand and consume web information without physically looking at the page has a lot of applications. For example, the robots that determine SEO. If your page is impossible for a screen reader to read, it might be difficult for a bot to read, which that is going to impact your SEO. Semantic HTML matters. I don't know if there's any SEO experts in the room, but I think they would agree that at least as much as meta tags are important that if your content is basically unreadable for the Google bots, it's not gonna matter how good your meta tags are, not to say that they're not important before the SEO people are coming. So another use case that isn't always thought of are the laws surrounding accessibility. In the US, right now, the laws around it are pretty much just limited to anything that receives public funding. So that would be like university websites, that would be municipal websites, that would be government websites, things like that. But even spills over a lot of times into schools, I was talking about accessibility before another conference and somebody brought up from the audience that they ran a hair salon that was actually being sued because their site was not accessible enough. And it fell within these laws because it was a hair salon that also taught people how to do that, how to do hair and those things. So it was a school and therefore it fell into that category. In the EU, they're even more strict and there's a lot more laws about just having customers at all, certain requirements for accessibility exist. There used to be a pretty prevalent attitude that, oh, well, if you didn't have customers in the EU, it really doesn't matter. It's not like the EU is gonna sue you if this happens. Well then GDPR happened and everyone sort of changed their mind about whether or not EU laws apply over here. So it really does matter. And if you have any customers in the UK, basic accessibility is something you're probably gonna need to worry about. And then something else to think about is also the tech debt because if you start at the beginning with accessibility, it's gonna be a lot, lot better than if you're trying to do that much later. Now this doesn't just go for designing plugins and themes and things like that. This also goes for the content itself. There's many ways in which the content can have accessibility problems. For example, even ones that you wouldn't exactly think of as being related to disability, a lot of times people have links that say click here. Well click here is only useful to a sighted person who can see that and understand within context what it means. If you're listening to it and if the link doesn't have the right attributes attached to it, click here doesn't really mean anything. So if you're using a screen reader and listening to the page instead of reading it and you're just going through to skipping to every link which is a common thing people will do is I'm gonna go through every link on the page. And you're gonna click here, read more, read more, read more. That's not useful. And so as part of your content it's important that you think about what the use cases are. If you have any charts, try to make sure that they work even without color. And if you use language like in the graph above or in the graph to the right, that only makes sense if you're looking at the page in the same way as when it was written. Because even on a mobile screen, if things get stacked, which hopefully you're using some sort of stacking on mobile screens, suddenly things are in a different place. So the phrase, the graph to the right, no longer applies because the graph is no longer to the right, it's at the top of the bottom. So things like that that can slip into your content can create a lot of debt later on when in the future two years down the road, oh now I've got to audit all my stuff and make sure that it still makes sense for this 20% base. So it's a lot easier to do it from the beginning. Here's one of my favorite tweets about this. Accessibility and open source story. Month one, it's too early for accessibility. Month six, fixing accessibility issues at this point is too hard. That's how sometimes it can go if it's not a priority from the beginning. So in response to this, you know, and it's kind of a true story, it does happen all the time. Here's my patented, it's not really patented. Here's my patented three steps to making and keeping your project accessible. Okay, so step one is make it accessible. WordPress makes this pretty easy because out of the box it actually follows some pretty good guidelines and the links show up pretty well. But step two is once it's accessible and your shirt works, then do all of your awesome fanziness that you wanna do and make it as fancy as you want. But after that, after you've made it fancy and you love the way, you know, the look and feel and everything, make sure that all of those fancy parts that you made don't break the accessibility in step one because oftentimes they will. Step four of this three step program, celebrate that you don't have a ton of tech debt and that your product doesn't exclude millions of people and potentially violate international law. And then of course step five, do what you want with all that extra free time and money that you've saved. This has been three steps to making and keeping your projects accessible. But I can simplify this just to one step and that's make it accessible. If you're thinking about it from the beginning, it shouldn't be that hard to maintain just like anything else. So, and that's just one of the many ways that tech debt can be introduced if you're not worried about accessibility from the beginning. So that is some of the ways that I tend to try to sell people on accessibility, just describing that there's a lot of use cases for it outside of, you know, outside of the regular what you would expect and outside of people with disabilities. But there's, once you've sold people on it, here just some common, at least the most common that I've seen, pitfalls that can exist within accessibility. So these are things that I've seen the most often that people get wrong with accessibility. So, starting with background images. I think background images are super cool, especially when done right, like you've got a really good hero image, you've got some text and things like that. I'm obviously not a designer if you look at that, but so if you're using a background image and you do a text on top of it, it might look really good in this state. However, it's important that you specify in your CSS or however you're coloring the background color behind the text. See, in this case, we're using an image, and up on my screen right now for those listening in, is an image with text over top of it. And it's very easily visible because the image is dark and the text is light. However, if I were to turn on high contrast mode, most computers that are either running Windows or Mac OS would turn off background images to enable high contrast mode, and if no color is specified, it will inherit the color that is behind it. So if I turned high contrast mode on this page, I would see this. And for those listening in, it is a picture of white background and white text. It is not easy to see. So yeah, whenever you're using background images, as cool as it is, just make sure to throw in a color behind the text even though you think you might not need it so that while it's loading, you can still see the text and so that if high contrast mode is used, you can still see the text. Here's another one. Ignoring focus state is one that I see a lot of. Focus state is when you're tabbing through a website, whatever is in focus at that particular time, you should be able to see what that is. So if, let me just see if this works. Open up a new tab. I'm gonna go to time.com and pick on time magazine a little bit. So a focus state here on the screen is I'm demonstrating. I'm tabbing through and I can see what I'm clicking on. So right now, we've got US, politics, world, ideas and at any point I can hit the enter key and it would be like clicking, right? But after I get through this menu, where am I now? What would happen if I click to enter right now? And for those listening in, I'm tabbing through a website that is not clear on focus state so it's impossible to know where I am. So you're kind of playing Russian roulette with your links and if I click, I don't know what's gonna happen. Oh, I guess I was hovering over business but it was really tough to see that because at that point, they were ignoring focus state. So getting back to, there we go. So if time magazine, anyone working there listening, please press your website. So all right, I'll text up right. Here's another thing that is often done wrong. If you've got alt text, alternative text, it's just text that seems to describe goodness. So if you're using a screen reader and you're going through a page, it's just gonna tell you what the image is of. This, I'm looking at an image of pancakes with butter and syrup. So the alt text is pancakes with butter and syrup. Pretty easy, straightforward. You want people to be able to understand what it means. One thing that is sometimes not good is people make the alt text way too long, right? And you get situations like this. The alt text is now, is the winter of our discontentment. Glory is summer by the sun of New York. There's an entire Shakespeare play in that alt text. So that's how you do it wrong. Obviously not that bad, but another thing that can sometimes happen is if there's no alt text at all, you get this. But even worse, because screen readers will read the file name. Which in WordPress sounds like WP config slash date slash file name. So imagine hearing that every time there's an image. It's not very fun. Decorative images, any image that's there that is just for visual, it's not actually part of the content. Put an alt tag there, but don't put anything in it. And when you do that, so the screen readers will know they can skip it. Otherwise they will read you the file name. So if they know they can skip it, then it's fine, they won't even notice. They can go to the page and they'll have no problems. Another one to try to keep in mind is clickable area for links. So this one is also very impactful on cell phones where the difference between one and two pixels is a lot, lot tighter because you're working with a three by two inch window. So the clickable area is just the area that you can click on in a link. And sometimes a mistake that is made is either the clickable area is too small or the hover state doesn't correspond with the action, which is sometimes you see this on a little bit older websites. You'll hover over a menu item or a link and the color changes to show you that you're hovering which is great, good job for doing that and you click and nothing happens. That's because the hover state knows you're there but the clickable area is not actually corresponding with the hover state, which is not good. Another thing is form labels. When you're going through, if you're using a screen reader and you go through a page, there's different modes. Whoopier has used Vim. All right, so in Vim, one of the reasons why it's kind of tricky to use Vim is that there's different modes and if you've never used it before, you'll try to type on the page and suddenly text is deleting and the declaration of independence appears out of nowhere and all this weird stuff happens. So the difficulty is all the different modes and you have to switch between different modes to interact in different ways. Screen readers are exactly the same way. They have reading mode, they have forms mode, there's other modes depending on the reader that you're using. Well, if you're in, if you're trying to type something and let's say you're trying to make a purchase so you need to fill out, hey, what's my name, here's my address, credit card info, things like that and your label is not, your form is not labeled. You have to switch from forms mode to reading mode in order to see what's there. So for those listening in, there's a form on the screen that says name next to it and anyone who can see that can just look at it and say, oh yeah, I put my name in here, that's easy enough. But if you're going through this on a screen reader and you're tabbing through and you get to the part on the page that is a form for name in your in forms mode, without a label, you don't actually know that it says name there. You have to go into reading mode to know that it says name and switching back and forth can be annoying because then you have to go back, find where you are on the page and it takes forever. But if you label them properly, you can stay in forms mode and know what it's called. Concurrent form seven does a great job of this. Gouraf of them. Color contrast, good visibility, poor visibility. There are tools that will kind of test your colors for you, even automated tools that will test your colors for you to see what's available. And as far as a visual impairments go, oftentimes people with extreme disability will find very accommodating tools anyways and you don't always have to go super far out of your way for that. But generally speaking, if you're using good enough contrast, it should work. And another misconception, it's not the worst thing in the world, but another misconception is that more contrast is always better. It's not always the case, just because extremely high contrast, depending on the font that you use, can actually make it harder for people with dyslexia. So there's things that you can do and just guidelines you can follow to make it both visually appealing so that the designers love it. And good enough contrast that it's easy to read and direct sunlight on a phone. Poor visibility is hard to read even under the best of circumstances depending on the screen or the media. So color contrast is important. Inaccessible embeds is another one. A lot of WordPress is really cool with its use of oEmbed because you can throw all kinds of different content, including WordPress posts themselves into other WordPress posts. Really, really cool that it can do that. The problem is with that, not that I would have it any other way, but the problem with being able to so easily embed things is that you inherit all the problems of anything you're importing. So if you embed something that is made, for example, in Flash and doesn't interact well with accessibility things or you're embedding something like a PDF, it won't be able to... All of your accessibility is gonna be gone because, well, your page is great, but the content is in this inaccessible frame. Restaurants, if anyone's working on any restaurant websites, listen up. I feel like restaurant websites are the worst at this. And I love restaurants, I love food. Keep doing what you're doing in the kitchen. Restaurants are your websites. Sucked because, at least for accessibility because they'll design these beautiful websites that were great on mobile to load fast, they've got great SEO, all the things that you think of. And then they'll have a link somewhere in the middle of the page that says, click here to see our menu and it's a PDF. Like you just, like every single accessibility problem in the whole world all at the same time. Click here, it's a link that inaccessible, like all of it. Yeah, so all of that work and effort and everything that went into making that beautifully accessible website is now out the window if you have to use a PDF to see the menu. So it's just something to think about. So anytime you embed something, make sure that you're not ruining it. If it all possible, sometimes there's requirements that make them possible. Sometimes there's compliance issues and you have to use some government-made thing, you know, that was made in the 80s and you can't get around that. But if you have any control over what you're embedding, see if you can make it accessible. Tab index is where you're at when you hit tab. Imagine what it would be like if you steps through the front door of a building and you were on the roof. That is what it is like if you're messing with tab index and somebody's going through it. So what tab index does is it says how many times you have to hit tab to get to a certain point. There are ways it can be used, right? For example, jump links are one where the first time you hit tab you'll go to a jump link that will easily jump you to places on the page. It's great for accessibility, it's built into most WordPress themes. Jump links are fantastic. But it's really easy to do it wrong. Oftentimes it's better to just put your stuff in order so that top to bottom is correct. Otherwise, like if your tab index is two, for example, no matter where you are on the page, if you hit tab twice, you're gonna be where that thing is that the tab index you specified was two. Have you ever been in the dark going downstairs and you think there's one more step than there is? And it's just like a little tiny heart attack as you do that. That's what it's like if somebody's messing with tab index and you're going through the page and suddenly you're in a different spot. It's extremely frustrating and there's a really high amount of drop off for people that are trying to navigate that way who are suddenly dropped off the page or suddenly in a completely different place as a result of messing with tab index. And that kind of ties into the next thing which is make sure your HTML is semantic, which is just to say make sure that you're using pieces of HTML to describe what it actually is. The old editor, right, which all this talk about Gutenberg soon it won't look like this, but the current core editor is now tiny mce and it's here, you've got paragraph heading one, different types of headings. Those should actually be what they are. If you're using some header, it should actually be a header. If you just want to make your font bigger then make your font bigger in some other way. Use a CSS class, use some to custom. You can actually hook into this and add more things if you want. And there's plugins that would change your font size arbitrarily, it's really cool. But if you try to make the font size bigger by using a header, it's everything that uses a screen reader and expects semantic HTML, including the Google bot is going to think it's literally a header. So if you've got this really big quote and you make it H2 or something, it's gonna read that whole thing like a header and Google will treat it like a header and think that your keyword stuffing because you've got two paragraphs of a header, right? So semantic HTML just means if it's a figure, make sure it's a figure. If it's a details, make sure it's details. If it's, sometimes if you're building in like a JavaScript heavy environment or like a friend and thing, it's okay if your application is a gigantic mess of divs. That is actually okay as long as things are properly labeled. Then it can still be traversed natively. Things will still understand it and it will be fine. But as long as you're not using HTML objects wrong, you should be okay. But yeah, make sure your HTML is actually accurate. So next, I wanna go through some resources and tools where you can learn more. And where you can check to see the accessibility of your sites and you can learn more about how to code things right. The, of course, first on the list is codex.wordpress.org slash accessibility. It is a great place to start. And it details not just accessibility in general but also what matters in relation to WordPress specific things. So that's a good one to check out. A good one to bookmark. This is an evaluation tool. It is wave.webain.org, w-a-v-e dot w-e-b-a-i-m dot org. You can put any URL in here. We'll analyze the page for you and point out, hey, you're using this wrong, hey, your color is off, it'll do all kinds of tests. Kind of like an XML or HTML validator, except it's an accessibility validator. Very handy. You can even set up automated tests because this is a, you know, it uses public endpoints. So you can use automated tests and sometimes accessibility problems have nothing to do with your code, it's your content. So if these automated tests are running and then a plugin updates and breaks accessibility, you can know from an automated test that comes back and says, hey, suddenly all your colors are wrong. All right, it's pretty cool. And there's plenty of browser plugins that utilize these endpoints as well that you can use. ColorSafe.co is a really fun tool where you enter a background color and your text color and maybe even some font or the weight and the size and things and it will tell you based on the size of the font, the color and things like that, the weight of the font, what is appropriate for contrast ratio and it'll be able to tell you, oh, that's not enough or that works. So pretty handy. The No Coffee Chrome extension is a lot of fun. If you've ever wondered what it's like to have a certain visual impairments, this can actually show you a lot of different things and it just sort of gives you a better understanding of what it's like. It's got all kinds of different visual impairments that you can just check on and off and it just changes the page where this is an approximation, kind of like that dyslexia simulator. It's not exactly perfect, but it'll show you, oh, this is what it's like to have partial blindness in this eye and this is what it's like to not be able to see these colors and you can simulate the different types of color blindness that exist. That's the No Coffee Chrome extension. And there's a lot of other tools that are linked to on WordPress.org slash accessibility in this page is the process of being updated. So check it out for weeks and it'll be even better, but I can close at this point for questions if anyone has any. This is the current day we get the websites that have to be ADA compliant from the US. Yeah, so certain websites, right now, as far as I know, they're not a lawyer, but right now, what matters the most is websites that take any sort of public funding, right? So if you're not taking public funding, the chances of you being sued are less. As far as this goes, that's not to say that excluding one in five people is still okay, but for anyone listening in, it's probably best to Google that just because the information changes a lot. Yeah, next? How about a specific question about tab indexes? Yes. So, and I haven't tried this, I'm curious how this might work. So say I have a regular page, I'm not putting tab indexes anywhere, but if I tab through, I'll go through my top nav page. But then say I have a form on the page and my form builder does automatically put tab indexes on the fields. Would that mean that as soon as I hit tab, it would jump to the form? It shouldn't, but it would be worth testing. Okay. And it would be worth testing in multiple browsers. But in those cases, it shouldn't as far as I know. Thanks. Oh, there's like a little thing that you can pass around to. All right. Oh, and it's a microphone, how cool is that? Yeah, a ball and a mic, this is awesome. Accessible on the beach. But just curious, do you have any accessibility audit testing tools that you know where I'm in? Yes. So this public endpoint here, the web aim one is a really good one. Another one that's actually built into Chrome, I don't have a, I should have a slide for it. Recently, my recent, I think it was like six months or so ago, Chrome actually came out with an accessibility audit that you can do in browser. You know, Chrome has a lot of performance benchmarks that you can do in browser. Recently came out with, someone recently came out with accessibility audits you can do. It does, I think at this point still require Chrome extension, it's made by Google. But if you just Google Chrome accessibility audit, Chrome extension, you will get it. You can install it. Then just using your Chrome inspector, you go to audits. There are at this point four options on the page. The bottom one is accessibility testing. Check that box, run the audit and it will tell you what the robots think of your accessibility. Of course, it's probably something human to review it in 2018. Next question. The back. If you are a magical wizard and could snap your finger and eliminate one of your pitfalls to most dramatically impact accessibility. Yes. Mistakes that most people make, which one would you eliminate? I would make it so that people didn't mess with the focus state. By default, if there's no CSS or there's just default stuff, you can see what you're focusing on in browsers. So you can tab through things. So anytime you can't see where you are on a page with the tab key, it's because some CSS broke what the browser already had. And if I could step my fingers and make one thing change, it would be make it so that you can access, you can navigate most websites just using the tab key enter and the space bar. Colors and stuff are impactful, but I think the tab key is probably the most important thing, especially since most temporary accessibility issues like a quick example. Every time I donate blood, because I'm kind of a wimp, I have to like squeeze this ball and it wears my hand out. So anytime I donate blood for the rest of the day, I'm not using a mouse with my right hand and I'm tabbing on the keys. So that is impactful of that and that is a temporary disability that exists. So that's what I would change. Make it so that people can tab through websites. Do we have time for one more? One more question. So would you say being able to tab through a site be the most 80, 20 thing you could do to get the quickest wins in terms of accessibility? Quickest wins in terms of you could tell right away whether or not you're compliant in that way and if you're somebody who's hired a dev to build your site and you wanna know whether or not they've worried about this in the past so far, that is a really easy thing to do is just open up a website, press the tab key, and just try to use the website without a mouse to see what happens. No test is required, it's just can you do it? Is it enough of a pain that you would give up? If it is, it's a problem. Follow up question. So at the agency I ran out, we had a client actually get sued because of Bay of ADA. It happens more than you might think. So what's a good like if we pass the lighthouse Chrome audit? Yes. Is that like a safe bet so they're not gonna get sued anymore or what's the criteria you have to meet? So first, I am not a lawyer. But secondly, in what I've read about lawsuits that do exist about these sorts of things, there's two things that are important. One, maintaining accessibility, specific accessibility standards even quote, right like with this level of requirements we passed these audits, anything independent in third party is good. But the second thing is if you can demonstrate an intent to do it, like oh, we were accessible at one point and then we upgraded our version of React and nothing's accessible anymore. That's a lot better than we've never cared about this in a quarter of a block. So some of you think about it. I think we're out of time for questions, but that is WordPress and web accessibility.