Shifting Accessibility Testing Left with LambdaTest and Evinced

The full transcript

Kavya (Director of Product Marketing, LambdaTest) - Hi, everyone. Welcome to another exciting session of LambdaTest XP Series. Through XP Series, we dive into a world of insights and innovation, featuring renowned industry experts and business leaders in the testing and QA ecosystem.

I'm your host, Kavya, Director of Product Marketing at LambdaTest, and it's a pleasure to have you with us today. Before we start, let me introduce you to our guest on today's episode, Kevin Berg.

At Evinced, Kevin leads the Solutions Engineering team and helps leading enterprises improve and accelerate their digital accessibility efforts. Before Evinced, Kevin worked with Sauce Labs for about six years in Global Solutions Engineering.

In today's episode, we will discover why detecting issues early is crucial and how Evinced & LambdaTest Integration provides a scalable solution for enterprises.

So let's jump into today's episode. Kevin, why don't you tell our audience a bit about yourself and then share your insights?

Kevin Berg (VP of Solutions Engineering, Evinced) - Thank you so much. I'm so pleased to be here. I really appreciate being hosted. Yeah, my name's Kevin Berg. I'm a passionate tester and have recently, for the last few years, jumped into the accessibility space, which has been really exciting. I love being in the accessibility space, knowing that we're doing good, trying to make the web and mobile applications accessible for everyone.

So today, I was hoping to talk a little bit about Evinced and then talk a little bit about how our partnership with LambdaTest works so well and helps our customers achieve a higher level of accessibility testing with the two products combined. So for those of you who might not be super familiar with Evinced, we are an accessibility technology company.

Kavya (Director of Product Marketing, LambdaTest) - That sounds great. Yeah.

Kevin Berg (VP of Solutions Engineering, Evinced) - We are focused on building accessible technology only. And that's a little bit different from perhaps other accessibility companies out there who are primarily based on services, you know, people doing manual audits and things like that.

And that is a really important part of the accessibility journey, just not our business. We are focused on the automatic detection of accessibility issues as early in the pipeline process as possible. We want to follow in the footsteps of functional testing a few years ago that shift left security testing that has more recently shifted left.

And now there's absolutely no reason why accessibility can't be the next thing that we are able to check early and often to fix issues faster when they're cheaper and easier to fix, just like we would with any of those other things.

So one of the things that separates events is just how our engines and our technology are a little bit different from those others out there. So to do that, I'd like to go ahead and just run through a quick example of how our technology is taking a modern approach using modern technology to solve the accessibility problem.

So I'll go ahead and share my screen, and we'll jump into it just quick, for example. And then I'd like to show how we can use that very same technology and add the power of LambdaTest to exponentially increase our coverage.

Alright, is everyone able to see my screen?

Kavya (Director of Product Marketing, LambdaTest) - Yes, yeah, it has loaded.

Kevin Berg (VP of Solutions Engineering, Evinced) - Fantastic. All right, so this is our example site. It's meant to emulate just a travel site where you can select the type of vacation, where you want to go, select when you want to go, and then click the Search button. So, to get started with a baseline, I'm going to fire up a legacy accessibility tool that you might be familiar with, like Google Lighthouse.

So, to do that, I'll just start up here and analyze and run a scan. And this uses a tool called Axe Core under the hood. And Axe Core, it's a very nice tool. I don't mean to disparage anyone. But the way it works is by only analyzing the underlying HTML of the website that we're checking.

It essentially checks to see if anything is missing. And so while, you know, back when websites were a little bit more static, and we were coding them during HTML, this was an acceptable approach.

However, modern web development no longer provides a high enough level of coverage to ensure that the sites are accessible to all users using assistive technology, especially those who might be dependent on a screen reader or keyboard entry for navigating through a website or mobile app.

And so, through this analysis, we've been given a score of 100, meaning that Axe couldn't find any accessibility issues, but the problem is that this site is completely inaccessible. I'll turn on my keystroke visualizer.

If I were to emulate the requirements of a keyboard-only user, I would expect to be able to use my keyboard and tab through and be able to select all the elements and just use this website as it's designed.

However, if I hit the tab key a single time, you'll notice that I wasn't able to get to the first drop-down or the second drop, and I skipped right to the date picker. And I can get through the date picker, okay, but I'm also not able to get to the search button.

As I tab back and forth, we're on this calendar icon. And then if I hit the tab key again, we jump back to the, jump down to the bottom of the page in the footer. And so, if I were a user trying to use this site, dependent on keyboard entry, the only thing that I would be able to do on this website is select a date.

