Rachael Yomtoob 0:19 Thank you for the wonderful introduction, Sean. I’m super excited to be here at code word comp, giving my presentation, Introduction to mobile app accessibility. So my first slide, actually, I think Sean covered pretty much all of it, aside from the fact that my favorite color is purple. So I do have a couple photos of me up here with some lovely purple hair, including my three cats that Sean mentioned as well. We’ve got Rosie on the left, Roxy in the middle and Ruby on the right. And today I have actually shorter hair. I’ve got a mullet now, which is still very much purple, and I’ve got some neon pink and green going on today, paired with my DQ digital accessibility is my jam t shirt. All right, so let’s dig into the presentation. So for our agenda today, I will first off, cover what is a disability and what is digital accessibility. Then we’ll talk about the guidelines that exist in the digital accessibility space. And then the bulk of the presentation will be about digging into specific accessibility concepts and how they apply to motive mobile applications. And lastly, I’ll give you some information about automated testing tools that are available to help you build more accessible apps. So I always like to start off with what is a disability? And I like to start with the definition from the CDC. So a disability is any condition of the body or mind, in parentheses, impairment that makes it more difficult for the person with the condition to do certain activities. In parentheses, activity limitation and interact with the world around them. In parentheses, participation restrictions. So that’s kind of a lot. Let that sit in for a second. And this represents the digital, or, sorry, the medical model of disability. There’s kind of two prevalent models of disability. One is the medical model, and the other is the social model. In the medical model, the onus of the disability is more so placed on the person. So think of it as saying, like you this you, you as a person, have a problem, and that is the disability, and these are the tools in the medical system to fix that problem, whereas the societal model thinks of it more as we live in a society that was not built in a way to satisfy the needs of all of our varying different types of people that we have that exist in the world today. So in contrast to the medical definition from the CDC. I like to talk about how the prefix dis doesn’t need to have a negative connotation. One meaning of this is to Twain, which literally means in different directions. So I like to think about disability as not a lack of anything more as disability means people have different abilities. And so I have a quote here from Lawrence Carter, long being disabled does not suggest a lack of anything. So using the word disabled is often it’s important to the community to kind of redefine that and and and make sure that it doesn’t have that negative connotation and that it just means that people are different and people have different abilities, and no one has a lack of anything. So then moving on to how does this relate to digital accessibility? So digital accessibility is the practice of building digital content such as web and mobile apps in a way that allows access for everyone, regardless of any disabilities. So this covers a wide range of concepts such as screen reader support for people who have visual impairments or are blind, and captioning videos for people who are hard of hearing or have auditory processing disorders, as well as different color schemes. And then you’ll see sometimes the use of the numerium Alley a, 11 y. This is a numerium because there are 11 letters in between the capital A at the beginning and the lowercase y at the end. So this is a term that you’ll sometimes use C used for the concept of digital accessibility. Then just to kind of reiterate and think about it from the more statistical side, an estimated 1.3 billion people experience significant disability, which represents 16% of the world’s population, or one in seconds, one in six of us, and this is us to. To stick from the World Health Organization, but if you think of disability more broadly, as I was suggesting, from the societal model or the social model, disability really does affect all of us at some point in our lives. So now I want to talk about why is mobile app accessibility specifically important. So there are more than 6.5 billion smartphone users worldwide, and that’s predicted to continue increasing, as well as WebAIM does a screen reader survey in which 90% of the respondents of that survey said that they use a screen reader on a mobile device. So that’s nearly, nearly all of them. And so if you think about it, just as as the digital world has evolved, mobile has become more and more prevalent. People are able to do more and more things on their mobile devices that they previously needed to do on a desktop or laptop computer. So naturally, people with disabilities also want to be able to use mobile devices. It’s also not just about screen reader users. I have another example here that many people will mount a tablet to their wheelchair. So I have a photo of two people sitting next to each other. One is in a wheelchair, and they’re interacting with each other through a device that is mounted to that wheelchair through a mobile tablet. So now that we’ve kind of set the stage for what is disability, what is digital accessibility, and why is mobile app accessibility important, let’s talk about the guidelines that exist today to help us build accessible mobile apps. The first guideline that I will talk about is the Web Content Accessibility Guidelines, often referred to by its acronym WCAG, or WCAG, which is how I’ll refer to it, which is the kind of gold standard for digital accessibility guidelines. It’s the most widely adopted and has been around the longest, and it is authored by the Worldwide Web Consortium. So the W, 3c, so in, in to, just to kind of describe how it works, there’s, there’s different versions and levels of WCAG. So the versions the, the most, the oldest, still used version today would be WCAG two Dotto, which was released in December of 2008 and for some context when it comes to mobile apps and mobile devices, iOS came out in 2007 and Android came out in 2008 so WCAG 2.0 really didn’t have any opportunity to consider mobile apps or mobile devices or anything like that, because it was under development and not widely adopted yet. So then WCAG 2.1 was released in June of 2018, so 10 years later, and what 2.1 is, it includes all of the criteria from 2.0 and adds additional criteria on top of it. So some of those criteria were more mobile focused since the mobile apps and mobile devices had gained so much popularity they were now be, now being considered by the W, 3c in the the the web accessibility guidelines. So kind of same thing happened with 2.2, which came out in October of 2023 so last fall, we added more criteria on top of 2.1, and 2.0, so then, now, once we have the different versions, we also have levels. So each version of WCAG has different levels, and each criteria falls within a certain level. So double A is seen as the group of criteria, and WCAG that is the standard that should be complied to level a would be less than that, so fewer criteria, so that would be like almost the bare minimum. But really, people shoot for double A and then triple A is additional criteria on top of double A that is more so seen as extra credit. So it’s not often what people or what enterprises are striving for, they’re usually striving for double A as opposed to AAA.

