 So these slides can be found on my GitHub at stevejonesdev.github.io forward slash accessibility dash first dash method. All right. So like I said, I'm Steve Jones. I'm the CEO or CTO of Equalized Digital or certified B Corporation and WorkPress VIP agency that specializes in accessibility. I'm excited to talk to you today about implementing an accessibility first approach into your WorkPress web development projects. This ensures a truly accessible digital experience for all users, specifically those with disabilities. WorkPress developers' unique responsibility to take a proactive approach to developing blocks, plugins and themes, as well as some tools and automations we can integrate into our development workflow. So before we get too far into this talk, I want to outline what I want your main takeaway to be. I'm going to give it to you upfront because it's very important. The goal of this talk is to equip you with the inspiration and the information to adopt and prioritize accessibility early and often throughout your development workflow. And this is also a bit tweetable. Okay, so prerequisite, website accessibility. I'm sure most of you are very familiar with website accessibility since you showed up for an accessibility talk. Or maybe you're just developers and you're following the developer track. But here we are. But I want to start with a simple definition of accessibility so we're all on the same page. Accessible web development is the practice of making websites usable by as many people as possible regardless of their ability or circumstances. Traditionally we think of this as people with disabilities. People who are making websites accessible also benefits those on mobile devices with slow internet connection or those with temporary health issues. So why accessibility? There's many reasons why accessibility is important to our development workflow. I just want to touch on a couple real quick. Legal requirements, disclaimer, I'm not a lawyer. This is not legal advice. Please consult your lawyer for legal advice. Many countries have accessibility requirements and penalties if you're found to not be following accessibility guidelines. In the United States federal agencies and often those receiving federal grants are required to adhere to Section 508 standards. Other businesses in the United States such as local governments and those open to the public must adhere to the Americans with Disabilities Act. I've personally been in conversation with companies and people that are in the process of being sued for not having an accessible website. Trust me, you want to do it right the first time and not get tied up into costly and stressful legal litigation. The second reason why accessibility is important is that it benefits everyone. Accessibility benefits all users. Even if you develop features for users that are hard of hearing, it will benefit those watching in loud places or with the audio turned off. If you develop features for users that are visually impaired, it will benefit those that suffer from migraines and can't currently look at their screens. In a side note, it will also benefit those that have few timid drains at the word camp after party. And as much as we all like to avoid it, we're all aging and will most likely someday benefit from accessibility ourselves, either due to age-related issues such as visual impairment or some more extreme health issues, even though we may not realize it, we need accessibility. We fully adopt accessibility first development now, ensures inaccessible features. So what is accessibility first development? Firstly, it's necessary. Accessibility first development embraces the idea that accessibility is necessary. It's not added on later or worse, ignored altogether when a project deadline is approaching. Prioritizing accessibility takes it from being a baseline standard to a core project requirement. Accessibility first development is also inclusive. Accessibility first aims to target those with the most extreme disabilities first. This creates a trickle down effect that covers all users with little to no disabilities. And finally, accessibility first is proactive. Accessibility first development addresses inclusivity at the beginning and throughout the process. Not as an afterthought addressing accessibility early saves time and resources through a more efficient workflow. Simply put, if it's not accessible, it's broken. Developers must adopt the mindset that if what they're recording is not accessible, it's broken. It should be fixed, it should be tested, it should be reviewed before being merged into production. Yeah, it's a good tweet but we're right there. So WordPress developers have a unique responsibility to taking a proactive approach to developing plugins, blocks and themes. They are fully accessible at launch. These plugins are generally content producing. They can be installed on multiple websites and on any number of pages within those websites. WordPress has a massive 40 plus percent of websites on the internet running it. Which makes retroactively limiting accessibility a daunting, expensive and maybe an impossible task. So for example, you create a block, right? Create a block plugin, develop it, don't check it for accessibility. This block actually will generate some HTML stored in the database. The HTML that is generating is inaccessible. We upload that into the WordPress plugin repository. It's downloaded on X number of websites. This inaccessible HTML gets generated on any number of pages. And then somebody submits a support on the .word support thread that says, hey, does blocks generate HTML that's inaccessible? Can you release a patch for it? So you can go out there and you can fix that depending on how it's generating this code. If it's storing it in the database or if it's being generated through PHP. It would require all those plugins to be updated on all those websites. It could static HTML in the database. It could require you to write a script that would have to parse through those blocks, find that HTML and replace it. It could be quite the difficult task. So just a word of caution. There are some people out there that claim that accessibility can be layered on top of an existing inaccessible website. There's a word for these products which I won't mention here. Don't want to call anybody out. This is not true because people are most likely trying to sell you something. But why? There's no replacement for making accessibility part of your development knowledge base from the onset. So we've been here before. How many of you are old enough to remember Model First? Yeah. How are we going to get APIs to pay for this? This is twice as much work, right? 2009-ish, 2010, we first heard about the Model First concept. It was an overwhelming shift in thinking and development workflows. These days it's just part of what we do. I actually think it would be even harder to make a website that's not responsive now than to make one that is responsive because my code base is set up for Model Responsive. Today the accessibility first concept may seem just as daunting as Model First years ago. With the right tools and attitude, accessibility can become just as integral to our development workflow as Model First is. So I want to implore all developers here to learn accessibility deeply. Here are a few websites to get started. The web content accessibility guidelines are sometimes referred to as WCAG, which can be found at w3.org-wai-standards-guidelines-wcag. So these are the official docs. You can go through there and you can read what level A, AA, AAA is. You can learn about the 2.1 standards and there's lots of code examples, like if you're trying to make an application in you or walk you through all the parts that you need to consider. So as a developer, I find myself going to the Mozilla in the end web docs. Quite often, for examples, they have a lot of really good accessible examples. When you get to more advanced accessibility things for tabs, menus, flyouts, modals, things like that. You can find that at developer.mozilla.org. So finally, a tool that I find myself using quite often. Particularly because it's a tool that our company has put together is the accessibility, the Equalized Digital Accessibility Checker documentation. The Accessibility Checker is a plugin that I developed with my partners at Equalized Digital, but it also comes with great documentation. For each accessibility check that the Accessibility Checker does, the plugin documentation describes the issue, describes its impact on accessibility and how to fix it. And believe it or not, even though I coded the plugin, I find myself working on client websites, clicking over there to how do I fix this issue and the documentation right there. This is what's wrong, this is how to fix it. So in the last two here, I just want to put a little disclaimer that these are unofficial docs. It's always be sure to cross reference the unofficial docs with the official spec. All right, so let's jump over to testing. Accessibility-first testing. So I kind of use this as the accessibility-first mantra. Test accessibility early in test development. So we start with automated testing. Automation is crucial to the accessibility-first development workflow. It reduces repetitive tasks and the potential for human error. Testing can quickly identify accessibility issues and provide full-time reports, same time and money. So as I previously mentioned, my company has put together an accessibility tool that is a free WordPress plugin that can be found on the .org plugin repository. You install this plugin and it lives right inside of your post or page dashboard. It shows a summary of all the errors, warnings and contrast and ignored items. On the left side of the screenshot, it shows a circular progress bar with 83% pass test on this page. Below that, we can see that we have a 12th grade reading level and then some more context on what you're to do if your reading level is too high or too low. The plugin runs 40 different accessibility checks. There's no limits to how many pages your post can be scanned. It runs the readability analysis. It has an ignore feature and all data is stored on your server. It does not go to any external API. In this second screenshot, we're looking at the accessibility checker running inside of a post with the details tab currently active. You see the accessibility issues are ordered from errors to warnings to pass tests. These can all be toggled open to add ignores to. You can ignore this if you've done a manual check and insured yourself that it is in fact a manually reviewed accessibility fix. You can go ahead and put a note in there where you did and you can ignore it. There's other software that can be used to run similar scans. These are typically software as a service tools. You can sometimes call those sassas. It's Monsito poke tech, which runs on the way of API and site improved. These all work offsite, set up an account. They're often premium services. I think all three of these are premium services. There could be limits based on your plan level, but they're full featured. There could be delays in scanning. They typically will scan your page once a week or every few days or once a month. You don't get that instant feedback on accessibility. Those are all great options. Just a caveat on automation. Automation doesn't equal accessible. The only thing that automation guarantees is that you've made accessible anything that can be automated. Some issues must be tested manually. There's browser extensions to help us do testing. These browser extensions live directly within the browser. They're typically private or secure. I don't make these software products, so I can't guarantee they're private or secure, but as far as I can tell, the tests run within your browser. They evaluate the rendered page, the fully rendered page. The downside is that you can typically only scan one page at a time. The results are not typically stored anywhere for you to evaluate later or to generate reports. Probably the most popular one, and probably one you're most familiar with is Wave. Wave is a web accessibility evaluation tool developed by webaim.org. It provides visual feedback about the accessibility of your website by injecting icons and indicators into your page. On this slide, I'm showing a screenshot. The screenshot is of the weather.com website with the Wave accessibility evaluation tool active. The Wave evaluation tool lives on the left side of the screen, and it has a number of tabs, such as summary, details, and so on. Currently active is the details tab, and it shows the errors and contrast errors in the alerts on the page. Wave is pretty cool where you can toggle off the CSS. If there's hidden items that you can't quite get to, you're clicking over here and you don't find it. You can toggle it off, or the CSS off, and it'll just show a straight HTML page with these little error icons all around. The second tool here, which is pretty similar to Wave, is the Accident tools. This is by a company called GQ. We'll be covering quite a few of their tools in this talk. This is very similar to Wave, with the exception that it runs in the Chrome developer tools. You open up your Chrome developer tools, and you would tap over to the Acc's Dev tools. On this slide, we're looking at a screenshot image of weather.com again. The Acc's Dev tools Chrome extension is running, but this time it's in the inspector. I currently have the inspector on the right side of this window. It shows the total issues, and then it'll be details and descriptions about your issues here on the right side. Finally, in the vein of these scanning tools, we have the IBM Equal Access Accessibility Checker. The IBM Equal Access Checker is an open source tool that utilizes IBM's accessibility rule engine. This one also runs in the Chrome Dev tools. On this screen, I have an image of the weather.com website. Again, running the IBM Equal Access Accessibility Checker in the Chrome Dev tools on the right side again. It's split in the IBM Equal Access Checker, split in the two windows. On the left side, you can see the scan issues. On the right side, you can see a summary with the current violations and need to reviews and recommendations. Finally, in the browser extensions, we have the Headings Map, which generates an index of all headings on the page. It provides a quick way to identify out of order headings. There's a screenshot on this slide which shows two browser windows. On the left side, it's a browser window of gizmodo.com with the Headings Map browser extension enabled, showing all the headings for that website. On the right side is a similar window with yahoo.com with the Headings Map running, and all of their headings listed there as well. What you'll notice is there's something wrong with one of these, right? We want to be making semantic websites. We want to have heading orders that are in order, h1, h2, h3, pretty easy. You can see on gizmodo that gizmodo starts with an h2, and then they jump to an h4, and so on, and that seems to be the pattern of their website. Now, I will say this, not calling out gizmodo.com. If you run a wave evaluation tool on gizmodo.com, their accessibility is phenomenal. It's a really accessible website, but their heading orders are way out of order. As you can see on the yahoo website, we've got a nice h1 yahoo home, and then we'll go on down to the page. It's 2, it's 3, it's 4, then we jump back to 3, back to 4. They're very smanted, very pretty, nothing's red on this side, good to go. It matters for accessibility. Screen readers are going to read those out in order, and it matters for SEO as well. Alright, so we're going to get a little bit more technical here. Being accessibility first, we can take a proactive approach inside of our IDEs as well. We can run plugins inside of an ID that I use in most developers, it's the Visual Studio Code. The one plugin that I found the most useful was the Axe Accessibility Linter. So Axe will check for accessibility issues using their library in any like JavaScript based project for HTML or Markdown. On this slide I have a screenshot of some code, it's just one line of code, which is a button that's missing text. So the Axe Linter is showing an error below that, and it's telling me the problem. It says Axe Linter in parentheses button, they ensure buttons have discernible text. So to fix this, what do we need to do? We just need to put some text inside that button, right? Pretty easy. So there's a little bit of a caveat here, right? I myself have not been able to find a current up-to-date PHP Linter that will do these kind of checks on PHP within Visual Studio Code. There are some that are pretty outdated, they're not maintained. So if anybody in this room knows of any good PHP Linters, they'd be happy to talk afterwards. So to be even more proactive, we can move beyond our IDE into GitHub Action. So we print our code inside of Visual Studio Code, we use the Linter to make sure our HTML is accessible. And we commit a merge request to our source, and what we can do is we can run GitHub Actions to do another check on that code before it gets merged into production. So GitHub Actions can be used to automate accessibility tests with code libraries like Axe by DQ, which we've mentioned several times, and then Pali, which is spelled P-A-11-Y. And I put this in here, but a little sidenote. You can also run Lighthouse reports in these GitHub automations as well. I don't know if you know what Lighthouse is, but it runs in the Chrome Dev Tools, it does performance tests, but it also does accessibility tests as well. So in this slide I have an image that is showing a GitHub failed check. It's running an Axe check, and it shows a fail, and it's running a unit test, a custom unit test that was built with an error. So what would happen is this developer would need to resolve these issues and resubmit effects before it could be approved and merged into production. So we have another tool here for testing, which is the keyboard. We're all very familiar with mouse, right? Well, there's a lot of people out there that are very familiar with the keyboard, using the keyboard for navigation. So I want to run through some practical things we can do in our keyboard testing. Use your keyboard to move through any active elements and look for the ability to tab to any interactive element. Button links with the tab key. Nothing invisible or hidden that you cannot see gets focused. Visible focus order follows the order of the page. That's what I talked about. Visible focus outline, and what we typically use in our company is we use a two-pixel solid outline with a two-pixel outline offset. So visible focus outline that sufficiently contrasts with the background. We typically try for a triple-A color contrast. You can use color contrast tools. I think WCAG has one, and you can just do a search. I think Google even has one built right into their search. Buttons should be able to be triggered by the enter slash return key or the space bar. Links should be triggered by the return slash enter key. If a button or link triggers a scroll or opens a modal, et cetera, the focus should shift from the scroll to area or into the modal. If a modal is open, when it is closed, the focus should return to the button that triggered the modal to open. This is a big one, and this is where I see on almost all websites I have accessibility issues that focus state of modals does not go to the right places. Alright, so once we've done our keyboard testing, we can move over to our screen reader testing. You can use either the NVVA for Windows or the voiceover for Mac to listen to elements. I know the first time I used voiceover, it was a little, it kind of takes you back. It kind of scares you a little bit. I don't know if I have audio hooked up to this, but... So it sounds like a computer, right? Just be comfortable with using that. When you're doing your website testing, you jump over, you use your mouse to make sure that a hover is working or that a tab is working. Use your keyboard to make sure it's working as well. Turn voiceover on so you can hear what somebody used in assistive technology would hear as well. So these are the things we want to listen for. Anything that just says button or link, but doesn't say what the button or link does. Confusing or incorrect labels or alternative text. For example, a closed button on a modal that just reads as X rather than closed modal. Ambiguous labels that don't have meaning without the surrounding text. For example, read more, download, learn more. Click here, click here, click here. We're going to click here, user here. Unnecessary clutter. Multiple links in a row going to the same place. Decorative icons next to link text, etc. Sometimes they're butted up right against the text and it just says funny things in the screen reader. In conclusion, when we fully adopt the accessibility first development method, we're choosing to prioritize people first because accessibility first equals people first. That's another tweetable. Got your phones? Alright, go for it. Wait, you've got to be in the picture too. Oh, I've got to be in it. Alright, I'm going to look real down the nose first. Alright, like I said, I'm Steve Jones. I am the owner and CTO of Equalized Digital. You can find me at most places that I want to be found on the internet. At Steve Jones Dev, so that's my Twitter handle, you can find me at GitHub and wordpress.org with that same handle. Equalized Digital runs an accessibility meetup that you can find at equalizeddigital.com. How often do those run, Amber? Twice a month. Twice a month. There you go. And Equalized Digital also runs a WordPress accessibility Facebook group which you can find at facebook.com. So with that, I'd be happy to take any questions. Where are you located? Where are we located? We're located in Georgetown, Texas. This is our headquarters. We're a distributed team. I live in Ohio. I'm going to check her. I don't know about how she says it, but this isn't going to check her. So we can get the captions. You've touched on the accessibility tools a lot, especially. And I want to know, since I know how she uses it, does the accessibility checker at your plug-in also use that for accessibility checks? Do we use Lighthouse? No. Do you use PAX? No. No, we don't. So the Equalized Digital Accessibility Checker, these are all custom rules that we've written ourselves. Does the accessibility checker use the accessibility object model at all? Yeah, I'm not familiar with exactly what you're referring to when you say accessibility object model. The accessibility object model. I mean, it is kind of new all through Safari already, has it? Because one of the guys down here is a senior software engineer at it. But it's strong, it's a bit of a feature and a problem. But it basically allows you to assess accessibility attributes through JavaScript. No, okay, okay. So let me just allow you to work with it. I was just wondering if you have to assess if they check it either way. No, it does not. The accessibility checker parses the HTML of the page and then runs evaluations. So yeah, it's not using the JavaScript library to achieve the checks. But your pricing model. We'll get to that next. Hi. So I'm not a developer per se. I am a graphic designer. And what advice would you have for somebody who is not super heavy on the coding side of things, but I still want to make sure that any websites I design are accessible to people? Exactly. So you would be accessibility first first. First first. So I will admit that some of my talk items was derived out of some of the accessibility first design methods. I think it's put together by Cambridge University. I don't know, don't quote me on that. Yes, so you're even further, you're before us. And I think that there's room too for developers and designers to work together to ensure that we're both meeting accessibility. So I think as a designer, you could learn the accessibility requirements. And a big thing with design is almost color contrast. Just being mindful of the colors that you're using. Running a color contrast on any text you have laying over a background. Got blue text laying on a red background. Of course that's been a fail for the most part. I'm just using that as a bad example. But being very mindful of your color contrast, testing it. And I think even some of the design tools these days even have plugins that will even test that for you. So look for some of those. Fonts. Fonts. The fonts that you use that are readable, the font sizes that you use are important. You want to make sure that, I don't know if you do it like a design brief on what you make. If you're doing web design that you are thinking kind of like a developer when it comes to headings. Like you're thinking that the H1 is probably going to be the logo. And it's going to have some screen reader text inside there that's hidden. And then just being mindful of when you design that H2 and H3 and H4 visually follow in order. Like the H2 of course is bigger than the H3 and so on and so forth. So being mindful of those things, I think those are a few things you can look at. But that's great that you're thinking about that. Are there any specific plugins you would recommend? When I design a website with WordPress, there's a lot that I do right now that's theme and plugin based. If there's any way for me to go in that's not so much on the developer side of things to address some of those issues like you talked about today. So not to keep plugging myself here. But I saw you pitch that hard of me. I'm going to knock it out. So the accessibility checker is not made specifically for developers, but it's made for any kind of generating content inside of WordPress. So when you pull open your WordPress post and you can publish or you can save draft, WordPress accessibility checker is going to run those checks and it's going to show them to you right below, right when that post saves. So you can tab over and you can see all the issues. Now there is a column that shows the code that is the problem. And so for a designer, oh code, I've got to find something else to help. But we're making improvements where we've added an image category. If we're referring to an image on that page, we will show you which image it is. We've got features coming out later that you could just click a button. It'll pop over to the front of the website and it'll highlight that issue on the page for you. Awesome. Usability for accessibility. Exactly. Thank you. Yeah, thank you. Alright, I'm going to preface this by saying, please don't shoot people for asking this question. So like that said, what about the argument that everybody's browser is individual, my wife will like to increase her font size regardless of what website she's going to. So any changes as a developer that I make can easily be overrided by somebody who might have poor visibility and they're already enlarging things. So I'm not going to shoot you. That's a great question. Developers have a responsibility to make websites that adapt to any change that the browser will make. We need to make sure that our text flows, that it's not in a div class that has an overflow hidden. So a navigation has a lot of text and you slide it down too far, or you increase the font size in your browser to your personal liking, it gets cut off. So we, as developers, have a duty to create our websites to adapt to any setting that you would make in the browser. Oh, that's so much work. Yes, it is. Thank you. So the point of life is to be able to use the website, right? Yes. Does this mean I can't use the subframeless font when there are little guns? You know, I mean, I'll say it for one that's awesome, that's hilarious, but now it's probably not a good idea. But if you do that, provide some hidden screen reader text for somebody that knows what that is. So a screen reader will read out, so brandos, gun fodder, you know, I don't know. That's hilarious. Probably we'll get you soon. Yeah, thank you. That's on him, though. I'm not a lawyer. I saw you're a lawyer. Anybody else? Okay, and for my CEO of Egoise Digital, how can I help you? So how do you feel like, like, what was the biggest change for you, or thing you had to change in your actual coding process to start building that habit of testing as you code? Or are you, like, coding and then testing at the end? I don't think it's as technical as a lot of us think it is. I think it's a mindset. I think you have to accept, like, I know, as a developer a lot of times, especially if you're running a small agency or if you're a solo person, right, like if you want to get the project done, you want to get invoiced and you want to move on to the next one, right? I think when developers are required or asked to make some accessibility, you're like, oh, okay, you think of it as an afterthought. You have to shift your mindset that if it's not accessible, it's broken. It has to be done. And as you go along, it just becomes part of the way that you develop. And to be quite honest, a lot of the accessibility issues we make on websites are not that difficult. I guess there's Modals, there's Tabs, and there's Accordions, where those will require a little bit of JavaScript to achieve, you know, a nice accessibility aesthetic. But most of the stuff we do is pretty easy. It's straight up semantic HTML. Anybody else? We've got one here. How long have you been in business? How long have we been in business? Equalized. Equalized digital? How long have you been here? We've been around for about six or seven years. We actually went under a different business name previously. We rebranded to Equalized Digital two, three years ago, 2020. And what is your pricing model? The pricing model for the product, the plugin? For you to redeem a whole website. Oh, audit. Okay. Well, I have to get you in touch with Amber or our other partner, Chris. Sales department. Yeah, the sales department will handle that. I'm a developer. Thank you. Thank you. Oh, we've got another one. I'm not going to shoot you, I promise. Yeah, this is a good question. All right, so we come here, we become educated, we learn, we're developers or agencies. And now we go, oh boy, we've got work to do. What do you suggest you go back to clients and say, you know what? You're not really as good as it should be. I want to charge you to fix your website that I just built you? Yeah, that's probably not the approach I would take. Right, so what do you suggest? So yes, it's an upsell opportunity. I'm not a salesman, but it's an opportunity for you to go back to them and say that we have gained new knowledge and new appreciation for making the website accessible to all people regardless of their ability. We want to bring your company along as well. We want you to be in alignment with this because it's the right thing to do. There possibly could be legal requirements to it. We don't want you to get sued. We don't want you spending money on a lawyer. We don't want you spending money with us, right? So yes, it's an upsell opportunity, but I would use it that we've gained new knowledge. We have this new offering. We would like you to come along with us and we want to help you make your company better. Great. Are there any checklists available in addition to the resources that you listed earlier in your talk to help websites get up to better accessibility? Checklists specifically? Do you have a checklist? If you come tomorrow to do this, we'll test your workshop. Good segue. You will learn how to do it and get a bunch of resources and checklists. Which one? What track are you in? The business track? No, it's in the workshop. It will be sound room or sound stage. I think it's on 11, but I don't know. 11, 11, and 30. That's great. You will get food. Don't worry. All right. We got another one? No, that's all right. So for those tools that you're showing, if you wanted to enforce the audio for the accessibility, say for menus and our plugins, would you be able to provide the audio? No, the audio, they'll read it out to you what you're looking at. No, those plugins don't. On a Mac computer, it's built into the operating system. It's called VoiceOver. And then on Windows machines, they use the NVDA screen reader. The browser tools don't do that. It's built into the operating system or software added on. I just kind of wanted to add something to that. These tools are great for us to test things out, but we don't use them the same as someone who would normally use a screen reader. So what we do is we like to have, for instance, we have a center for the blind nearest that we ask them to test on our sites because then they're being tested the way they would actually be used. That's a question. Yeah, and in my company, you always do the same thing. We do user testing. We've built full WordPress websites that we have. We've had blind users test. We do the same kind of testing. We use a school for the blind as well, right? Yeah, we typically work with Texas School for the Blind, Digital Impaired, or nobility if we want other... You don't necessarily only just want blind people. So sometimes you want to have people with neurodivergence, or low vision, or maybe someone that has mobility issues that are using eye tracking software. So if you are doing user testing, you want to have a wide variety of users. Great answer. I work for a full-service media production company, so websites are just one area that we work in, but obviously they all cross the intersect. That being said, the other side of the team, if you will, photo, video, production, et cetera, do you have resources? Because obviously I know a lot of that content that they shoot photo, video, and create graphic design ends up on the website. So are there resources that I can share with those team members for things such as video captioning, audio captioning, photo, you know, how to name photo elements, or photo files, et cetera, that sort of thing so we can be more accessible, and everyone that's working more streamlined than that. Yeah, totally. Yeah, I mean, I started with the WCAG guidelines that I went over in the slides. Just go there and search for what you're looking for, like, you know, alt text on images, or video transcriptions, and, you know, have a wealth of things to read through. The most similar docs that I showed as well are very good. Like I said, those are unofficial docs. You always want to read from back and make sure that you're doing everything properly. Yeah, that's where I would start. Yeah, Amber can be the only document. Well, I was going to say, I can also connect you with, like, transcription companies or, like, ESL interpreters if you're looking for that, because they're a few from WordPress Accessibility Day and WordPress Accessibility Network. Cool. All right. Anything else? It's got a lot of good questions. Very good. I got asked to give an announcement that the talk that is supposed to be here next got moved to the soundstage. Okay. Thank you, Steve. All right, thank you all.