I wouldn't be able to fill out where I wouldn't be able to execute a search. I would be completely blocked from using this website. And so that's where events take a different approach and where we saw that there was a really dire need in the market for technology that can just do better.

And so the way that events work is instead of just looking at the code, the first thing that events do is to analyze the page to understand how a user is meant to interact with it. And so we use modern technology using things like computer vision, advanced algorithms, AI in certain cases, machine learning to understand, to model the page and understand that, hey, there's a top-level heading here.

There is a form with a couple of drop-downs, a date picker, and a search button, and then some second-level content. And so the idea is that if the technology knows ahead of time that this search button is a button that the user is meant to interact with and click on and is integral to the functionality of the site, then there's a lot that we know about accessibility as well.

We know that it needs to gain keyboard focus. We know that it needs to interact with the screen reader appropriately so that the screen reader users can interact with the page as well once we have that knowledge and context, we have a set of expectations when we then look at the HTML code.

We're expecting to see an HTML button tag or the very that has all of the built-in accessibility to help make these things possible, or at the very least, we're expecting to see the element attributes that would comprise that same functionality. And so when a Vince technology doesn't see the appropriate attributes or code or semantic HTML, we can say with certainty that there are accessibility issues there.

And so, just to show it, I'm going to start out by just flashing our Webflow analyzer that'll tie nicely into how our automation SDKs will work seamlessly with LambdaTest. And so I'll just start this off, start a new session here, and this will just show how we can flag these types of issues where other technologies, Google's accessibility, Lighthouse tool does not.

So, in fact, while all three of these elements do have issues on them, they actually have two issues. One is keyboard accessible, of course, meaning that we aren't able to get to these elements and interact with them using a keyboard. But the other one is an equally critical screen reader issue where the elements themselves are not declaring their role to the screen reader.

And so, in many cases, you're not able to interact with them using a screen reader. They'll just be read out as text, and you're completely blocked as well. So this is the key. You're able to shift a significantly higher amount of accessibility coverage, as far left in your pipeline as possible, with the ability to detect issues that are impacting users the most dependent on accessible assistive technology.

And so, with events, we're able to do that; this dramatically reduces the amount of manual testing required for accessibility and helps increase velocity in all aspects of your development process. So this is how the events technology is different from pretty much anything else out there on the market.

We can use this same technology as part of our functional testing flows with the power of a tool like LambdaTest that allows us to scale horizontally and across a number of different browsers, devices, and screen sizes to ensure that we're comprehensively testing for both our functionality and accessibility as well.

So to integrate with our functional tests, the event supports all the most popular frameworks. And I know LambdaTest does as well. We're discussing things like Selenium, Cypress, Playwright, all of the major players, and WebDriver IO.

If you're using any of those frameworks, you can very easily integrate events, and we can add them to your existing LambdaTest test scripts with just a couple of lines of code, and we can add accessibility scans to your tests as well. So for the example purposes today, I'm just gonna bring up a Selenium example and an Appium example, as those are still the most common frameworks that we see today.

And I'm just gonna see, this is just a normal LambdaTest script that I'm running. I've got a couple of tests in here that go to that same example site, but let's just look at what changes we need to make in order to run on LambdaTest and add accessibility to LambdaTest. And really, it's essentially three lines of code.

First, we would just import our evinced SDK with our package management tool, whether that's Maven Gradle or NPM, if you're using a JavaScript framework. And we would just add, once we've done that, we just add a couple of lines of code.

Here we just add our driver wrapper, which doesn't impact any of your existing functionality. Your tests will run just as they always have. We just add the libraries we need to scan for accessibility. And then the real key is what we call this driver.evstart method. And just to note, this is in our before hook.

So this is before any tests have run; we call this the EV start method. What this does is it starts the advanced accessibility detection engines running in the background, where we detect automatically, through the test framework, any page loads and any dynamically loading elements, any interactions on the page that would trigger a new element to be added to the DOM any new page loads as we walk through our flow, and essentially, we will continuously scan for accessibility.

This is somewhat different than accessibility tools that have integrated with functional test frameworks in the past. One of the ways it does that is if we go down here and look at the test code itself, there's absolutely no reference to accessibility at all. With events, you do not have to interact with your test code, which is important for a few reasons.

One is the initial setup. You don't have to go through 100 different tests and add static scans line by line as you have with previous tools in the past, making implementation super easy.