So as I mentioned, that’s the Web Content Accessibility Guidelines authored by the W 3c the web web web web web. So you might be wondering, you know, mobile apps are built with underlying technologies that are quite different than the web. We have on the web, we have HTML, we have CSS, we can we have Aria, but in mobile apps, native mobile apps, we have things built with Swift for iOS and Kotlin for Android. How does that factor in. We don’t have CSS, we don’t have Aria. How do these guidelines work for mobile apps? So there’s a couple of groups out there on the W, 3c, working on this. So one of those is the mobile accessibility task force, which historically kind of focused more on mobile web. So. Viewing websites or web apps in a browser on a mobile device and accessibility guidelines focusing there. However, within the last year or so, there’s been a new leadership change, which they are now actually focusing more on native mobile applications, as opposed to mobile web. However, that task force is only able to kind of create their own secondary document to WCAG. They aren’t able to add notes directly to WCAG or contribute new guidelines or anything like that. So they essentially the the the power of the task force is very limited in what they can provide to to WCAG. Then we have the w the WCAG two ICT Task Force, in which ICT stands for information communication technologies. So this task force aims to provide translations or documentation on how to apply WCAG to any any non web technology. So that does include mobile apps, but it also encompasses other things, such as desktop apps, PDFs, kiosks, etc. This task force does have a bit more power, per se, because they are able to add notes to the existing guidelines. So they still can’t create new guidelines, but they are able to add documentation about how existing guidelines should apply to the separate platforms. But it will end up being a bit still generalized, since we are still trying to encompass multiple technologies, not just mobile specifically. And so that task force also doesn’t really create guidelines that are specific to mobile. However, on the other hand, outside of the W 3c we have accessibility recommendations from Apple in the human interface guidelines, and Android also has a developer accessibility guide. Whereas these are less guidelines and requirements, they’re more so recommendations and advice on how to build accessible applications. They don’t have the same kind of legal weight as the WCAG guidelines do. And then I just did also want to include a resource that provides information and descriptions on how and code snippets as well on how to apply WCAG guidelines to mobile apps. That is the app Foundation, that’s a nonprofit group from the Netherlands that does a lot of great work on mobile accessibility. So now I’ve talked a lot about the guidelines, and I also do want to note that this does translate into legal landscape. So obviously, I wish everyone was developing apps in an accessible way, just out of the good of their hearts because it’s the right thing to do. Unfortunately, that’s not the world that we live in. So in a lot of cases, legal risk and lawsuits is a motivator for building accessible apps. So I do want to note on what that looks like, but I am not a lawyer, so this is not legal advice. This is just my understanding of how the legal landscape for mobile app accessibility plays out. So in the us all, most of the lawsuits for accessibility, or digital accessibility of mobile apps do reference back to WCAG, as I mentioned, as opposed to referencing apple and Google’s guidelines. They do reference back to WCAG, and then in Europe, there’s the en 3015, 49 which is a European standard for digital accessibility, which does add some new guidelines and things that are additional for mobile apps, specifically on top of what is available in WCAG, but it has not been widely adopted as much or as enforced in lawsuits in the same way as WCAG has in the US. However, the big news these days is the European Accessibility Act, which will enforce the en 3015, 49 with a deadline of June 2025, so enough of the legal worrying stuff. Now I’m going to talk about the technical accessibility concepts. This is what I really dig into and I find most interesting. So we will start off with some of the more simple concepts and go up to some more complex concepts. So starting with text alternatives, this is a accessibility concept that I found to be pretty widely understood on the web, that it’s when when you have an image, you need to provide a text alternative so that a screen reader or assistive technology user is also able to consume the content of that image. So I have provided the actual text from WCAG here, which reads all non text content that is presented to the user, has a text alternative that serves the equivalent purpose. This is a criteria that pretty much directly applies to mobile apps. It’s commonly referred to as alt text on the web, but in iOS and Android, there’s different technical terminology that’s used. So on iOS. It’s called the accessibility label, and on Android, it’s called the content description. So as I mentioned, this is one that pretty straightforward applies, just has a slightly different terminology on the mobile technology side of things. And I do have a screenshot here of a kind of sample application that I’ll be using to illustrate these examples. It’s a e commerce style app called chic boutique, so the home page has the title of the store with a search field and then a like main header image, as well as some other other icons and elements and controls that I’ll describe later on. So another concept that pretty easily translates to mobile is color contrast. So WCAG states that the visual presentation of images and images of text has a or, sorry, the visual presentation of text and images of text has a contrast ratio of at least 4.5 to one. So this is important for folks who have low vision or color blindness. If there’s not enough contrast between the foreground and the background of the text, it will be difficult to read and understand that text. And so I do have an example here where the there is an exception for large text. So in WCAG, if text is considered large, which means it’s either above a certain size or bold, that text can then be tested at a lower standard of 3.0 to one, instead of 5.0 to one. But this is really difficult to to test for for mobile applications, because you don’t have access to the DOM in the same way that you do for web. So if you don’t have access to the source code and those actual color codes, you have to do a lot of taking a screenshot and doing color picking and running color analyzers that way, which is going to be a bit less accurate, and you also have no real way to determine if it’s bold, unless you have that source code either. So in my example here, beneath that, like sort of main image of the current collection at shake boutique, there’s a heading, most popular, and then there’s another text element, 56 items with an arrow. And I have a zoomed in screenshot of that which most popular is black font on a gray background. But the 56 items is a dark gray on a lighter gray, kind of showing how it would be difficult to be able to read this if you have low low vision or color blindness, the contrast is too low to meet the requirement for WCAG. So next we have headings. And so WCAG describes headings as information structure and relationships conveyed through presentation can be programmatically determined or available in text, um. So what that really ends up boiling down to is on mobile devices, headings allow assistive technology users to navigate the apps more quickly, or that navigate the content more quickly. Same, um, same can can happen on the web as well. However, the the big difference is, on the web, you have six levels of headings, so you can start with your h1 and then you have H twos with H threes nested in them, and so on and so forth. Whereas for mobile, we don’t necessarily have that as much. On Android, we still to this day, only have one level of heading, so it’s just heading. There’s no level one, nothing like that. IOS introduced multiple levels of heading in iOS 15, but it’s not yet well adopted. So this is one of those kind of key differences between the web and specifically Android that they’re fundamentally the accessibility features don’t line up, so the guidelines need to be interpreted to make sense for mobile.

