 Today we have Manoj with us, who is going to talk about tips from the trenches accessibility testing. And Manoj is a principal technologist at ThoughtWorks. I'm super honoured to be hosting him today. So I'm sure we all will enjoy his session. So I'll hand it over to you, Manoj. Sure, thank you. Hey everyone, so happy to be here and thanks for being equally honoured too. Thanks for all of this. We have been meeting each other in different conferences. So I'm so glad to see Parvin again. So as Parvin already shared, today's session is going to be tips from the trenches accessibility testing. And before that, I'm Manoj and as Pravin mentioned, we work for ThoughtWorks and I'm a principal technologist. I like to be called myself as a T-shaped technologist where I go across breadth as well as go deep dive in tech where think QA and a few other like DevOps and mobile and think react front-end accessibility performance. There's a number of things that I do. They never one thing I easily get bored. So I try to go hands-on with different texts. So that's how I get experience in multiple areas. So today specifically, I'm going to share about accessibility testing and how I got involved. So this was during one of my engagements when I worked with an insurance provider in Australia where I got the opportunity to work more on, you know, transmitting front-end from Angular to React when mostly as a single-page application, right? I think it was at least six years back. So you could imagine at those stages, React was still picking up and as everyone, you know, the tech as a dev, they're trying to move from one piece of technology to the other. I think framework. I think it's basically due to try new stuff. And single-page application was trending. I don't know if it's still trending. So I still see a few providers, insurance providers specifically as well as a few forms still follow the pattern. And what's more challenging when you do that is try to bake in accessibility with that, right? I think it's becoming even more challenge. So I'm going to share some tips from there. And I think that's from since then, since I developed my passion around accessibility and I start researching about it whenever I get a chance. As a consultant at ThoughtWorks, whenever I speak to my clients, I always, you know, keep this as one of the agenda items and try to understand what is there mindset about empathy and inclusive culture, you know, all around these things. And I'm going to share a couple of things in terms of accessibility itself, what it means. And as a key takeaway, if you're someone who's new to accessibility, what is something that you should take away from the session. And after you understood what is accessibility, I think the most important or the immediate key takeaway would be to see this is all good, I understand accessibility. Now, how will I fit this within my SDLC, which is my life cycle, software development life cycle, and then more specifically deep dive into accessibility testing perspectives to see how quickly I can check. Because if you're in a green field project, that's great. You can start baking in. I'm sure there'll be a couple of takeaways from the good for all SDLC phases that I have. But if it's a brownfield and if you already have something, so you could go ahead and, you know, implement some of the testing features from there. Before that, I will actually start my captioning. This is something that I usually do for all my accessibility sessions. I just forgot. But nevertheless, we are never, you know, too late. It's just second slide and just the agenda. Let's get started. I'm more on accessibility. So what is first thing that comes to your mind when you hear accessibility? Wish this was an in-person conference so I can, you know, hear all your voices, but unfortunately, we can't do that. So accessibility to me is all about how easy I can do things, right? So what is my situation right now? What is I'm capable of? What I'm able to do? And a number of things that comes into picture, right? If the things around us are something quite naturally aligned to what humans can do or, you know, we humans have done a lot of damage to our environments already, easy for our lives. But that said, there are different set of people, different persona group who have different set of needs. And often we forget that as well, right? So before I deep dive on the core principles of accessibility and all that, right? So this is more of something that stuck me when I was looking at what is accessibility and how easily that I can say to someone, right? With the next slide, I want you to, I'll make a quick pause, probably say 20 seconds or 10 seconds. You have a read for yourself and I hope that will give you some sort of sense on what is that you're going to learn if you're someone who's very new to accessibility. Or if you're already someone who know accessibility, that's great. This is something that you could also go forward and, you know, look at implementing it. I'll take a pause here. Cool. The pause is over. So I'm sure this is something would have already reflected in your mind, right? So I don't know how many of you had a smile after you read this. I had the first time when I looked at this picture, which is simple and easy enough that we think, oh yeah, it really makes sense. And how do we usually, you know, forget things, you know, right from, you know, our architecture buildings. So we talk a lot about, you know, our country, things especially coming from India, the transport is being bad, the roads are bad, and it's not accessible. But how, you know, what's the impact that we're making, right? I think forget about the technology, forget about digital accessibility. But this is all about what you can do to the human that is standing right next to you, who may be healthy, who may not be, who may be temporarily disabled. And it could be a number of situations that I spoke about, right? But when you think about that, I think that's where you may start making a small change for the better of the world. So with that, he'll take away as a learning. To me, accessibility is not just about physical conditions, right? It is not about physical condition at all. I perceive it more of a limited human interaction. So if we understand what that limited human interaction can do for our day-to-day lives, and if we find a ways to include them in the things that we do, I think that is great, right? Like say for example, if I'm using my computer to book, you know, flight tickets or air tickets. Yeah, it is developed with some ideology in mind that, okay, with someone who knows the civilized enough to know how to use a computer who can read English, who knows to use operate mouse, I think they can go ahead and click. But if you think of the other persona where someone who's blind or someone who is having vision but can't see different colors, you know, what is something that they would do, right? It'll become very hard for them to, you know, understand and go further with that. So to me, that is all about it. So this is something that I advocate wherever I go. And it's beat, I'm building a small house next to me and I'm making it more accessible as well. So that any guest that comes to my house will be accessible. And this is going to take forward in multiple ways in the society as well, right? And I think this is something that everyone should keep in mind and accessibility is not something, you know, you need a special learnings. And of course it has few nuances that you should learn and this session is going to be all about. And of this 45 minutes, I'm sure you'll be able to understand what are those at least and research by your own and try and contribute that. So as I've been keep on telling about the number of situations, right? So this is a beautiful piece of kit that Microsoft has provided, which is the Microsoft inclusive design kit, where it says about common things that humans do, right? So humans can touch, humans can see, humans can hear what is going around and humans can of course speak. But if we look at people who has some sort of disabilities, yeah, it's not their fault, right? I think some people born with some sort of disabilities and some people happen to be accidentally become one of that, you know, vulnerable to become one of those disabilities and also situational. Like if you look at, say for example, the first one like touch, there could be chances where you could have seen a human born without an arm and there's nothing wrong about it, right? I think it's all about if you find a ways to include them in our day to day lives and I think that's great. And an arm injury, I've broken my arms a couple of times during my childhood days and I know how hard it is. And even if you're a new parent, you're holding a baby in your hand and if you want to, you know, put a lullaby on your YouTube or want to hear a song. And of course you have to operate it everything on your single hand, right? If the applications that you access is not able to do things, I think that is where we are talking about inaccessible. So how did we make it accessible? And I think moving on from here, digital accessibility, that's where it comes to. So now so far we have heard about what is accessibility and in real world how people think accessibility means. And I think that picture that I showed you would have given you some insights about how you should start perceiving accessibility itself, right? Yeah, I think, I hope my audio is clear. Yeah, yeah. So what I want to say is, so similarly, if the applications that you develop isn't accessible, then you're creating a barriers and making their impairment a disability. So the key words to notice here is the word impairment. Definitely they have an impairment, but it doesn't mean that, you know, they can't do things. They can do things provided if you find a ways to include them. And that is, this is all going to be. Now, this is great Manoj, I understand. You have opened my eyes. Now tell me, how should I make them, you know, make them use the applications with that limited interactions. When it comes to especially around digital accessibility, there is a group W3C group, I'm sure most of you have heard about it. For those of you don't know what W3C, it's the World Wide Web Consortium. So World Wide W3C standards define an open web platform for application development that has unprecedented potential to enable developers to create rich interactive experiences. So any spec, any technology that you see like PDFs, for example, how PDFs should behave in a web browser is like say automation tools like Selenium, how it should drive the browsers. So everything has a specification. And if you're developing one such it should abide by that. And that is what W3C all about. And when it comes to accessibility, there is a small group within W3C called the Web Accessibility Initiative, which is the Y group, WAI, where they have given a beautiful set of recommendations and guiding principles, which is the WCAG. We call it as WCAG, which is WCAG. And then that's nothing but the Web Content Accessibility Guidelines. And this itself will take a lot of time if I get into what the guidelines are, but I have a good picture that I will show you next couple of slides. And when you look at these principles, the next question that will come to you, come to your mind is, this is really great. I understand there are some principles that I can look at, but is there a way that I can measure against, you know, what is the target that I should have. If I'm taking accessibility as one of my bets that I'm going to solve in next year, how should I measure against? So typically, all these guiding principles has some sort of, you know, levels onto it. So I'm going to cover this as well in next couple of slides. But basically, all you should think is there is, you know, level one, there is level two and there is level three, right? Apparently that's nothing but level A, level AA and level AAA. As you see, level A means you're trying to adhere to the basic level of accessibility, which means you're trying to address and make sure your applications are accessible with some basic level of accessibility, like making sure at least the basics are covered. Like, something is better than nothing, right? So or if you're, you know, if you really wanted to solve, you know, this inclusive space, and if you wanted to be your applications and products to be more inclusive, then probably, you know, you choose most common barriers where, you know, it's been estimated around 70% of the people with some sort of impairments will fall into this category. And it's been overall estimated around 1 billion people around the world have some sort of disability, right? And if you're building a product, which means, and if that product is not accessible, then you could imagine that, you know, you're losing out of business on that specific sort of people. So and the next level is AAA if that's the gold standard, which has around like 61 rules that you should abide by, right? And I think this is the levels that you could choose. And putting this all together, this is what the WCAG, you know, it tells about principles. It suggests that your application should be perceivable, operable, understandable and robust, and it has some guidelines on what you should do about it. And say as a company, if you decide that, okay, let me start with some basic accessibility like level A, then it gives you some guidelines on, you know, these are the things that your website or mobile application should abide by. And if you feel, yeah, I'm already done with AA and I'm going a little bit aggressive and making sure I get it to, you know, a special set of people. So that's where, you know, level AA comes into picture. So like that it goes on and on. And I think level AAA is, you know, it's practically impossible. I wouldn't say impossible, practically challenging, because it has to adhere to a lot of things. And I think that's where the interesting conversation starts to begin between a product owner of BA and a QA, because a lot of attracting challenging sessions will happen. So I think in my experience, most companies try to aim at AA. I think a few government agencies like the Gov.UK, Gov.US in the Australia, in the Europe, I think those agencies will try to abide by AAA. Otherwise, I think AA in my opinion seems to be, you know, a decent contribution that you can make to make, you know, the digital applications more accessible for people. Now with that, how can I take this back into my, you know, software development lifecycle? So when this is an interesting question to ask for yourself, right? So this is something that I tell everywhere I go. I think in any situations you would have seen that people tend to throw things on over the wall, especially if you're a QA, you'll understand how things that happens. But when it comes to accessibility, I would say, I think, please stop there, understand. It's not someone else's job. It is everyone's responsibility. No matter what role that you play in your current job, it's your responsibility. Right? Even if you're a dev, you're a product owner, a BA, say, if I QA, if you're a DevOps, you have a role to play there. I think that's, you should collaboratively, as a company, make sure that you arrive at that sort of, you know, collaborative and inclusive environment so that you think about those people and make sure, you know, you make ideologies and then take it from there. And I'll just speak to the next one. Yeah, so to begin with, in any, as if you're, you know, if your product is just shipping up and if you're trying to do, I think analysis and planning is one of the first things that you would do, right? So in my opinion, accessibility deserves a dedicated thinking and planning. But definitely, I'm not saying it should be done in isolation, right? Rather it should be integrated in your organization process. And there should be, and there will be some sort of legal requirements that will be needed depending upon which country you develop your product and which, where is your customer base. And if it's a global, that's great. You can just follow blindly the WCAG guidelines and pick up AA or AA as a success criteria. And that is good enough, right? But starting, I think early planning on accessibility, it'll lead to a lot of benefit, as I mentioned earlier. I think on an overall, if you look at in your experience, Manoj, tell me, I have a brown feed project. If I have to make my application accessibility, how much cost will take? I mean, I can't give you an exact number, but you could imagine somewhere between, you know, 40K or 50K dollars. So you can imagine, you know, if you spend that instead, you can avoid a legal risk, which will cost you billions and billions of lawsuits. So go yourself, check it out on the internet about, you know, dominoes, lawsuit, colds, lawsuit against accessibility. You can see how much they're paying back just because your applications are not accessible, where in that country, they have to be, you know, accessible enough. So yeah, you could avoid legal risk. You can strengthen your brand experience, customer experience automatically. So by being more accessible, your search engine optimization definitely gets increased. And you also, you know, try to tend to have the inclusive and productive teams. And so these inclusive design practices should be advocated very early enough. Like say, for example, one of the first things that you should you will be probably doing when you create a product roadmap is that, okay, a user goes to the website and do blah, blah, blah things. So when you define such sort of roadmaps, I think it's very important you should think of user personas with disabilities, right, with some user interaction. So when you do that automatically, a new set of feature or a new EPIC will automatically create it in an agile role in my opinion, and that's, I've seen that happening. So think about user personas with disabilities, design for user interactions, considers other experiences than a normal human would do, and automatically things will pick it up, right. And then finally, as I mentioned earlier, there are different levels. So, you know, understand the guidelines and see which user base that you cater to, which country you're coming from and try and add her to one of the standards. And I think that is a first step to start with. And really what's the next step at the design phase. It is all about, you know, starting as early as possible. I would say I already talked about analysis and planning phase thinking about product thinking about user personas. I think the immediate next step would be to start creating the UX prototypes. And it is also very important that you bake in accessibility at that stage early. So there are companies who follow some sort of design kits which will help them, you know, make a product seamless across different streams like you can take a look at Atlassian design kit. You can take a look at BBC British broadcasting. Global experience gel, so GEL gel is nothing but the global experience language where it is a document which shows you what an every accordion would should look like. How does the button should look like, how the link should be given. So, you know, by doing that way, you're making your product seamless. If you're a global product company, so that the UI itself is more seamless and looks pleasing and same across different, you know, different, different products as well as more importantly accessible, right. And when you look at the design phase, also, you can actually determine what are the colors that I'm going to do. Like I think the first thing that you will do is, you know, choosing a logo or, you know, picking up what should be the color theme of my website or the product. Right. I think in that way, if you think earlier about color contrast requirements or the color contrast guidelines from the WCG that I showed you earlier, I think you can easily, you know, cater to make sure that the color contrast is the same. Make sure that the color contrast is covered. And of course, think about technology that are inaccessible like flash, you know, flash is gone, but I think it's still there at some places and now even can was coming into picture. So you can think about carefully using the tech, making sure that it's accessible. And more importantly, contact a usability testing outside your organization, which will help you really understand, you know, where your product is, whether it's inclusive or not. And of course, the next is development phase where things get interesting, where it's very hard to convince your developers. But I think, as I mentioned earlier, if it's collaborative effort from the beginning, and I think this is something that can easily be tackle. In my experience, I've seen the checklist has worked often very well. So, you know, especially coming from a developer mindset, it is an essential at a planning stage when product requirements are defined and the design stage is created. And during development, the implementation of the product begins where if you have a checklist of, you know, things, and I have a link I'll actually share in the references or a little later. I think most of the things are can be, you know, looked at that checklist and make sure that you're making changes like it given at a story level if you want to make a change, you know, make sure that you abide by the checklist. I think that's that's good enough. And I think when it comes to accessibility, if you ask most developers, they would say yeah, I will fix it up with area. So that is something that we should don't think about so usage of area is should be done very judiciously. It's not like a patchwork to, you know, patch fix for your accessibility, right? So if you properly use your native HTML contracts, constructs, it will automatically fix accessibility issues for you. So you don't have to explicitly use or learn about area attributes so that you will fix accessibility accessibility is not just area, it's more than that. So even your proper HTML constructs will do the, you know, job for you. And more importantly, as I have as a second point, design what everyone can use and not what is easy to develop, right? And next is the most important in the testing phase where you should start considering people with disabilities for user testing. That is one of the foremost things. And we have a lot of tools and plugins in the accessibility space. And it's not a silver blood solution in any way. But it is estimated that it will try and fix you some 40 to 50% of accessibility issues for you. As I've kept on saying, something is better than nothing. So I think some start is better. It will help you fast track your process. You can include it within your CI CD pipeline. I think that's all great. And next, if as a testing strategy, if you're a QA or a test manager, or even if you're, you know, someone coming from a C-suite who's listening to the stock, even now or a little later in a YouTube, I think make sure, you know, accessibility is also big as part of your test pyramid. Like you have various levels of testing like unit integration and end-to-end. So make sure I know there are ways that we could include accessibility to each level, which I will cover that shortly. And specifically use screen readers. I think that is one of the main things. I'll actually have a demo and I'll be happy to show you in a couple of things, right? So and what is after testing, I think I don't have a slide next talks about what is next. I think it's more around, you know, maintenance and production monitoring and stuff. I think a couple of you would have seen or most of you have sort of a way to look at synthetic monitoring as a way. I think you can make an accessibility there as well. I think there's no harm in doing it. Since you're already doing at various levels, there could be something broken where you don't know. But I think it's great if something tells you that, you know, something is not accessible. And you can go and ask companies which does accessibility certifications to give you a VPAT or sort of a conformance document. So QA's can learn accessibility. Developers can learn accessibility. But when it comes to certification, it is a little risky. So ThoughtWorks doesn't do that or I highly doubt if services companies would do that. But there are specific, you know, companies who are dedicated for that who knows the in and outs of accessibility and who will certify you where you're up to, right? So with that, I'll deep dive on to the accessibility testing, right? So when we start early, you know, starting early brings in a lot of benefits. As I mentioned earlier, it's less costly than, you know, looking at, you know, solving lawsuits and stuff like that. And you should also make sure the designers, the product owners and everyone is onboarded. I think the most robust way to ensure the long term accessibility is to make sure that the accessibility as a knowledge is being, you know, inculcated within the culture. And if inclusive practices is not one of the culture, I think go ahead and make and advocate that for your organization and then keep that as, you know, upcoming bets to something that you could solve. There is no substitute for real user feedback include people with disabilities to test. I think this is something that I always say there are tools and we are super smart and good enough and there are some tools which claim a can solve things for you from accessibility. Honestly, I don't believe so please go ahead and include the real people with disabilities to test. So what is something that we can test for so you talk about, I think if you just, you know, quickly step back and see what we have learned so far. We talked about, you know, accessibility, what is all about. And I spoke and I mentioned you about some guidelines and I told you about there are different levels about it. And then we slowly transition into how accessibility can be fit into different levels, right. And now we are specifically deep diving on to accessibility testing as a phase and what is something that you could, you know, do keep on doing. And these are some of the things that you can actually test for like and test for keyboard navigation landmarks color contrast assistive devices. And in the previous slide if you remember I had a point which said that it's not a silver bullet which is still true. But if you remember it had a mention that around 40 to 50% it can solve so that is this slide talks about right. So if you make sure these things are covered, I think that easy 40 to 50 is automatically covered. And again this is not a silver bullet sort of like make sure you go test this and it'll automatically be 50% done. No, it's not that it's coming in from experience that I have made sure these things are covered in the applications that I test and I contribute to. And I've seen good progress with that. With that, I have four demos to show you will see if I have enough time to show that quickly one by one. Firstly I will show you a wise over demo. I think as I've been mentioning about screen really testing is something very important that you should go and advocate for. If you're a developer if you're a QA and if you don't have accessibility that's totally fine. When you do an exploratory testing. So just turn on your voice over if you're on a Mac or if you can install tools like Jaws for Windows and and even if you test or develop for Android and I was it has similar screen data options, which is nothing but the assistive devices we call it as assistive devices right where it'll help people with disabilities or people who can't see who can't hear will use these devices to navigate things around. And with that I'll quickly show you I'm hoping you can hear the voice over. Hey, I've turned on voice over. Chrome bit busy busy. Well, I'm feeling lucky button Google search by voice search list box pop up menu pop up combo box. A G I L E agile I N D I A in the agile India Google search leaving agile India Google search Google Chrome in Kotlin. So I had a quickly pause so that I can tell you and I walked through. So if you look at the this is nothing but the voice over right so as and when you move changes around like whether if you use a mouse or a keyboard, it will actually start dictating whatever you see right. So if you see when I press tab on my keyboard it automatically should skip to main content. So which is also one of the things that we should be making sure that is covered. If you're already testing a web application, load up the, you know, refresh the URL and just plainly click a tab button on your keyboard and it should show something like that because automatically it'll skip to the main content on the page. So in this case, the results on agile India is very important for me so that I can skip into it. Rather, I don't want, you know, the voice over to keep talking about all news maps images and all of those stuff. But in this case it automatically moved into it. So now what I'm going to do is click on agile India go inside the website and then do a few stuff. I don't know if you closely watched it it shows it said link twice but it didn't highlight anything which is an issue that you know, I think I'm one of the organizers to we as a team should fix our webpads. But I think after that it shows you where the focus is on like link sponsors and schedules and most importantly it didn't show the skip to main content as well. I'll quickly. So in this case if you see I moved on to the speakers page but then it's still dictating my, you know, the menu which as a user I don't want it right so you'll be annoyed by looking at it again so in this case I ideally I would like to have a skip to main content button so that I'll directly jump into the most very interested speaker I'm in so that I can listen to the talk. So I think I hope this would have give you some, you know, view about how, you know, what you're going to do. I think I'm going to have a skip to main content button so that I can listen to the talk. So I think I'm going to have a skip to main content button so that I can listen to the talk. So I think I hope this would have give you some, you know, view about how, you know, why so what testing is all about. So now if you're testing on a web application or whatever desktop application, turn on this voice over and see what it talks about right if you see. And this is not bad, you know, if you can, it mentions link speakers link schedule so that I if I'm blind, I am able to understand I'll just click on enter. But then I'll go into into that page. But if I'm something, you know, I can't see where it goes. I don't have an idea which which which page I'm thinking about it and that's something that you should look at. And now, in order to, you know, look at how things you can what are the different things that you can do. So the next thing that I usually do is to use plugins. One of the things that I use is axe DevTools web access everybody testing so you can just include a plugin and then just go from there. Where I okay I just saw an application that I built I mean reusing from Harris Harris from DQ has this wonderful workshop that I attended and I had an opportunity to reuse the same stuff. So I go and inspect, and I've already added the axe DevTools in my browser so all I'm going to just click is scan, click on DevTools and I scan all of my page. And it showed me it has two issues, right so automatically it shows element must have sufficient contrast and of course this one right is very important and it is one of the, you know, perceivable guidelines that even people with color blindness or with less vision or low vision should be able to look at the applications. And it will highlight you and also you can go and inspect and find out why it is there so this is the color button. And one of the quick fixes that even you know rather than finding a bug about color contrast you can even guide your developers and say that hey this is a bug that the DevTools shows. So when you click on this, it actually shows you by contrast ratio is just 1.19. But if you're abiding by the rule AA or AAA the conformance levels that I mentioned you earlier. It should, it says that if you're looking at abiding by AA it should already be at level three, but right now it is just at 1.919. So simply you can just, you know, drag this bubble and come inside this line, which means that okay you are good from a AA level which means that right now I'm at 3.7. And also you can actually naturally notice that this is becoming more visible even as a naked, you know, eye user. And if you're so as I mentioned if you're super aggressive about accessibility and wanted to be the gold standard, you know, further drag even more down. And you can see this is also picked where your contrast ratio is 5.73. And this is a generic rule, right? And this is just doesn't change per the color that you're looking at. So in any page that you take, if you're abiding by having 4.5 as a contrast ratio, that's good enough. That will work simply work for any page, a foreground background. So now you can see the text is also more visible. So this is one of the things that you could see and it has been estimated that at least out of, remember the WAI group that I mentioned. So they estimated at least 97% of accessibility issues that they have seen will fall under six categories, only six categories. So if you remember what is that six categories and make sure you fix them, you're already in a much better shape than, you know, having an application that is not accessible in that six color contrast is one of them. I know by now you'll be super interested to know, just give me that six and I'm done. Don't worry, I have a slide and I'll show you towards the end of the session. And Microsoft also have something called accessibility insights. This is something that you could install. It is more or less like Axe DevTools. And more importantly, you should also heard about Lighthouse, which has accessibility as well. So Lighthouse by Google under the hood uses Axe Core, which is nothing but this Axe DevTools. So in my opinion, it's either as fine should have to keep on using everything. So if you use either of these, that is great. And this is just for a plugin-based testing or a screen reader-based testing. This is, as I mentioned, accessibility is everyone's job. Everyone in the team can do it. So now if you're a QA or a Dev and if you're looking at what you want to do, as I mentioned, you could come and fix this. We have changed this color to be, say, 4.7 or 5.7. Grab the hex value, go to your CSS file and you would change it as a Dev. And that's pretty much it. So now what are the other things that you could do in here? I have two different workspaces. I think both of them will be in my GitHub page. You can take a look at it. So I have an end-to-end test folder, which has a complete test for each pages, which is nothing but this page. It's a simple website. I'll just quickly, it's in Agile India, which has actions. So if I just do tab, it should come here and just keep on going. Tab specifically, I'll do stuff. And if I go to about page, it's just a couple of things around here and also a contact on a form where if I keep on doing a tab, it should focus each and everything. So which means that if you don't have access to a trackpad or even a mouse, you should be able to navigate by a keyboard. So that is one of the things that I mentioned on the QA testing aspect as well, where keyboard navigation is one of the things that you should look at it. And I have this website where we are closely running on time. Let me quickly show this up. So yeah, right now if you see, I'll just refresh this website and I'll do the tabbing. I'm not using a trackpad at all. It shows skip to main content and then it's coming here. So now I don't, I didn't click on skip to content. Now if I'm doing skip of the main content, it automatically comes to the contact page. And now I'm checking in message and asking Naresh, what do you call sheep without no legs? It's just a small pun. It already says he says it's a cloud, right? So you could imagine it's just a diagram of the cloud. So everything is done within a keyboard. So you could imagine without using mouse, you're able to do stuff, which is really great. And if you're able to do this in your applications, and that is what more important as well. And now specifically coming back to, you know, testing as such, what is something that you could really do? Well, we had a menu button which has the actions, right? So ideally what we should be doing is focus on the menu button, the actions. And then without using mouse or a trackpad, if you click on the, you know, up arrow and down arrow, it should be able to traverse up and forth, right? I think that is exactly what, you know, the test does here where you're trying to look at it. And there are many other stuff which we have written here, like role as a button. And even like say for example, let me go to my index. The role is a very important item. Like say for example, we have a menu item and we say the role of that button is a menu. So if I go and change, like say for example, you know, agile India, it shows an error, right? So which is nothing but an error which shows elements with earlier roles must use to valid and non-obstruct earlier roles. And this error message is coming in from an excellent plugin that I'm using in this repository, which is called JSX Ali area role. So by this, what I'm trying to say is you don't have to keep on writing an end-to-end test or use a plugin or use a screen data to do testing. But as a developer when you write, when you, you know, write your HTML code, if you make any small mistakes, it'll automatically show you. It's nothing but code linting or scanning tool, which we normally use, right? And this is something that you could use. And if it'll go back to my package.js and I have something here like eslin plugin JSX Ali. So as a dev, it'll be super awesome. It'll be helpful. Like when you write a component, a piece of code, it'll tell you where it goes wrong. And the next demo that I had was a completely, you know, a web driver IO based demo where it'll, you know, this is nothing but a page object pattern where I have a base page homepage and a menu page and I have a spec file and I run the spec file. It'll, you know, the web driver test will go to that website and land on that website. As in when it lands, I'm using acts to scan my page and I'm just saving that results in a CSV file. So this is something that it shows as a result that ensure contrast between the foreground and color meets. And, and it'll tell you, it'll give you a HTML dump also so that you can fix it things online. And more than that, one of the things beautiful things about acts that I like really is all about the link that it shows. Like when you click on this link, it'll actually show you what are the things that you would want to fix as well. Right. So it'll also show you how to fix the problem and why it matters so that you also learn while you fix things. So that is one of the good things. So go ahead, you know, use tools like acts and I'll open source it with my GitHub repo at the rate of Manoj 9788. And that's my GitHub ID also can keep watching and keep doing that. Yeah, just a heads up like, yeah, we just have a couple of minutes more. Yeah. Yeah. So I'm putting this all together. Here I present to you the accessibility test pyramid we have seen about accessibility, you know, test pyramid or, you know, the diamond or a champion trophy. I wanted to try different. So here is the accessibility test pyramid I showed you about the static linting checks. So there you go. That's at the bottom. You can tools like that. So this shows you accessibility is everyone's responsibility where user persona something you could do it early when it comes to development. Right. When when you code, it'll show you using those plugins. And as a unit test, if you're using X core or adjust tools, you can integrate with those and do some sort of integration testing. And as a QA, if you're running an end to end test automatically, you can integrate with Selenium and Cypress and also use the plugins that I mentioned to you, right? I think that I showed you something that you can do now to scale it further. So by the moment you integrate into the test pyramid or have an auto into an automated framework, you can obviously scale this into a path to production. Right. And of course I wanted to present to you again, an inclusive path to production. I don't know if I've seen this word everywhere outside, but this is something I think it's quite new. So inclusive path to production, right from concept to deploy to production to disaster recovery. There are different stages as per your product. You will have different builds. And this is something that I currently practice and advocate for my toolbox clients where where where you can do what sort of accessibility testing. So as you see, the things in that are grade out or something that is not necessary for this session, but also very important. But the things that are highlighted in Ali or something that is very important and also a key takeaway for you as well. So take a look at it offline if you have any questions, you can ask me around it. And these, this is nothing but the six common errors that I talked to you about. So low contract stacks, missing alternative, missing input labels, you know, empty links, empty buttons, document language. So these are the things that are significantly will improve if you, you know, make sure that this is not something happening in your things. So I think I think this mostly end of my session with that. I just wanted to thank you so much for people joining and I consider this as a passion. Let us hear, you know, I see a couple of people already here. And if you're already coming into the session, which means that you already care for accessibility. So that inclusive mindset is already within you, or even for people watching this offline in a YouTube or little later. If you're reaching out to session, it's already, you know, it's known that you're, you know, accessible enough and, and, you know, go back and create inclusive culture at your company. Be an inclusive tech disruptor, not just a tech disruptor, but as an inclusive tech disruptor. And I do hope that you had some of that key takeaways from the session and then, you know, make the world more digitally connected with inclusive inclusivity. And this is some of the links to refer you can go ahead and refer. And lastly, thanks for the opportunity to talk about an important topic that I most care about. And not only my talk and I think there were two other talks that spoke about importance of agility and inclusivity. So please go ahead and check out the other talks as well. And I think as a conference, I think this is something we care about a lot and lots of gifts out there and happy Thanksgiving and a new year to everyone. Thank you. Thank you so very much. So there was so much information about all about accessibility and especially inclusive path to production was something really new and yeah there's so much learnings there. And I'm sure a lot of people have enjoyed the session and they got a lot of takeaways.