Maintenance is also incredibly easy because as the application changes, you don't have to worry about going back in and moving those static lines around to make sure that you're getting appropriate levels of coverage. In addition, if you have new tests, you don't have to worry about adding accessibility.

All you have to do is make sure that as many tests as you need, whether it's one, a hundred, or a thousand, to get appropriate application coverage are in the class or tagged appropriately, and they will automatically be scanned for accessibility issues.

Another area in which we've dramatically improved this technology is in the reporting aspect. In previous tools, where we went line by line and had to add static scans, those static scans would create their own individual report. And so, from a single test, you might end up with eight or 10 report files that you then had to consolidate, de-duplicate, and try to extract the value from.

But with events, after your tests have run, we just call a single line called driver.evstop, and we are able to generate a single deduplicated report object after your tests have finished. And not only can we generate the report, but we also have access to that report in code.

So this report object is essentially just a JSON object where you can see the number of issues that have been detected, the severity of those issues, whether they're a functional blocker that prevents a user from using your page, or if it's just something minor that we need to check as well.

We can see the page that the issue was on, the element, and we also provide the guidelines for those who may not be familiar. There's the web content accessibility guidelines, or WCAG, as they are lovingly referred to by folks in the industry, are the gold standard for how to build an accessible website, and the standard we use to measure them against those criteria and conformance levels are available to reference as well in this object.

And so the idea is, if I am a developer and I submit a pull request, we can now test to check for accessibility in a way we haven't been able to before. If I was a developer and accidentally submitted a critical accessibility issue, I could get that feedback right away on that pull request. And as we'll see here in a moment, we can get some robust reporting that we can use to replicate, remediate, and really resolve the issue.

So then, you know, now that we have access to the power of LambdaTest, we can run all of these tests in parallel, making test execution faster. We can, you know, one thing that's important for accessibility is a number of different screen resolutions, making sure that no matter what screen resolution and how the application renders, we're able to test it. And we can do all of this in a scalable way with LambdaTest as well.

So I'm going to go ahead and run this test. We'll see it run on LambdaTest. And then we can move on to reviewing a report and then to mobile. All right, so we've kicked off our test. Let me just pull up the LambdaTest site, and we'll be able to see this running in real-time.

I'll head over to web automation, and we should see this test pop up here shortly. Here we go. So we see this test running. One of the things I love about LambdaTest is the tests run extremely quickly. They pop up, very responsive UI, and it's a pleasure to use.

So this test will just take a few seconds to run, and then we'll be able to review the report and probably cut this down. My framework must be a little bit slow at the moment. Great, so my test finished, and we can now view the accessibility report that was created.

So, in addition to all of the fantastic reporting that's available in LambdaTest, we also have a full report that is available via events. This includes the types of issues that are created, the severity of those issues, and the URL in which it was found. We also group issues together by component.

This becomes really important when evaluating reports because, let's say, you have an issue in the header of your webpage, and then throughout your testing, you go through, you know, 100 different pages that have that same issue in the header. Well, instead of providing you with a list of 100 issues, events will actually provide one component that groups all of those issues together to make it much more efficient to review the results.

We provide the CSS selector, the code snippet, the WCAG criteria here, and even a highlighted screenshot to show exactly where that issue is. And so, you know, also, perhaps I'm a developer who's a little bit new to accessibility. They can click right here on this link and go to the events knowledge base, where I'm able to get a broader description of the issue. I can see code snippets of exactly what works and what doesn't.

And there's even a theory section down here at the bottom written by our events accessibility experts. They really dive into how this impacts users, why it's important, and how to prevent these types of issues from happening in the future.

For folks out there who might be interested just in general, this is free and open to the public. We'd love for you to check it out and drop us a line with your thoughts. So now, on LambdaTest, of course, we can jump into the test. We can see all the commands and the video of the test being executed. We have all of the information we need to debug and view the aspects of the functional test of this as well.

So extremely powerful reporting. We can see that same demo site being executed, and we're off to the races here. And while this works extremely well for the web, it works equally as well for mobile. And so here I'll just bring up our mobile Appium framework.

And you know, the example here is kind of exactly the same. Here I have my exact same, this is my Appium test, Appium Java; it runs swimmingly well on LambdaTest. I don't have to edit or adjust any of my desired capabilities or anything from how I'm normally running my tests.

Again, I just have to add a couple of lines of code in order to run on my native application as opposed to my website. So the same thing, I've got a wrapper for the drivers to add our libraries and some clean coding practices. And then all I do is call this the start analysis method. And just like on the website, this starts the events engines running in the background.