Another criteria, this one was actually added into that one with mobile more so in mind. So this is from WCAG. The content does not restrict its view in operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. So as I want to harken back to my image before, of two folks interacting with a tablet mounted to a wheelchair, the screen orientation rule is important, or sorry, the screen orientation accessibility concept is important because many of those folks, their tablet will be mounted in a fixed orientation. So if your app is only available to be viewed in portrait mode, but their tablet is mounted in landscape mode, then all of the controls. And views on the screen would be sideways for that user, so it’d be very difficult to use. So I do have a couple screenshots here illustrating the chic boutique app looking very well designed in portrait mode, but then in landscape mode, none of the views have changed, so everything is 90 degrees horizontal as opposed to vertical another concept that is pretty widely actually adopted on mobile devices is increasing the font size. So when, whenever I talk to folks about mobile apps and mobile accessibility and or I tell them, that’s what I do, they’re like, Oh yeah, you know, I increase the font size on my phone. So this is a really like I mentioned, well adopted feature on mobile devices, so, but it’s interesting because it doesn’t really map well to the guidelines around it for coming from WCAG. So WCAG reads except for captions and images of text. Text can be resized without assistive technology up to 200% without loss of content or functionality. So this is important for folks with low vision. Often times, increasing the font size is allows folks to be able to read something on screen if they have low vision, varying types of low vision. And so the the part where this doesn’t really line up is for example, on iOS, Apple has specifications for font size in their human interface guidelines called the dynamic type size specifications, and these don’t line up with this 200% goal that WCAG sets out so on on an iOS device, you have the ability to increase the font size, so it starts at the default size, and then you’re able to increase it up to much larger than 200% however, all of that text also doesn’t scale at the same rate. So in, in Apple’s dynamic type size, if you have a heading that’s already large, you don’t want to increase increase the heading so much so that it takes up the entire screen. So the dynamic type size specifications account for that, whereas the WCAG criteria states that all text should be able to increase 200% so this is one of those ones where the WCAG guideline and the guidance from Apple doesn’t always match up. So there’s a bit of gray area in how you want to interpret accessibility guidelines for mobile apps. So the last concept that I want to talk about is touch target size and spacing. So there was a criteria added in 2.1 for target size, which was geared towards mobile apps. However, it only landed at AAA. So as I mentioned a lot of folks, their standard that they’re trying to conform to is WCAG double A. So they’ll leave out the criteria that are triple A. However, the criteria reads the size of the target of pointer inputs is at least 44 by 44 CSS pixels. So first of all, as I mentioned, we don’t have CSS pixels on mobile apps. In native mobile apps, however, thankfully, this is a one to one conversion. So on iOS, we have point so 44 pick CSS pixels can translate to 44 point. And then in Android we have DP density pixels. So same thing, 44 CSS pixels, 44 DP. However, Apple and Google both do have something to say about this in their guidance. So Apple aligns with WCAG by saying, Give all controls and interactive elements a hit target that’s large enough, for example, on touch target, on touch screen devices, a hit target needs to measure at least 44 by 44 so this aligns with what WCAG recommends at AAA, Google sets an even higher standard. We recommend that each interactive UI element have a focusable area or touch target size of at least 48 by 48 larger is even better. So this is one of those ones where, as I mentioned, Apple agrees with WCAG, but WCAG says it’s only AAA, and then Google is is setting an even higher standard. So it’s like, well, what is, what is the right answer here, um, there’s, there’s a lot of gray area in the space. And then to add on top of that, with WCAG 2.2 there was a new criteria at double A introduced, which, which I didn’t mention previously, but the WCAG 2.1 double A criteria is 24 by 24 CSS pixels, which, to me, is too small for a mobile device. It’s just simply, simply too small. But with 2.2 they introduced kind of middle ground between 24 and 44 which says it can be 24 but we can also incorporate the spacing into this. So the criteria reads the. Size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where spacing undersized targets, those less than 24 by 24 CSS pixels are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each the circles do not intersect another target or circle for another undersized target. So as I’ve said a couple times, a lot of the like that’s pretty dense. A lot of the guidelines in WCAG is very dense because it’s very thought through, very meticulously, but it can be difficult to understand what they actually mean. So there is a diagram here that I’ll explain just a second. So here we have a set of six icons with bounding boxes around them. And so in the first example, all six icons are contained within their bonding bounding box of 24 by 24 and those are all right next to each other. So this satisfies the criteria. Then in our second example, our icons have a tighter bounding box of 20 by 20, but there is a four pixel gap between each icon. So this also passes because you can draw a circle around each center of the icon and they will not intersect. And then, in the last example, the bounding box of our icons are 20 by 20 and they are touching each other. So when you draw those 24 by 24 circles, they intersect. So this does not pass the criteria. Actually, one more thing to say on this. So you’re probably thinking like, oh, wow, that’s a lot. Like, that’s really confusing. Like, should I do 48 should I do 24 should I do 44 I would honestly recommend the level triple A 2.1. Criteria, because 44 by 44 to me, makes the most sense on a mobile device, if you’re thinking about a physical finger tapping an icon trying to make sure that they’re not interacting with the wrong control. 44 seems like a reasonable size. However, these are the guidelines that exist, and so it’s always a balance of adhering to guidelines and creating the best end user experience as well. So I know I’m almost at time here, so I just want to wrap up by sharing some resources that can help you build more accessible mobile apps. So there are free tools from both Apple and Google. Apple has a tool called the Xcode accessibility inspector. So that’s within the developer tools in Xcode, which allows you to inspect and see the assistive technology properties and then also run a small audit for accessibility issues, and then you’re also able to run that audit with the XE UI accessibility audit framework in your UI tests as well. For Android apps, the Google accessibility scanner is available on the Play Store, which allows you to scan any app on your Android device for accessibility issues, and then those same rules and those same testing for same issue detection is also available for espresso through the accessibility test framework for Android. These tools are the are built by the Platform Developers, platform owners themselves. So it is guidance from Apple and Google on finding accessibility issues. And then a small pitch for me at dq, we have accept tools mobile which allows you to do those same things test. We have two formats, the analyzer, which you can test any app without access to the source code, and then we have the SDK, which can integrate into your automated UI tests. And we take a bit more focus on WCAG and compliance and providing results that will help you adhere to the guidelines that I mentioned today. And with that, thank you all, and I think we will have some questions and answers.

