Automating Accessibility Testing for Your Component Library

Hello, today we'll be speaking about automating accessibility testing for your component library. So we look at the different things that we'll be covering today, web accessibility and its how to measure web accessibility, when to consider accessibility, Storybook and its role in web accessibility, how to include accessibility in your component library, and then we'll be comparing accessibility add-on with your Lighthouse and then benchmark and then see how each one is better over the other.

Okay, what is web accessibility? Building websites that can be used by all. That is a simple definition of it. So that means that if I am able to do, if I am able to use something on the web, the person sitting next to me should be able to do the same things that I can do on the web. So for this to happen, you should make sure that you have ensured readability and usability for assistive technologies like your screen readers, you have made sure that your web application can be navigated through keyboard controls. So these are one of the important things to make sure that your application is accessible.

Now why web accessibility? Usually people think accessibility as something that is a good to have but today I'm going to tell you why it's not just like a good to have thing but a much to have thing. Firstly, more customers. So this is like one of the most important things because about 15% of the global population has some kind of disability. So this gives you an opportunity to tap into the 15% that your competition is not looking into. But this sets a differentiation from a competition and definitely helps you target more customers. Secondly, compliance and legislation. So today as I told you, accessibility has become a much to have and a lot of countries have already declared accessibility as something that you should other to. If you are not accessible then you may end up paying huge fines. So to avoid penalties and huge fines, you should make sure that you are compliant based on whatever your region depends. Thirdly and the most important thing is SEO benefits. Usually people think SEO is something that is just to do with your content but with accessibility, right? Most of the search engine today are optimizing for accessible websites. So if your website is accessible, the probability of you ranking higher in the search results is really high. So you should make sure that if you are just looking for SEO, it just isn't your content that is present on a website but also accessible nature of a website that is very important for your SEO. And then finally, improved usability. Accessibility does not just help people with disabilities but also helps people without any disabilities. For example, a person living in a remote village or someone who's old who's not able to use the website will be able to take benefits based on the accessibility nature of the website. So how to measure accessibility? Perceivability. Ensuring that the information presented is easy to perceive and understand. And secondly, operability. This makes sure that you can navigate and interact easily. So no matter who comes to your website, right, they are able to navigate and interact through your website. Then, understandability. This is making sure that everything on your website is easy and clear to understand.

And then, robustness. This is ensuring compatibility with various technologies, including assistive devices like your screen reader and others. And then, compatibility. This is making sure that the features that you have built for your website is compatible and works seamlessly across different assistive technologies.

When should you consider accessibility? Usually people think accessibility as something that you can do after you build your website, after you have everything ready. And then once you go live, right, people usually think that accessibility is something as an afterthought that you can think about. But I would beg to differ. Accessibility is something that should be considered from the start if you want to reap the benefits of accessibility.

So, how do you do it? Start with the components. So, today, everyone follows component-driven development. So, you should make sure that you incorporate accessibility and its consideration right from the start while you begin your component development. Secondly, address your basics. So, the basics like your ARIA rules, color contrast, font sizes, accessible design, and then a few other items attribute to about 60% of the accessibility requirements. This is massive. And today, in my talk, I'll also be trying to help you with strategies as to how we easily make our website accessible and how we cover all these 60% of the basic requirements that are very easy to cover if you have the right strategies and plan in place. And then finally, once you've covered your basics and you know that your application is already 60% accessible, now what you do is you just try to look at the complex cases, right? Like, for example, how do you enhance the user experience on these assistive devices? How do you manage the reading order? And you can tackle all the other complexities.