We will follow through your mobile test just like we did before, where this test is very simple, but it will follow through all the steps of your tests, capturing accessibility issues along the way, and you're able to, with a single line, have all of the advantages, just like the web one, of not having very little implementation, easy maintenance, deduplication, and you can output to HTML, JSON, CSV types reporting to augment your existing reporting mechanism as well.

So very simple. We'll just go ahead and run this again on LambdaTest, and we'll discuss some of the advantages there. So let me just kick this off. One of the fantastic things that really powers up our partnership with LambdaTest with accessibility; we want to make sure that we're covering a broad array of devices as well as screen sizes.

We want phones and tablets, and this is super easy with LambdaTest because, with your device availability, we can do all of those in parallel to speed up our builds dramatically. And so it's just extremely powerful; we're able to use that type of power to continue to shift left, making sure that, as a developer, if we submit a pull request for our native application, we're getting feedback within a minute or two to make sure that we haven't changed context or anything like that.

So we'll go back to our LambdaTest dashboard, and we can review the results they're going to jump over to the dashboard. And we'll go over to app automation, and we'll see the test that just ran. So this ran here. We can see, again, the power of the reporting here, where we can see the video of the test running. We have all the information we need to debug, as well as we can review the reports generated by events.

So once the tests have finished, we get a report that looks like this for our test run. So we have a fully detailed and interactive report for our mobile tests. So as I click through or hover over any of these elements, it highlights it on the screenshot to make sure there is absolutely no ambiguity as far as what element what issue refers to which element.

This is especially important with mobile frameworks. We wanna make sure that the reports are as clear as possible. So we can go through, we can see a number of different scans here, and we can kinda talk about some of the really important types of issues that we're able to detect automatically.

Similar to our web frameworks, here at events, we want to focus on the types of accessibility issues that impact users the most. And this is for mobile, you know, really around screen readers, especially some keyboard input, as well as voice control and switch control for the use of additional excessive technology.

And that is where our validation system really shines. And so this is going to be things like interactable role, where the element isn't declaring its role to the screen reader appropriately. Touch tour target size, making sure that these elements are large enough to be interacted with easily.

And one of the things that, you know, events always wants to make sure that our results are as accurate as possible. And so, this touch-target-tappable area validation is a good example where this is not just simply an area calculation. We're taking into account the type of the element, the spacing around the element, and the types of the surrounding elements to make sure that if we're calling out an issue, it's an accurate one.

In addition, color contrast is one that is a really tedious one to do manually, where we have to go with a color checker and every element and every bit of text to analyze. But with the Evinced, we do that automatically. We've got the color contrast, we provide the foreground hex, the background hexes, the computed ratio, the guideline, the criteria, and everything we would need that probably the designer, in this case, could do just to adjust those colors so that they're clear to see for folks who may need some additional help visually.

So with that, that's really how easy it is to integrate events with LambdaTest in review for both our web and mobile frameworks. We essentially have a start analyze method before the test run, stop, and analyze after importing our libraries. And we're through quite literally three to five lines of code. We can add accessibility scans to as many tests as we need to check for accessibility.

All right, I'll go ahead and stop sharing, and we can go on to the next phase.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. I appreciate the insightful demo, Kevin. Of course, accessibility at scale is one of the taglines that I came across on Evinced's website. With the integration with LambdaTest, Evinced is definitely tackling early accessibility testing challenges with a focus on scalability.

And it is great to see that LambdaTest 3,000+ browser and device combinations that we have, right? That is definitely helping create use as a perfect experience for testing. And, of course, making sure that your app is working for everyone is super important these days.

Accessibility testing is definitely a must-have when it comes to creating that inclusive, I would say, digital experience. So yeah, thank you so much for that demo as well as the walkthrough. So before we move on, I just had a few questions for you, Kevin, or we could jump straight onto it.

The first question that I have is, can you elaborate on the technical aspects that enable seamless integrations between these tools?

Kevin Berg (VP of Solutions Engineering, Evinced) - Yeah, absolutely. The key is, in the past, existing tools for integrating with really at Selenium, Appium, and the functional testing level have been extremely difficult to integrate. They had to go into the test themselves and add scans line by line, which inherently made the test more fragile. They would take longer to run. It was a pain to implement and maintain.

And what we needed, at the end of the day, they didn't have enough coverage to be valuable. And so, with the technology that events provide where you can just add a couple of lines of code, we remove all of those problems around implementation, maintenance, reporting, and then having the power of LambdaTest on the back end of that to be able to scale and run those tests extremely quickly.