Sean C Davis 29:02 Yes. Thank you so much. Rachael, that was great. You covered so much. Went so deep. I think this it’s it gives me a ton to think about, and I’ve got a few questions lined up ready to go for you folks in the audience. If you want me to ask any more, drop them in the chat or in the questions section to the right side of the chat. So first I wanted to talk about what in my experience historically, it seems like devs are constantly under pressure to move really, really, really fast, and that what I often see is that accessibility and kind of performance, in a lot of ways, tend to be two of the last things that we were we just we shoved them to the end. We’re like, yes, we will do that if we have time, but then there’s never actually time to do that. And so what I’ve seen is that the way you get that time is by making a. Arguments for it up front and saying, we need to carve this out. And I’m curious what advice you would give to folks. I mean, aside from you, did mention that there are legal implications in some scenarios. But aside from that, what other advice, or, yeah, information, could you feed developers to help make this a priority to what if they’re going to have that conversation with their boss or their product manager or whoever it’s going to be, what should they bring to that conversation?

Rachael Yomtoob 30:32 Yeah, that is a great question, one that I get a lot, and so you’re right. I did mention kind of, I like to think of it now in three, three kind of categories. So you have one, you know, convince someone to do accessibility because it’s the right thing to do. Convince someone, you know, this is the right thing to do for our users, and that’s why we should dedicate time towards this. Reason number two would be increased revenue. So you can take the angle of that, that 16% of users that I kind of mentioned with statistics, or whatever statistic you want to grab about digital accessibility or people with disabilities, and say this is, you know, X percentage of users that we are missing out on right now because they can’t use our app. And then correlate that to x, x many dollars. And then I like to say, then the last one is the legal I will say, right now, the really compelling argument about the legal thing is with the EAA, anyone who does business in the EU is held to that standard. So think of the GDPR and all the cookie banners you see. Now that’s happening with accessibility, essentially. So those are the three main motivators to kind of discuss with someone when, when you’re talking about why accessibility is important and why we should take time in our sprints and take time to, you know, incorporate accessibility testing or accessibility you know, skill set learning trainings into our work days.