Now today, I'll be introducing you to a tool called Storybook, which a lot of you must already be familiar with. So Storybook is an open-source tool that helps you document, view and test components in isolation. Now why Storybook? Because Storybook helps you with component-driven development. Today, anyone who is doing component-driven development, right? Use Storybook. We'll firstly look, why Storybook, right? Isolated development. Today, you don't want to keep your components... the tests associated with the components and the various things that you want to do with your components in your application folder. So the easier way to do is with Storybook, you kind of isolate it. You take all your components to a different environment. And then you test your components there. You see if your components are compatible for mobile, tablet views and different things. You also test a lot of other things. So separating this right will definitely help you improve your efficiency and cleanliness of the project. So that is why Storybook is one of the mostly used tool today.

And then secondly, developer awareness. Today, let's say if a new developer is joining your team, it is very difficult for the developer to know about the existing components unless you have it documented somewhere. And this is exactly where Storybook helps you with. So with Storybook, you exactly know about the different components that are existing.

And then if a developer has to pick up a task and then start building components, he knows exactly if there is a component available for the same or if he has to build a component for it. And then thirdly, style guide and documentation. So Storybook serves as a living style guide. So if you are making some changes on Storybook, if you have documented your components in Storybook, when you import these components into your actual project, it is going to behave exactly the same. So it is highly likely that if you have tested something on Storybook and if it's behaving as expected, when you import into your application and when you integrate into the other components in the application, it will just behave as expected.

And then finally, and the most important thing, it simplifies testing. You can do a lot of things with Storybook. Like you can do viewport testing, unit texting, accessibility testing. And today we will be focusing on accessibility testing. So what are the tools that helps us with accessibility testing? Storybook has this add-on called Accessibility Add-on that helps us with accessibility testing. This is a tool that helps to identify and address accessibility issues in UI components. So let me try to introduce you to Storybook. This is what Storybook is and you have different components documented here. You also have documentation for these components where you can look for different things. So it generates auto, it auto generates the documentation for you. And then you can also look at different variations of your component. These are called stories. You can look at a button and you can look at the documentation for the button. You can look at the different scenarios of the button. For example, there's a primary button that you can see in your application. There's a secondary button.

And this is the add-on that I was referring to, right? So what this add-on does, right, it just injects this particular add-on into all your components and then makes sure that accessibility audits are run against each of these components. So you are able to understand if there is something that is failing or something that is passing. Okay, why accessibility add-on? When there are a lot of tools that helps with accessibility, why is that I am stressing on accessibility add-on with storybook? Firstly, easy integration. It's just a single line and then you can get started with in just a few minutes. It's that easy.

And then secondly and the most important thing, right, component level insights. Today most of the modern tools usually do the audits on a page level. But when you're trying to build a library, right, component library, it's very important to like actually start auditing at a component level. So let's look at the differences, right. Let's say if I chose a tool today which does page level insights. So the problem with that is if you're trying to build a component library, every time you will have to build your library, and only when you integrate it into your actual application and then audit it on that application, right, you will be able to see the audits. But with the storybook Accessibility Audit, what you can do is you will get to see the Accessibility audits run on all of your components and immediately you'll get to see if there is something that is being violated and then you can pinpoint and fix it and basically save time because it helps you with shortening your feedback loop.

And then thirdly, right, effective feedback. So this is something that is very important. So today if you are trying to choose any tool, the most important thing that you look for is how easy is the tool to use and how much of feedback does the tool provide so that it makes your life easier. So Storybook gives you a lot of things in terms of the resources, links, the security tags, the violations, and it basically helps you identify a violation and then go from identifying to actually fixing the violation and all the resources that will help you fix the violation.