That's a key component of the shifting left process. Running tests sequentially, no matter what, even if it's just a couple of dozen, takes too long. The developer is going to lose their focus. They're going to shift to a different project. They're going to shift context, which then you have to shift back, and it creates slowdowns, and it becomes really important. So it really comes down to making sure that we're integrating in a way that works with enterprise-level software development processes and doesn't slow anybody down.

Kavya (Director of Product Marketing, LambdaTest) - Awesome; thanks so much, Kevin, for that explanation. It definitely makes sense how crucial it is to have that effective collaboration between tools. And, of course, impressive focus on the technicalities of it, of course. Moving on to the next question, in what ways are Evinced tools scalable, and how do they cater to the demands of enterprise-scale accessibility testing?

Kevin Berg (VP of Solutions Engineering, Evinced) - Absolutely, well, making sure that accessibility tools fit within the processes of modern enterprise development cycles is key. You can't expect developers to be exiting outside of their normal process to do things like accessibility or really anything else, it simply becomes a bottleneck.

So with events, we have taken our technology and created multiple different form factors in order to fit in at every stage of the development cycle. This is everything from our design assistant that helps build accessible designs from the very outset to our unit testing tools which allow you to test your component library that you're developing for 100% of keyboard and screen reader type issues.

Then we get to kind of the focus we've been sharing about today, which is our kind of functional testing suite, which is where you've taken all of those web components or mobile components and put them together into the full app or website. And then you're able to test with unparalleled coverage for accessibility issues at that point once you put everything together.

Beyond that, we have tools for QA, like our Webflow Analyzer, the Chrome tool that we saw previously, all the way to production monitoring. We have a site scanner that allows you to test the entirety of your website. We have customers scanning millions of pages per month to make sure that the accessibility issues are monitored; they're able to trace back if any are slipping through the cracks.

This allows us to provide as many entry points as an enterprise might need to add accessibility testing as part of their process seamlessly.

Kavya (Director of Product Marketing, LambdaTest) - That is awesome. I mean, good to understand how accessibility is essentially playing a role in every stage of the development cycle. Very insightful, especially given the context of enterprises, right? We have enterprises across different industries that have unique use cases.

So, yeah, good to hear that Evinced is basically helping them embrace accessibility throughout every development stage. That's definitely helpful. Moving on to the next question, when emphasizing clear and actionable results, what specific features or methodologies does the solution employ so as to aid developers and testers in addressing accessibility issues?

Kevin Berg (VP of Solutions Engineering, Evinced) - Yeah, and this is a really important question and a really important feature that's required. I developers have so much on their minds today. With all of these things shifting left, there's just a lot for them to remember. And so being able to provide clear, efficient remediation information as part of their testing process is critical.

I mean, with events, you know, we have over 140 different validations that have different levels of coverage. And to expect anyone to remember how the details associated with 140 different, very specific accessibility criteria is a lot to ask. And so, with our tools, we approach this in two ways.

First, we provide detailed code snippets. And in many cases they're able to just copy and paste this code over into their project, and it will resolve the accessibility issue. We provide highlighted screenshots as well to make it quick. We can always include selectors, but nothing beats a screenshot or, in the case of LambdaTest, a video replay of the test being executed to really understand what happened.

And then third, we've built in a lot of kind of training within our tools. So, for example, every report that we have has the cause, what causes this issue, and how it impacts users from an accessibility perspective. And so that as developers are using the tools, they're also learning more about accessibility and ramping up while they're using the tool.

Kavya (Director of Product Marketing, LambdaTest) - That is definitely a great reply, Kevin. Good to hear that there are various methodologies that you have implemented so as to improve the experience wherein those who are testing, for instance, are able to learn even the root cause analysis when it comes to accessibility testing, the issues that it's been faced, the detailed reports and the screenshots that they are able to access and so on.

So yeah great to hear about these factors. Moving on, how does the integration with LambdaTest contribute to optimizing release velocity in the context of accessibility testing? We definitely heard about how the integration sort of helps from a scalability standpoint. But we would love to hear more thoughts on it.

Kevin Berg (VP of Solutions Engineering, Evinced) - Yeah, and I think that that's really the key. The scalability is what's important because no matter what type of testing it is, whether it's functional testing or performance testing or whatever, we can't have that be a bottleneck in the development process. We need developers to get feedback as quickly as possible. If you submit a pull request, we want that feedback to be happening within minutes.