Sean C Davis 32:07 Yes, definitely. Okay, it makes sense, and that 16% number is significant. I mean, that’s a, that’s a, that’s a big number. Now, if you’re Can, can you measure retroactively either? I mean, you can, because, of course, you can measure like, folks who landed on your page and dropped off, but I, I’m guessing that there’s, there’s more like, well, there are privacy implications. So you you could, you can’t like correlate those things necessarily, but you could, you could study things potentially, like, well, how many people are hitting this page and then not converting in one way or another?

Rachael Yomtoob 32:42 Um, of my colleagues, Matthew Shepard, does a great job about and he has lots of content that he’s done at conferences and whatnot about correlating accessibility into those metrics. And how do you tell the story to leadership about why accessibility is important, and using those like conversion metrics, just like you mentioned, and just treating accessibility bugs as if they are just like any other bug, right, like it means a user can’t do a thing. So why are we not caring about these users just because they have disabilities, versus users that don’t have disabilities? And

Sean C Davis 33:20 then, based on those last couple slides that you have, it sounds like you can, you can. I mean, you can automate it to a portion where it’s more like it’s, it’s, you can run tests, and then you can see what’s failed, and you have to fix those. Have you seen? Have you seen? I mean, we’re talking about AI all of the time. Have you seen anything in the realm that is kind of coming in and helping us make those fixes so we’re not doing as much of the manual coding?