And then finally, a colorblindness emulator. So I'll just show all of these things to you. So this is how. So this is where you get to know about the severity of the issues. So it tells you whether something is critical, serious, or something is just a minor issue that you can let go of. And then I also showed you how does it help you, right? Let's say if there is a violation, so I have a violation here. Okay, I don't have a violation, but let me show you, right? Let's say if at all, if I had a violation, what would I do? So if this was a violation, what it gives me is it helps me navigate through resources and it gives me the exact description of what this rule is and why do we need this rule in the first place and what are the right ways of fixing this, why it matters, rule description so that with this, right? Let's say if some rule was failing, all that you'll have to do is you just have to look if that is something that is severe, if that is something that is important for you. And if you feel that that is critical and important, right? You just go through the resources, identify what exactly the rule does or like why this rule is important. And then from that, uh, and from that, right, you actually get to know the importance of it. And then you immediately make changes to your code, come back, see if the rule is fixed and yeah, you're good to go. It's that easy. And then, right? Uh, one of my most, uh, favorite features here is the access to the colorblindness emulator. So with this emulator, right, what it gives you is it helps you build empathy because you get to see and experience the UI exactly like how someone with colorblindness would come and experience it on the application. So let me, let's say blood vision, right? You get to see.

And then you immediately make changes to your code, come back, see if the rule is fixed and yeah, you're good to go. It's that easy. And then, right? Uh, one of my most, uh, favorite features here is the access to the colorblindness emulator. So with this emulator, right, what it gives you is it helps you build empathy because you get to see and experience the UI exactly like how someone with colorblindness would come and experience it on the application. So let me, let's say blood vision, right? You get to see. But this why it is important is you'll get to know if the font size is here, right? If you're not able to read it, or if you're not able to like understand something from this, it, it just means that, okay, someone coming with colorblindness also, uh, not able to like see it. So it builds empathy today. Building accessible applications have become overwhelming and for developers, if you actually want them to like start focusing on accessibility, right. The first thing is to build empathy and this tool, right? Helps you build that empathy and also helps you see at things which you wouldn't, wouldn't have been able to see otherwise.

Now coming to the most important thing, how to include accessibility, uh, in your competent library. Now today, let's say if you were building a competent library, and as I told you, right. Um, if you just fix the basic issues, about 60% of your issues are sorted and these issues are so easy to fix. If you just set up the right strategy in place, if you automated and if you do the right things, you will be able to like make your application, uh, 60% accessible in very little time. And then the rest, right? Uh, you can, you can figure it on the go. So let's look at the different things that we will be, uh, covering, or this is my secret sauce of how I implemented accessibility into my competent library. And it has definitely given great results.

Firstly, integrate accessibility at all. So let me show you. So if you have Storybook installed and, uh, which I believe today, most of the people have Storybook otherwise also right. It's very easy and simple to, uh, install integrate. So if you have the Storybook, uh, installed already, it's, it's very, uh, easy to like actually, uh, integrate it. All that you will have to do is you just have to add this add on and then you're good to go. It's that simple. And then you'll, you will see the audits running on all your components. So that is where you start it. Secondly, you will have to choose your rules. Uh, choosing rules are very important because, uh, the rules that I would want, um, to follow, right? Maybe different from what, what that you would want to follow. Maybe you want to follow the basic standards of accessibility, whereas, uh, someone else right. Want to follow all the standards. They were, they would want to like follow the highest standard and then make your, make that application, uh, accessible.

So to choose the rules, right, uh, we'll see how, how we can do it with, with Storybook. So there is a preview file, uh, where you basically get to, um, add your decorators and your parameters and in your parameters, right? That is a parameter for your accessibility. And here, right. You get to choose your rules. So here, if you see, I have, I have a rule called color contrast that I have, that have disabled basically, because I've enabled false. So if you would want to like maybe like, not disabled, right. If you want to enable this, you could enable this, or if you'd want to look at other rules that you would want to configure, it's, it's very simple. You could just go here. And then here is a list of rules. You get to see the different rules are your area. And then you get to see the tax, whether it is this compliant, if you want to make sure that you're compliant to the standards, you can include it. Or if you feel that, okay, this is something that you, that it would not want to use. All that you'll have to do is you just come back, come to your, you just come to your config here, and then you just disabled that rule. You add that rule and then disable. So for now, right, I'll just enable this. So that I'll be able to actually see violations on my storybook UI. So I'll just come to storybook and then. So here I started seeing violation. So earlier when I showed you, you didn't see the violation because I disabled the rule. But now as soon as I enable the rule, right, you can start seeing violations. So this also helps you just concentrate on the rules that you would want to and leave everything else, right? All possible stories.