And I remember I once worked with a customer who was the largest retailer in the United States, and they had a company-wide mandate that developers had to get feedback within six minutes. And so it's meeting enterprise-wide goals like that where it's critical to have a scalable test infrastructure like LambdaTest with all the resources it provides.

The other side of it, besides scalability, is coverage. I mean, almost no two phone devices are alike. There are different size screens, there's different hardware, there's tablets of all different shapes and sizes. And to make sure that from an accessibility standpoint, each of these tablets or phones renders the app in a slightly different way.

And we need to make sure that no matter what device a person is using, that application renders appropriately and is accessible, and they can use that app as it's intended no matter what. And so it's in those two ways that LambdaTest really enhances the power of events for both scalability and comprehensive coverage.

Kavya (Director of Product Marketing, LambdaTest) - Well put, I mean, that was an amazing explanation. In fact, something that also stood out for me when you initially explained LambdaTest and evidence integration was you used the word scaled horizontally. That was exactly the phrase that you used across different devices and screen sizes for comprehensive testing. I think that sort of sums up the integration that we have and yeah, glad to be a part of it.

Moving on to the next question, to what extent can Evinced tools be customized to suit the specific requirements of different enterprises and projects? You definitely mentioned the retail example. So I'm sure there must have been several other specific requirements that enterprises must have come to you with.

Kevin Berg (VP of Solutions Engineering, Evinced) - Absolutely, and customization and the ability to work with our enterprise customers is a key to any partnership that we have with our customers. Accessibility is tricky. There are a lot of areas in which there can be debate as to whether accessibility is there or not.

But a good example of how we can customize our tools is we work with a very large financial company one of their brand colors is a shade of green. When comparing that green color to some text, the contrast ratio came in at about 4.48 to one.

And in accessibility standards, the guideline states that it needs to be 4.5 to 1. And so it was just barely underneath that guideline. And so that was causing dozens and dozens of issues that were becoming tedious for folks to go through. While technically, they are accessibility issues, we also have to understand that this is the brand color of an enormous financial institution. That's probably not going to change anytime soon.

So Evinced is able to create a fuzz factor and make sure that we're able to customize our rule sets and customize our reporting to make sure that it's valuable for customers. In this case, we were able to make it so that they could adjust the color contrast and not flag those types of issues so that their reporting would maintain efficiency and the value that they expect.

So customization is key. Any true partnership with our customers requires back and forth and making sure that everyone is well supported.

Kavya (Director of Product Marketing, LambdaTest) - Yeah, and impressive to hear how even the minute detail, especially given it's a brand color, even that is something that is sort of being, I mean, you're sort of helping out enterprises even with that solution. So yeah, the flexibility and the customization that comes with the Evinced tool is definitely impressive.

Moving on to the last question that we have today, I would love to hear your thoughts on the reporting capabilities of events and lab tests, especially in terms of tracking and resolving accessibility issues in a collaborative manner.

Kevin Berg (VP of Solutions Engineering, Evinced) - Absolutely. So, I mean, with the power of the two reporting systems combined, you have really all the information you could ever need to evaluate and understand any issues that are happening, whether it's from the loading of the website in the browser to the functional aspects of the tests of the actual underlying functional test to the interactions with the API calls through the network logs through the from the step to walking through the flows and page loads, all the way to once the page is loaded and scanning for accessibility with the fully-fledged accessibility reports.

Then you can go back in with LambdaTest, you have a full video of the entire test being executed to see any problems that might not show up in a single point-in-time screenshot you have all of the information you need so that if any issues do pop up, you're able to remediate them quickly.

Instead of having to create a spike for an investigation that you have to replicate a dozen times and bring back an environment, you already have all the information you need to solve all of your problems, whether they be from accessibility or otherwise. It's just extremely powerful that developers have everything they need right at their fingertips.

Kavya (Director of Product Marketing, LambdaTest) - Once again, well put, Kevin. Thank you so much for that wonderful phrase because I think it is a great example of a successful collaboration between an accessibility platform such as Evinced and LambdaTest.

Great! So we have come to the end of today's episode. As we wrap up the episode, I would like to thank you for being a part of our XP Series, where we bring you the latest trends, innovations, and conversations from the world of testing and quality assurance. Kevin, once again, thank you so much. That was a very insightful session.

And yeah, great to hear everything that you had to share about accessibility testing, how Evinced is sort of powering it, and the integration between Evinced and LambdaTest.

And those who are listening, please Subscribe to LambdaTest YouTube Channel for more XP episodes. Kevin, once again, thank you. It was a pleasure hosting you. Until next time, everyone, happy testing. Have a great day ahead. Bye.