Rachael Yomtoob 33:52 Sure. Yeah. So as with anything in today’s day and age, AI is a big topic in accessibility. So maybe one thing that I will warn against is the concept of overlays that use AI and they will fix everything for you magically, if something sounds to be too good to be true, I think it is, however to your point, are there tools that we can use to that incorporate AI to build more accessible code. One thing that I can talk about here at DQ is we have what we call AX assistant, kind of in in beta, which is a, you know, an AI, a conversational AI tool that is trained on our wealth of digital accessibility knowledge, whether that’s our training courses in Deque university or our 1000s of assessments that we’ve done on websites for accessibility and you can and you can give it code, and it will also incorporate our linter that links for accessibility issues as well. So that’s one tool that we’re working on. Um, that I can speak to here at dq, that I’m excited about. I’m sure there’s other tools in the space as well. Um, one of my big fears is that with so much of the web being inaccessible today, and so many AI tools being trained on what we have today, we’re just exponentially making the problem worse. Um, but I think that there’s a lot of good people out there that are also learning about AI and how to use it effectively and ensuring that that problem doesn’t occur.

Sean C Davis 35:27 That’s great and great to know that it continues to get better and improve, for sure, and lift, lift the experience up for all users. Was going to ask you next. So there, there are, you mentioned the levels, the A, double A, triple A. And as you were talking about that, I was thinking through, you know, do you, do you have approach for, is it? Is it kind of like a framework I’ve seen before, as we’re, you know, say, getting close to a launch, it’s like we must do these things. We should do these things. We could do these things. Does that kind of correlate to those levels, or does it? I mean, are there specific features? Basically, what I’m trying to ask is, yeah. How do you draw the line between we ask, we have to do this. This serves the bulk of folks who deemed these accessibility features versus, if you compare it to, say styling of a website, that yes, if it’s if it’s structured well, and it’s not broken, and I can do the things I need to do, then it works fine. But I could also add all these fancy animations and sort of, is there a, is there a correlation there or, you know, but, yeah. I mean, how do you think about those applying those levels to your site?

Rachael Yomtoob 36:49 Yeah, so there’s also another dimension of impact. So how, how much does this criteria impact, or how much does this issue impact your users, and that’s something that in our tools at dq, all of the issues have have an impact associated with them. And actually a large part of what we do at DQ is help organizations prioritize their issues, right like our goal is to work with organizations to build a sustainable Accessibility Program, or accessible, accessible development program as a whole. And if we just dumped a bunch of issues on you and said, go figure it out, that wouldn’t work very well. So that’s actually a whole a big part of our job at DQ is helping you prioritize and figure out which issues should be tackled first. One of the things that I do want to point out is the concept of shifting left. So shifting accessibility left in your development process, the earlier you think about it, the less it’s going to cost you. We have another statistic about, you know, like rev like the cost of finding a defect in production versus finding it in design, and how much more time and resources you spend fixing issues after the fact. Actually, screen orientation is a great example of that one. That’s one that a lot of businesses will decide at the jump. They’re like, we’re only doing portrait, and then they ship it, and then we’re like, hey, you need to do landscape. And they’re like, we can’t. The infrastructure doesn’t support that. So, yeah, testing frequently with automated tools to find those issues that you can easily and quickly find and also often quickly fix, and then doing that iteratively in your development process, not not letting it slow you down, and then just feeding those bugs in as you would, any other bugs that you find from your customers or from your other tools, like your security scanning tools that say, Hey, you need to fix this security bug, kind of same thing. But then my the other note will is that manual accessibility testing is still going to be important at the end of the day, there’s there’s, you can’t catch everything with automation. You need the human touch of how human interacts with it, with a device and with a digital property. So you still need to do that. Just automate as much of it as you can, to iterate quickly, but so then you can do the full manual audit less frequently. That’s that’s kind of my whole philosophy and methodology. There.

Sean C Davis 39:19 Love that do.