So stories are nothing but basically declaring all possible variations of a component. So why is it important to write stories? So let's, let's look at it like this, right? Let's say, today you're building a react application and react everything is a component, basically a single component or like different components that are integrated together and these components can be rendered based on conditions or based on state changes. At the end of the day, everything is a component. You just decide like what to render, what not to render.

So if you are building your component library, and if you're trying to make it accessible, you'll have to make sure that you test the accessibility for all variations of a component. But this is why it is important to write all possible stories. So let's look at how we do it. So let's look at a button component. So usually what people do is, here is where they make the mistake. So they just write a single story. So I could have just stopped here, and then my primary button would have been accessible. But if you looked at the UI that I showed, my secondary button was not accessible. That is because my primary button was working as expected because of the right color contrast, whereas my secondary button was not. So that is why it is very important. If there is a component, and if you feel that there is a variation that you can see in your application, it's important to write and document all those variations in your application.

So writing a story is very simple. You just have to create a template. And once you create a template, you just have to pass the right arguments for it. This is basically the props that you would want to drill in, and then, yeah, you're good to go. So it is very important to actually write all possible stories for a component. If you miss out on this, you're just not making, you're not just testing all variations of your components. And then, a re-interaction test. So now, to just summarize, we have integrated the add on. We have decided the rules that we would want to choose. And then, we have decided also on all the possible stories that we'll have to write for the component. Now, you have like a component library where you have components, you know the different components, and the state changes on which the component can render on. And you have covered all of these cases. Now, the next thing is interactions. Let's say, for example, there's a component, there is an input box and when you wrote something, that checks basically for URL validation. And if you type something on the input box, you would want to see if it is a valid URL or not.

Now, with most of the tools today, you can't do this. This is where Storybook sets all of them apart. With Storybook, you can actually like write these interactions and you can actually mock your API calls.

Let's say there is a button, when you click on the button, it makes a call to your backend and then based on the response, you display a view. So with Storybook, you can actually do this. Let me show you how and how simple it is to do it.

So let's assume that there is an ad project. Let's say you would want to add a project. I'll show it in the UI, how to do this. So that is an ad project. So this is my default input box, where I would want to add the right URL. So here, if you look at it, I have an invalid URL added and then it prompts me for issue. So here is where the interactions are. So I was talking about the interactions, this is how you do the interaction. You can actually choose what you would want to expect on the view. So here, what I'm trying to do is, I'm just trying to see if... I'm trying to get the component and then I'm trying to enter the URL on the component, the invalid URL. And then I'm trying to see if this is an invalid URL. And then I have this description, right? So earlier when you saw, you didn't have this description here. So only when I entered a URL, right? There is a description that comes in. So with Storybook and with the interactions, right? What I can do is I can actually check for every single thing. On every state change, I can actually see if there is something that I expect to be on the UI. So here, this is what I'm checking. So I am just checking if a Storybook URL, okay? That is having accessible description. So what is accessible description? Please enter a correctly formatted URL. So this is what I can do. I'll show you a few more scenarios as well.

So here is a component that you're trying to basically import. So whenever you click on import, right, API call is made, and then it's displayed. So let's say the API call fails if you're trying to import, and if the import does not work, right? You enter this test.

