 Fantastic, we are recording. So thank you all for coming out to my little session here. I'm very excited for this. Just a personal out to start it off. This is my first in person Drupal speaking event thing. So thank you for having me. Thank you for coming. So yeah, we're going to talk about accessibility testing tools, and then some real world best practices and examples of things that I find myself fixing a lot. So yeah. So brief agenda for today. We're just going to do a brief introduction of the importance of digital accessibility. And then we're going to jump into some automated testing tools, some manual testing steps. And then, again, as I said, those common and then a couple more complex accessibility issues and their related remediations. And depending on how fast I talk, we will likely have some time for some questions, answers at the end. I've also got at the bottom left here the Bailey link to the slides. This is just going to be a lot of links to different tools. So if you would like to open that up now, I would recommend it's going to be a lot easier than trying to write down all those links really fast. Some of them are very long. I am a typical lead at Northern Commerce. We are a Drupal agency out of Ontario, Canada. A little bit more about me just to make a little bit more personal here. I have two cats. Those are them, Callie and Ellie. I love to go to concerts. My favorite band is the 1975 Travel, Being Outdoors, Hiking Things, all the things. And yeah, there's my team at Northern, like a third of them. Yeah, I like them a lot too. Been with Northern for about four years now, working in the accessibility space for about three years of that. So I've had a lot of experience in different projects and working with different teams, being designers, developers, project managers, working through the whole accessibility process. So yeah, let's dive into it, shall we? So first off, let's talk about the importance of digital accessibility and why we need to make our sites accessible. Simply put, the humanity of it. It sounds so simple, but it's just something that we always need to remind ourselves that it may be easier to do something one way, but at the end of the day, our websites, our products, whatever we are creating, are for a human. And we want to make sure that everyone has the ability to use our site, use our products in the way that works for them. Next up, the numbers, about two billion people globally identify with having some sort of disability. That's nearly one in every five people. And then also we need to consider people with disabilities that might not be something that they're living with all the time. So it could be a temporary disability or a situational disability. On the side of the screen here, I have a couple of examples, just to get your mind thinking of these different scenarios. So if we look at the hearing line here, of course, you think about someone with a permanent hearing disability. You'll think of someone who is deaf. A temporary hearing disability could be someone with an ear infection. And then situational, could be a bartender or someone in a loud environment. In all of these situations, the person is not going to be able to hear what is coming from their device or whatever software they are using. Yeah, they'll either be able not to hear it at all or just barely. So these are situations where we need to be thinking about how we are presenting content. Next up is, of course, the law. I will practice this by saying I am in no way a lawyer. Maybe the farthest thing from it. So I'm not gonna stand here and try to preach to you about the law. Hopefully if you are in the accessibility space, you can take some time to research the local laws of where you go from, where your clients are from, so on and so forth. Again, as I said, I'm from Ontario. We have the Accessibility for Ontarians with Disabilities Act, which was passed in 2005. You guys here in the states were much more ahead of it than us. So, show it to you. This is probably gonna be my biggest takeaway from this whole presentation. I'm gonna be talking to you a lot about different tools that I use, how I work with things. But it is so important at the end of the day that you are always involving people with disabilities in your testing, in your development, the whole stage of the process. There's only so much that we can do. I can do the reading. I can follow all the steps, do all the research. But at the end of the day, it is not the same as having someone who is using these assistive technologies, using the softwares that we're working with who are living with the disabilities every day. So yes, keep this in mind as I go through this whole process. Let's jump into some automated testing tools. This is where we're gonna get through all the links and hopefully you find some new tools that you can test out and try. So, first we're gonna preface this by automated testing tools are super helpful ways to run through and catch high level issues. They're mainly gonna be catching semantic issues, issues with HTML, they're automated tools. I'm sure you've all heard it a bunch that they're a great first step. We have a bunch of different kinds of automated tools starting here are probably the most popular, I think. If you have heard of any, you have heard of one at least one of these. So first up is Axe, which is by Dequeo. This is a browser plugin that's just gonna let you test the single page or component. And then same idea with Wave, it's gonna run through all the automated issues, present them to you nicely on the specific page that you're in. Oh, and then of course Lighthouse, this just ships with Chrome right in the DevTools. So yeah, all these are just kinda like one-off situations. They're great for working like while you're developing, if any of the developers in the room. So while you're working, just a single click of the button, it'll run the test and you can check it out. Next up, we have some more comprehensive automated tools. So these are tools that are gonna be able to scan through your entire site. I work with a lot of sites that are higher education, so we have a whole bunch of pages. And I do not wanna spend hours and hours and hours going through page by page by page. I'm sure a lot of you in the room can relate to that. So these tools are great for that. Some of these as well, you can even set up user flows. So if you have any interactive elements, multi-page forms, things like that, where you wanna follow through your process, you can go through, set up the user journey, looking through everything like that. I will say these are all paid tools that I have listed here. Most of the comprehensive automated tools like this are going to be paid services. These are the ones that I have worked with and enjoyed. If you want more details, closing calls of each, I could talk about that all day, but I don't wanna waste your time. So if you have any specific questions about any of these, or yeah, wanted to get an inside look, I am happy to chat with any of you afterwards about the specific tools and give you a demo and such. Yes, and then the usual automated testing tools are not great. We are here. As I said a couple of slides ago, we need to make sure that we are making our sites work for human beings. So if we are having these machines, test our sites, they'll do what they can, but at the end of the day, they are just a machine. They are not a human. So we need to do manual testing. So what does manual testing look like? Here I've just done some questions that run through my mind when I am starting a manual test of a site. This by no means is a comprehensive list. This is just the first things that I'm running through as I am testing things on the fly, things like that. So just running through the list quickly. Can you successfully navigate an action, all functionality with a keyboard? Can you tell where the focus is as you're moving through the site? Can you successfully navigate with a screen reader? Hopefully. Will the site still function when you zoom in? What about zoom out? Nothing being cut off. Everything is all good. What about skip domain link? Does that exist? I find that's something that gets missed a lot. So making sure that the user can skip over all the repeated content, usually in the header, and then our usual color contrast, making sure there's no empty links, right across this one a lot, with like mobile functionality, so like your hamburger menu icon, your search toggle icon, things like that. It's easy just to go in there and, hey, I'm just gonna throw an icon on this button, throw some JavaScript at it, but just make sure you have some actual words in there for those that are not visual. And then yeah, semantic HTML, and then all of our favorites, the alt attribute, making sure those make sense, whether they are, need to be a full alt description, more of their decorative, make it empty. Yeah, yeah. So diving in a little bit deeper to some specific steps of manual testing. The first thing I usually like to do is keyboard testing. This is one of the easiest things for me. Usually run this through as I'm developing things. Just simply throw away your mouse. Don't literally throw it away. I would, you know, put it aside. Maybe I'll plug it and make sure that you can access everything. You can function everything. Everything works using only your keyboard. And also making sure that you can follow all the interactive content on the screen using only your keyboard. So when you're tabbing through the site, making sure that it's not jumping from the top to the bottom, or you know, out of a way that would be confusing. Yep, and then last one there is keyboard traps. So this comes up a lot with any like custom modals or pop-ups, things like that. Sometimes the close button is simply tied to the click or just like does it exist. And then, so if you're a user, not using a mouse that's able to click out into the gray area, you cut it, screwed. Because you're stuck in that modal and all you have left to do is refresh the page and then go through all the content and that sounds super annoying. So let's avoid that. Next up we have screen readers. Most common, most popular are Jaws and NBDA. I put a couple graphs on the side here of some interesting things. So the top one on the right here, the pie chart, we can see that Jaws is the most popular by, this was from 2021 by WebAIM, 53% of people that they surveyed reported using Jaws, whereas that's 30.7 on NBDA and then 6.5 voiceover and so on and so forth. I wanna point your attention to this graph in the bottom left. That is the right, not the left. So something super interesting, of course, Jaws has always been the most popular. It was one of the biggest first screen readers out there, great tool for a lot of people. Of course, it is a paid tool that's pretty expensive. So NBDA came out, free screen reader. It's still developing, people are getting used, the people are using it more and more. You can see here, Jaws in the blue line is decreasing over the years and then NBDA increasing. Makes sense, free tool, it's working, they're a competitor. Something super strange last year. I have no rhyme or reason why this would have happened. If anyone has any idea, I would love to know your thoughts as to why maybe. Jaws is back up. After 10 years of decreasing in popularity and NBDA increasing, it kinda just like flipped back and now Jaws is more popular again and NBDA is less. I bring this to your attention basically just to say, make sure that you're not just testing with one tool, one browser, one situation. You can't just assume that your users are going to be using one assisted technology with one certain browser with the newest operating system. You need to make sure that you are testing on a wide variety of scenarios. And something I use to make that a lot easier in my day to day is this tool called assistive labs. Again, this is a paid tool. I don't know if I said this at the top. I am not sponsored by any of these people. I have no affiliation. So this is a screen reader emulator, works really well. It lets you choose between the different assistive technologies. The ones I use most commonly are NBDA, Jaws and voiceover. It also lets you choose between the different versions of that assistive technology and then also different browsers. You can render it on as well. This is great for Firefox, Chrome, even Internet Explorer, crazy, I know. And then that different browser version as well. So it's just kinda like your one stop shop of here, I'm gonna run all of my tests right here right now. Don't need to worry about opening different browsers and softwares and all that. Just great one stop shop. And of course, contrast checker tools. I'm sure everyone's got a favorite one of these. There are so many out there, a lot of really great ones. But I'm just gonna highlight a couple of my favorites that I use on the daily. The contrast checker tools. First one is from WebAIM, which is pictured in the top right here. Real simple UI. Toss in your foreground color, toss in your background color. Spits out the contrast ratio. There's even a slider there. You can change the lightness slightly. If you need to make it slightly lighter, slightly darker. Just don't get in trouble with your designers if you change your color. That does not make them happy often. One other thing I really like about the WebAIM contrast checker is that they also have a link checker associated with that as well. So you can throw in your body text color, your link text color, and your background color and make sure all three of those check out with each other. Next up is contrast-ratio.com. This one is great for testing out colors that have transparency to them. So you can throw in your CSS values there. So like your RGBA, your HSLAs, all those guys and test them there. And then these bottom two are the grid style. So this is where you can throw in your whole color palette and see at a glance what's gonna work together, what's not gonna work together. This is what I have a screenshot here on the right width. These tools I really love using in the initial phase of a project with the design team so that they can see everything that we're working with. But then also with situations where we have clients, content editors working in the system that are able to, let's see if we're using like Comonance, Layout Builder, all that. If the editor has the option to customize blocks on the page and maybe select a background color, change content in the WYSIWYG, that kind of stuff. It's really important that they know what combos can and can't work together, as much as we try to restrict what they can do so they don't mess it up. So having this as a visual is just a quick reference of, hey, here what works and what doesn't work together. You've got them highlighted in the bright red. Yeah. And just another one here, a quick one is heading map. Again, this is another Chrome plugin. One click of a button will show you the whole heading structure of the page. I really like this one specifically because it filters out all of the hidden titles. So anything that is like display none, that your screen reader is not gonna pick up on anyway, it will remove it from the list. So that's great. There's a couple additional resources here that I find helpful. First one is a checklist from Deque. Second one is a checklist from WebAIM. If you're feeling like accessibility audits, where do I start? I am overwhelmed. There is so much to do. And that is like completely fair. This is where I kind of got my start of, hey, here's a list of things that I should be checking. It really just like gets your brain working and thinking and it's a nice intro to auditing sites for accessibility in general. And then same thing for the web.dev blog there. I'll have to do an accessibility review. Just a step-by-step, simple introduction to it all. Of course, these are starting steps. I would use these as inspiration. Again, just like with our automated tools, same idea here. This is not the be all end all. I am a firm believer that there's never going to be one set checklist that is like, hey, fill out this whole checklist and your site's accessible. So much of accessibility comes down to context and being a human, how we as humans are interacting with and interpreting the different product. So yeah, take this with a grain of salt, use it. It's great. And then keep going from there. So that was me rambling with all of those links. Now let's get into a couple of specific examples of issues that I run into on so many sites, things that I fix so often. And then just how we fix those. So starting off with some simple common ones, headings orders, heading order. Of course, our blocks by default are mostly going to be rendering with H2s. This is great. If you are working on something super simple, I have a lot of situations where we have the client is in there using layout builder components, paragraphs, things like that to create blocks right in the layout because change is page to page. So we can't just say, hey, this block is going to always render with an H2. That's going to be a mess. Either our whole site's going to be an H1 and all H2s, or everything's going to be out of order, the whole thing. So we have a couple of different options here. Again, if it's a static block or a place in the block layout, generally we'll go in and just override the template and change that to whatever heading level works. But something else that we've been doing a lot recently for those more customizable layouts with layout builder and such is actually giving an option for the editor to select with heading level. Of course, this requires some training for the editor side. So depending on how competent they are, having extra field that will dynamically render what heading level is placed on the page before that specific block context is super helpful. Okay, next up is keyboard only. So again, making sure that we are not writing any custom JavaScript that is going to rely on someone to be using a mouse. So not relying on the click function. We can do that just by calling out which key we're pressing on 1332 for the enter or the space bar. And yeah, simple as that. This is hopefully something that you would catch if you are doing that keyboard testing. Next up related to keyboard testing is the focus control. So this comes up in a couple different scenarios. One scenario that I run into a lot is with facets. So if you have a view that is reloading with Ajax and facets, because the view is going to actually rebuild those facets, the focus is lost. And so anyone that is using a keyboard only or a lot of assistive technologies, they're going to select an item from the facet. Page is going to reload. The focus is right back at the top of the page. So then they're going to have to go through all of your page again. Maybe if they want to select another facet. Oh no, they got to do this all again. This is a really frustrating process. So we want to make sure that we are being, we're taking action and taking control over where the focus is going and making sure that there's always a seamless experience. Next up, again, if we think about views, Ajax, things dynamically changing on the page, we want to let users know. For a lot of us, if we are, again, I'll use the view, like search view, Ajax facets. And if we select something and the content automatically updates, great, me myself, I can see that. A lot of people can't. So if they are using a screen reader or other assistive technologies, we can utilize the aria live attribute which will notify the assistive technology whenever this element changes. So in this scenario, you update the facet and the number of search results changes to 20 results found. Great, something as simple as that. We'll let the user know that, hey, this search was successful. What I did took action. I'm going to go check out the content now. Great, so those workable, quick, easy ones. Now let's jump into two more complex things that have a bit more functionality that we run into all the time. First, accordions. We love accordions. So there's a couple different ways we can do accordions. This specific example is for custom accordion markup. Of course, you can use the native HTML. Details and summary accordions. But for this example, we're doing custom stuff. We utilize the aria attributes to communicate to the user what the functionality is and what the state of our accordions are. You can see here, we're going to make sure we're using semantic markup, using a button element. And then we've got a unique ID, the aria expanded attribute. This is something that's going to communicate to the user. You guessed it, if the accordion is expanded or not. And that's going to toggle between true and false, giving them a state. And then the aria controls is what connects the actual trigger to the content. This is something that I believe right now only works in JAWS. So maybe that's one of the reasons that JAWS is back being more popular because they have a little bit more functionality. So yes, in JAWS that lets the user jump between the trigger and the content super quickly. And then back on the content here, of course we have the ID to connect to the aria controls from the button. And then we have the aria labeled by, which will simply tell the user what this content is labeled by. And that is linked, of course, to the trigger. Clearly we have tabs, tabs are a bit more complex, but there's a lot of the same attributes and systems that we see with the accordions. So again, that's semantic markup, making sure that we are using buttons and our unique IDs, roles. We have a specific role of tab here. And then for all of our tabs, rappers, we've got that role of tab list. That's gonna notify the user when they get to this element to know that, hey, this is gonna be a set of tabs. You're gonna have to do some interacting here to see the content. And then, of course, the individual tabs have the role of tab. And again, on the individual tabs, on the accordions, remember we had aria expanded. These guys, we have aria selected. Same idea, you're gonna toggle it between true and false depending on which tab is open. And again, aria controls, of course, linking the trigger to the content. And the content in this case is called a tab panel. We have a specific role for that. And then here we're using the aria labeled by attribute again. And here's some custom functionality that we can use for tabs. This, of course, is the single source of truth of you have to do this for tabs. This is kind of like the above and beyond, like, wow, your tabs have so much functionality. I can navigate them in so many ways. So of course, by default, we just wanna make sure that they can be opened and closed and toggled and that they function. In this case, enter on space, and then, of course, unclick. In this example that I've outlined here, the tab panel, so the whole tab list, I should say. So the group of all of the tab triggers, that is what receives focus. And then to navigate between the individual tab items, the user will use the left and right arrows, and then you can quickly jump to the first one or the last one using the home or the end key. So I feel like I talked really fast there, but this is basically the end of it. Yeah, I hope you got something out of this today. Maybe a new tool that you're going to try. Maybe something new that you are going to test. Thanks for being here. The fact that you are here today means a lot. Appreciate you all going on this accessibility journey and making the web a better place. That was so cheesy. That's what I was going to say. Yeah, so again, there's the, like if anyone wants to grab the slides, feel free to chat with me wherever. I love talking about accessibility. LinkedIn's there as well. Yeah, do we have any questions? Hey, sorry, yes. Yes, sorry. So I'm a project manager, right? So the only thing that I can do is make sure that this is something that we're looking at in general. What would you say or do you have any tips for a client or team who says, well, we've done our accessibility checks because I ran it through site and crew and the score is good enough. So we're done with check mark. Since it seems like that is not sufficient, what is, how do you have that conversation or what would you bring out? That conversation at the end of the day just comes down to emphasizing empathy. I was a bit of a litteration there. I'm going to use that. I think it's just reiterating over and over and as I said, this conversation I've had so many times with basically every client is like, cool, yes, you see this number that's either going to be good or bad from this automated scan, but just being really honest with them, like, hey, that's simply an automated scan, that's machine, like that does not guarantee that that's actually going to work for your students. You could focus on, I don't know, depending on the client, you're the project manager, you're more than best, like if it's going to be the empathy route, if it's going to be the money route, I don't like to focus on that, but I lost to you. Oh yeah, literally, like, hey, no, that's kind of a lie, trust me, you could get sued. Trust me, you're going to be losing out on money because what, you only want able to body people to be able to buy from you? That sucks, like, yeah, I don't know, does that answer that? Yes it does. Okay, yes. In my experience as a front end developer in agency life, the only way to make sure that accessibility is still on the radar, and maybe there's other ways, the only way that I've seen is to keep talking about it and keep sharing knowledge. What does that look like in your work? How do you keep sharing knowledge with each other? Yeah, that's tough. I definitely run into that same thing a lot. Sometimes it's easy to get in the boat of like, and I feel like I'm like speaking to an empty room or I'm like, I'm reiterating the same things and that can definitely be frustrating. I think first step is something that I have really worked on over the past couple of years is just being so, I don't know, just so upfront with management specifically, like starting right at the top and being like, hey, this is like super important, you may not see it, but you need to trust me. And they might think you're annoying, that's how. But they definitely have been annoyed at me at times. But just like being at them, every instance of it, like hey, hey, I noticed we just launched this site on this thing, who was looped in on this? What happened? I think we should be sending out a better product, all that kind of stuff. And then on the more like, you and I leveled along the developers, we do like lunchtime sessions where we'll like go over new things. We've got a Slack channel where like, I don't know, I'm just like posting there all the time of like, hey, I found out this today, cool. Or I don't know, sometimes even just to like get people engaged and like, hey, what are your guys' thoughts on this? We have a lot of conversations about, I don't know, common things like, like the last thing we talked about in there was the rule about color contrast on disabled form elements. I don't know, it goes back and forth. Like of course it's disabled, so I guess technically it doesn't really need to meet the contrast thing, but I think just getting people engaged, a lot of people on our end are intimidated by it, I'd say. They're like, this is a whole thing that I don't know what to do, I don't know where to start. I don't know, so I like doing things like this just like putting a single thing in front of you, like those checklists and being like, start here. Cool, let's make this a little bit more digestible. Or like, hey, I'm gonna get you started and just check all the color contrast. And then we'll walk through the rest, but like, you know, dip in the toes in. Yeah, sounds like it's basically a full-time job. It's a full-time job. Yeah, full-time job. Yes, yeah, yeah. Well thank you for that, it's all on me. Yes. Let me give an example first, then I'll ask my questions. So, a while back, big US government site, I come in at the end, check accessibility. Essentially, at the end of the process, they had contrast issues and focusability issues, both. Yep. The both solutions. You have a style guide here that we're supposed to do, you have accessibility law over here that we're supposed to do, you get to choose one. Yep. And yes, late. So the question I have is getting this process started as early as possible at a mock-up level. You know, run through the automated thing almost before you get to anything else. Yep. It's not perfect, it's gonna change, it's not gonna have everything but getting the visibility to the front-side, the designer people earlier or any direction on making it early enough in the process to get the party started. Get the party started, I love that. I think again, it really just comes down to inserting yourself in the process and being assertive about it. Be confident in yourself. You know this is something we need to be doing and if they don't see it, that's, I don't know, that's someone who knows, it's kind of our job to communicate it with them. As far as getting it through the designers and stuff, again, just making those connections, even outside of the project with the designer, being like, hey, is this part of your process or we use Figma Sketch a lot and being like, oh, hey. It kind of feels like it could be on them almost more than- Sometimes we need to spoon-feed them. Yes. There's a bunch of plugins and stuff for Figma and Sketch and stuff, but I'm like, hey, have you tried this out yet? Like, I don't have Sketch on my computer. Can you test this out? Sometimes I'd have to play dumb like that. It really depends on the person of like, anything to get it in front of them. To make it easier for them and to make it be- Exactly. Some sort of just have you done just the bare minimum. Yeah, yeah, some people. I think it's also kind of what you were saying before, you start up with leadership and you make sure that they know, especially as a government organization ever mandated by Congress to be accessible. And I have to say, sometimes it's a stick of like, hey, for my group, we don't build things that are inaccessible, we can't. And you can't get sued. So we've had to sit down on clients and go, this is, we can't launch your site. There's too many accessibility issues and they'll open you up to lawsuits. If they don't get the, hey, this is humanity. Exactly. Sometimes you've got to correct them a little bit. And please think about people. Just keep lecturing about VPAT and like, what happens when something goes wrong until they have suffered so much that they just do the contract. Or send them a couple of articles about how people have gotten sued. Oh yeah, those are always fun. Don't make them listen. Do you want to spend the money now or do you want to spend $100,000 later? Yeah. Check. Yeah, because you have the bad eye, we have to think there's bad actors out there looking for whoever there absolutely is. There's definitely like specific companies that their whole job is just, you know, running these automated scans on sites and being like, oh, here's a random issue. I'm going to file a lawsuit against you now. Hey, give me your money. It sucks. I don't like that at all. But, you know, people, capitalism. Not helping. Jordan. Just to add to the conversation too, on how to get like teams on doing it, it's like, I know we have this whole thing about like mobile first, but it's also should be accessibility first as well. So like, why do it at the end when you could be doing it while you're building the elements so that you're not like going at the end and saying, oh, the whole site's inaccessible and we have a week to launch. And I find that it helps to like, at least our process is we've implemented like accessibility scans along the way of development. So like, you know, say we're part way, we do an initial scan, see where we're lacking, try to fix it, do another one before launch, even do one after launch to make sure that we like, you know, if we didn't catch everything, we can kind of fix all the other bits, but really like putting that in the process of creating the site is really important as well. And then everyone's kind of on the same page and yeah, really driving it home. So is there another thing? We've done this, where we've actually brought our developers and other stakeholders into a meeting where we brought in somebody who uses assistive technology and has them try to use the site. Recently we've done that with our HR site, when we built in a lot of accessibility ourselves, we had a whole group come in and one of them had site problems. They used assistive technology and they'll just sit down with somebody and see what they have to go through. Is it, you want empathy, there's empathy. For real? Well, the thing I will say, since that project and then you make a choice and they're big choices, it feels like this is just a piece similar to semantic markup, that similar to the SEO lever has helped. If you do the right thing early, in general, we get two thirds of the way, it's gonna service all these other values that you wanted at the same time. So that's kind of the carrot. It makes it more SEO friendly if you have alt tags. Exactly. All those kind of really simple things has helped. Those are the major things we normally see is alt tags, fellow contrasts, and not using semantic markup. Are you using it wrong? Yeah, perfect. Do you know of any tools or plugins that we use with CK Editor so that content editors are getting on the spot alerts that for things like, you just went from an H2 to an H5, for example, those types of, I don't know. Yeah, there is one right now, I forget what the name of it is, I'll have to talk in my head, Jordan, do you know? I think it's called, I was like, we've got it all over, so. It's called editorially, but like, Yeah, Editorial A11Y. Yeah. And it kind of does like a scan. There's one of them, I think that's the one that is in the WYSIWYG, and it'll tell you what the errors are. It'll also tell you on the bottom corner of a page. And then just tell them right up, after they save the nodes, like, yep, this is wrong, I need you to fix it. So it's very clear to them what is there. It does require them to click the button. Yeah, I mean, there's a little bit of pressing to them. It'll kind of be in their face of like, oh, I want to get rid of this warning here. Maybe I should fix my header. Well, and it kind of feels like, I would throw this out there, and this is a question for the group, maybe. It sort of feels like there's a piece of this that could be related to CICB. So if you have VHA, it takes picture, and you have result, it's you just get a build, then comes up, now you're objectively failed. Or just even some hints. It feels like that part of the process could be, it's not gonna solve, that maybe it raises its hand and says, there's something there. Yeah, I feel like at the end of the day, it's really like, even if the person specifically who sees that there is an issue, even if they're not able to comprehend it, understand it completely, that's fine, but being available, and having like a Slack channel, whatever, open for people to have that open discussion of, hey, what does this error mean? Or should I be checking this? There should be some sort of scripting. Fire off one of these tools. How bad are we? Something happened. I think that's it. Yeah, let's go ahead. I was gonna make a recommendation for this conversation here. There's XCOR, you can, we have a plugin for Playwrights. If you're using Playwright for your VR testing, you can easily run accessibility tests, and it's gonna test you. Yeah, I think all the access tools are really good. I don't know if all you guys were in a non-session yesterday. She was going over the inline, in the ID tool that they are developing now. I was sitting in a session with it earlier last month, from the queue, and it seems like it's gonna be pretty good. Essentially, it's like automated scan built right in, as we're writing the code, it'll flag things. There's still some limitations with it right now. Well, it's not really in here because I haven't had much experience with it. Mainly because I use PHPStorm. It's not available on JetBrains or anything like that yet. And then there is still some limitations with what kind of files it can test, like. Are there tools yet for tab builders? I'm not sure. Because it feels like everybody, I gotta have an answer to that, but a whole nother discussion. Yeah. But it kind of feels like there should be something in that world that explodes and eventually hopefully it dies. Yeah, that would really help so, but I don't know, don't have a good answer for you there. All right. I have a question. So, I know our devs and engineers do the best they can to pick up on a lot of this stuff, but some of what you're talking about about manual testing and the benefit of having someone who actually has, is differently abled using that. Are there any services or companies that allow you to contract with them to get people? Because we don't have an endless pool of people internally who are differently abled and will be able to test it. So where do I go to find some people who could? Yeah, it feels like there's a business opportunity that's in something. Yeah, there is. Definitely use a lot of companies like that. I would like you to do your research and definitely get some examples from them. Some of our clients work with those other companies as well, which like all the respect to it, like more people lies on it. It's gonna be a better product, but there have been some definitely questionable things that come out of these companies. So I'd make sure you do your research. I don't know, kind of a funny story recently, but I'm fighting with one of those companies right now. I don't even know their name, so I can't talk smack about them if I wanted to. Are fighting with me about making sure the page looks aesthetically pleasing when CSS is disabled. Basically they want me to make everything in tables in the markup when CSS is disabled, but then not in tables because they understand that that's not really the best for accessibility when CSS isn't disabled. I'm like, what are you talking about? I was like, are we in 2001 right now? Who's disabling CSS? Who even knows how to disable CSS? Yeah, like Chrome, even you have to install a plugin to disable it. Exactly, like it's semantic, cool. I get the whole premise of it. DQ does this. Yeah, DQ has teams of people. That's awesome. Yeah, the same company that you just said is awesome. We love DQ, so much. But we worked with them before and had really great experiences shockingly. Yeah, DQ. So it's possible to contract with them from initial build? Yeah, they're super easy to work with, lovely. And I mean, I would have thought that it would be wildly expensive too, but I mean, that's subjective and relative. Yeah, I mean, in the context of a $300,000 build, I didn't think it was actually that expensive. I'm gonna comment and take a look at things, so. Well, if it's less expensive, then get in the suit. Ding, ding, ding. Yes. Yes. Yeah. DQ's also got early great training program. If you have, like, developers, designers, project managers, curiosity testers, basically anyone that has no idea anything about accessibility, they've got a lot of really good courses that I personally have taken that we now have integrated into our company as part of our onboarding process for everyone. So yeah, I would recommend that as well. Probably a little tricky as we work towards a model that's more component-based. So you're building a little piece of thing. Yep. If it could be any stack of them, yep, yep. That's probably a challenge. Yeah, most of our components these days have so many fields of, like I mentioned earlier, like you have just a liquid heading level and all those flags about, like, hey, if you're using this background color and then in the WYSIWYG you're choosing the primary button and if those clash, then you have to add all this extra CSS to make it change it and it's a lot more dynamic we get. We had one project building headers upon it that stripped out the normal A20. Oh. Okay. Okay. Why? Why? Interesting. Yeah, because why'd you, exactly. I'm a little lost, but okay. Yeah. Why'd you do that? Well, it seemed like the right thing to do. I don't think so, whatever. Oh, anyone else? Questions, comments, concerns? Cool. Oh, Jordan, one more. Take us home. What voice do you use for the voiceover? We were talking this morning. You can change the voiceover voice. Personally, I like to use Daniel. He is the man from the UK. He's got a very nice British accent. How fast does Daniel talk? Personally, I only have Daniel set at, like, 60%. Have you ever heard someone who uses a screen reader full time? I can't. It's amazing. How are you comprehending all of this? Yeah. I usually go fast enough that my friends who don't do any accessibility testing lose their minds, but it's still half as fast as people use screen readers every day. It's wild and exact. So they have a Snoop Dogg plug-in now, so everything's fine. No. Really? In voiceover? No. But now that you have all of these plug-ins for Waze and all these other mapping things, plug-ins for that stuff, it could actually be... Yeah, I think they did the Cookie Monster, so that would be a great one, right? Absolutely. Cookie Monster. If you're like, yo, man, that's a tab. That's another tab. Okay. Yeah, I want an accessibility voiceover tool that gives me a hard time. They're really, like, raspy. Like, hey, what are you doing? He just gets on your case about it. What are you doing? Can you even hurt our attributes? Like, come on. Come on. Well, if they could make it a little more fun, maybe get more people helping. I think those need, like, the Karen voiceover. The Karen voiceover? I need to talk to your manager. Yeah, it's amazing. April 1st. Thank you guys. Appreciate you all.