So with Storybook, it is very easy to test all of these. I'll just show you how. So you can actually use the mock service worker, where you can actually mock your API calls. And then I'll just show you a scenario, right? So this is a submit field. So what I'm trying to do is I'm just trying to run these interactions. So first, I try to find the canvas element. And then once I identify the canvas, right, I just try to find the element that I would want to interact with. And then once I try to find the element that I would want to interact, I then interact with the actual element. This is how I do it. So where I actually type mystorybook.com, this is an invalid URL. And then I get the button and then I try to hit the submit. Now when I hit the submit, usually when you're trying to build a component library, you don't have your APIs created or integrated. But if you still want to test, right, this is where your mock servers worker comes into play. You can actually do it very easily. You just try to exactly mock it. So here I'm trying to do a request to slash project. And then what I could just mock it to send a 401. And then once you say 401, you get this place like a different view, just like how I saw it here. Same with the success, right? I would have to like, yeah. So your success, you are a different UI here. So when I imported, and if the API call succeeded, right, you actually get to see the different view. Now, why this is important is maybe let's say if you didn't write this interactions, the pop-up that you see here, right? Or the toast message that you see here, you could never test if this toast message is actually accessible or not. What if everything was accessible, but the view that you see on interactions, right? Are not accessible. Let's say if this color contrast was not as expected or maybe the font sizes was not as expected or anything we heard, right? And you see is not accessible, then you actually can't make, then you can actually not fit into looking for all the accessibility rules that you would want to follow. So this is very important because once you have also tested for interactions, you are making sure that you, it is easy for you to test for 60% of the accessibility parameters in your application. Let's say if you didn't follow these metrics, you just can't test for all the scenarios in your application for accessibility. This is where this is very important. And now, right, finally automating accessibility testing. Now that you have integrated your add-on, you have chosen your rules, you have written all the different, you have identified all the different variations of the component. Now that you've written all the variations what happens is your accessibility add-on kicks into all of these variations and then looks for accessibility audits.

And also you have checked for interactions. Let's say if there is something that you would want to interact with some API call, just like how we saw, right? We are trying to import and then that import as soon as you click on import, it makes like a post message, which you don't have access to in your component library. So you can actually mock those APIs easily. And then you can still trigger the variations that you would see if at all, if your API call fails, then you see a different view. If your API call succeeds, you see a different view.

Now that we have written all of these things, right? When you're working on a team, something that is very important is how do you automate this? So that anybody on your team, right? When they're trying to maybe raise a PR, they are other to the same standards. So how do we do this? So let me show you. Storybooks gives you a test on our file, where basically what it does is just a thing that you saw in the UI, right? Where your access to add on tries to inject the access to your audience in every component. You do the exact same thing in a different environment, basically. So let's say if I had to do the same thing on the CI, or if I had to do it on the terminal, right? How would I do it? So this is where your test rendering file helps you with. So it basically uses your aXe and then it uses the different things like your check accessibility, your configure accessibility. All of these comes from aXe play, right? Where you try to first, before you render your page, you try to inject the aXe, basically the one that is responsible for your access to your audience. So aXe is the one responsible for access to the audience. You try to inject it. And then after injecting, right? What you do is every time there is a story that is rendered, you try to you try to look for certain things. Firstly, maybe there are certain stories that you would not want to run aXe on. So this is where this check will help you with. So if you, if you feel that you don't want to like run aXe on a particular component, you can just disable it. And then maybe let's say now that you have, you want to run it on all the components, so what you could do is you could just come here, configure all the rules that you would want to run for, and then you just try to like check the accessibility audits for it and then give a detailed report here. Just like how I mentioned the configuration. This is very simple. And also, what story book gives you that a lot of tools does not give you is it also helps you with snapshot testing. So this is how I can actually do the snapshot testing. Along with automation, I can actually run snapshot tests. What are snapshot tests? So let's say there is a snapshot of a component for accessibility, that is stored here. Let's say I want to like maybe someday, a few days later, I change something on my component. So it'll exactly know, it'll give you indication that, okay, this is how your snapshot looked earlier, but now it has changed. So do you actually want to bear with it? So with this, this snapshot testing, right, actually helps you a lot. Even if someone is reviewing your PR, right, or something has changed, they exactly get to know, actually. Okay.

This thing has changed, and maybe is it actually impacting the accessibility standards that you would want to follow or not? So it helps you place a check in place.

Yeah. So now that I have also added a test runner, now let me show you how I would actually run these audits. So first you should make sure that you have storybook running. So you just have to do yarn storybook, just like how storybook recommends you, this is the basic thing. So I've already started my storybook and now what I would do is I would try to automate this.

How would I do it? I would run the script. So before I run the script, I would want to show what the script does. So here it just uses yarn test storybook. So this is something that storybook gives you and which helps you audit for accessibility issues. So I just run this script and let's see what happens. It just takes some time to actually run these tests. We should see it anytime now. Yeah. Yeah. Yeah. So you saw here, right. So it actually ran all the accessibility audits right on my terminal. So, and also the cool thing here is it gives you the exact issues.

So let's say if something failed, right? It tells you like, actually which is the component that is failing. So here the primary works and the secondary doesn't, it does not, it's not accessible. And also I told you like why it is not accessible because on purpose, right, I have given incorrect color contrast. And then it shows me that, okay, the expected was supposed to be a zero, but then you have an issue here. And then you have seen that safety violation. And then what is the violation, right? And what is the rule? So it is a color contrast rule and what is the impact of its seriousness? So you should make sure that you are there to this rule, right? Otherwise you will see this.

So with this, what happens is you can easily interact your accessibility audit onto your CI. So along with viewing things on your UI, right? Everyone who is raising a PR now is assured that whatever they're raising is accessible. So that is what it helps us with. Now, we would want to fix this, right? I do not want to see the things failing. So how would I do it? So let me show you, right? I'll show like what are different issues that are currently there and how I would fix it.

Firstly, I would want to like disable this because there are a few color contrast issues. I have disabled this and then I also see a few other issues, right? I think like, okay. I think just the color contrast is what should be the issue. I don't see any other issue.

Okay. Yeah. So let's try to run the audit once again and then see now if it passes the checks. Okay. So yeah. So here is what, right? So it passed all the tests now and you don't see any violations here. So this is the beauty of it. And also like it's very simple to integrate into your CI.

Let's say if you had to like integrate into your CI, right? It's very simple. All that you'll have to do is you just have to run the script. So what I've done here in the script, let me show you what I've done in the script. I basically have to start storybook. So only when I start storybook, right? I'll be able to do it. So I'll have to build storybook first. That is what this does. And then once I build storybook, I would want to like start storybook on port number 6606. And then once I've started storybook, I would want to wait until it started. And then once I'm insured that it's started, I have to run this, run the script that I ran in the terminal. And with this right, it basically runs on the CI.

Let me also show you how it looks on the CI. So here is our right. So I'd actually like integrate into my CI in one of my projects. So you could actually see the exact thing that you saw. So you have no accessibility violation detected. These are the tests that are passing. And yeah.

So with this, if at all, if someone didn't follow the accessibility standards, right? And if there is a PR, and if you integrated on the CI, they'll immediately get some feedback as to like, okay, this particular thing is not accessible. And then they can immediately fix that and then get back to it. So the feedback loop is very, very small. And then it actually helps you save time. And with this strategy, right? It makes sure that anyone and everyone who's contributing to a project is following the accessibility standards. And there is automations in place that basically helps you from the right get-go.

And now that we have automated accessibility testing, something that I would want to tell, right, Storybook or any add-on or any tool, any modern tool today, does not guarantee 100% accessibility audits. Because you'll have to always run manual accessibility tests. Let me tell you why. Let's say, for example, there are these assistive technologies like your screen readers, right? There is no way for you to know if the user experience or the order in which your content has to be rendered or various other things, right? That you would want to, that you would want to abide by. Unless you actually run manual accessibility tests on these assistive technologies, you can't actually identify. So Storybook is not a complete replacement for your manual testing. What we are trying to do here is, we are trying to look for the majority of the accessibility issues, that is your basic ones. And then that accounts for about 60% to 65% of the issues. And we are trying to see how we can actually come up with a strategy and a plan so that we can easily cover the 65% of the issues without a lot of effort. So if you just followed the things that I told you, from integrating the rules, to writing all possible stories, to interactions, to automating it in a CI, 65% of the issues is sorted. And then after that, what you do is, you go and then actually look at the other complex issues that can only be tested on your actual screen readers. And then you identify these issues and then you fix these issues, and then your components are 100% accessible.

Now, let's try to compare accessibility add-on with Lighthouse. Most of the people today use Lighthouse for their accessibility audits. Let me tell you how Storybooks' accessibility add-on is better than Lighthouse. So firstly, in terms of its ability to audit accessibility issues, both of them, your accessibility add-on as well as your Lighthouse, has the same ability because they have the common accessibility engine. So both tools utilize the accessibility engine from Deque's systems, ensuring that they have equal capabilities in identifying accessibility issues. So if you're looking, if the comparison is, which one is better in terms of the capabilities, both of them are pretty much the same.

Here is what it differs with, right? Here is what the differentiation is. Page-level versus component-level insights. So if you look at Lighthouse, right, Lighthouse is something that you use as an extension or basically it's a tool on your Chrome or any other browser where you actually run accessibility orders after you render your application. So after all your components, right, after you have integrated all your components, after you have built your entire page, you go and run this. The problem with Lighthouse is it works great at page level. Let's say if you have already built a component, or maybe like if there is an application that is not compatible with Storybook, right, or maybe if it is not compatible with the accessibility order, your Lighthouse is the go-to for those scenarios. But with accessibility order, right, what you do is it tries to pinpoint the accessibility issues right from your component development. So when you're developing your component, right, it actually helps you pinpoint the issues right away and then you can fix it. Let's say if you didn't choose to use accessibility order and then rather go with Lighthouse, right, what you would do is you would build your components and then you would publish your components in your component library and then you'll come back to your application and import the components and then render those components on the browser and then you will identify that, okay, with Lighthouse or any tool that does page level violations, you'll identify that, okay, there is a violation here, you go back to your component library and then again fix it and then repeat. So what happens here is it's a longer feedback loop. Whereas with Storybooks accessibility add-on, you just get to pinpoint accessibility issues while you're developing a component and then you can just fix it right away. So it results in a shorter feedback loop. This is the actual differentiation. So if you are building a component library and if you want to start accessibility audit right from component library, right, just like I told which you should, then Storybooks accessibility add-on is the go-to tool for you.

And then finally, static versus dynamic auditing. In Lighthouse, I think most of y'all should have already used Lighthouse. And if you have used Lighthouse to audit accessibility issues, what Lighthouse does is it does like a static audit. So whatever it sees on the screen, it just tries to audit for those issues. But with Storybooks accessibility add-on and the different add-ons that Storybooks ecosystem provides, like, for example, your Viewport testing, your interaction testing, all of these, right? What you could do is you can actually test for accessibility issues even on state changes, just like how I showed you where I was trying to do URL validation. And when I was trying to do URL validation, if it was an incorrect URL, you saw that an error message was coming up. And then I was actually trying to check if that is the right accessible description. And same goes with the component that I was trying to import. And then I was trying to mock this API. And then if there was a bad response, right, I can actually render a different view.

If it was a good response, then I could actually render a different view. So what I'm trying to tell is, based on state changes, right, you can actually do your audits. So that is very important.

Yeah, so that brings you to the end of my talk. So here is what we learned, accessibility and its significance. Timing, accessibility consideration, actually like when we should start considering accessibility in our application. And then the role of storybook, why it is important. And then storybooks, accessibility add-on, advantage, how to use it, how to include it in your component library. And then finally, right, how do you automate this entire flow and then make it so easy for your developers or anyone in your team so that the 65% of that accessibility issues, right, that accounts to the majority of the issues can be fixed very easily and you don't have to like spend a lot of time on.

Yeah, thank you, and you can connect with me on my social media handles here. So here's my X and my GitHub.