European Accessibility Act: What Software Testers Need to Know (Actionable Guide) with Laveena Ramchandani

[00:00:35] In a land of testers, far and wide they journeyed. Seeking answers, seeking skills, seeking a better way. Through the hills they wandered, through treacherous terrain. But then they heard a tale, a podcast they had to obey. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.

[00:00:35] Joe Colantonio Hey, Guild listeners, today's episode is a little different. I'm sharing a recording, one of our monthly live Automation Guild member only trainings. And trust me, it's a session every software tester should hear. Our guest, Laveena, a seasoned quality engineer lead and accessibility advocate walks us through the upcoming European Accessibility Act and what it means for devs and testing teams. And most importantly, the practical steps we can take right now to shift accessibility left in our flows. Whether you're testing in the EU or not, this is something you need to be aware of. Now, this webinar is just one example of what you get with the Automation Guild Instant Access Pass. A lot of people don't know, but after our annual Automation Guild event is over in February, you can also purchase an after event ticket that gives you on demand access to all the sessions from our latest annual event. But you also get exclusive new live training like this one every month. If you want to learn more? Definitely head on over to Automationguild.com or use our special link with the discount down below or in the comments, wherever you're viewing this podcast. All right, let's get into it. Here's Laveena all about, are you ready for the European Accessibility Act? Let's check it out.

[00:01:51] All right. I think it's probably a good time to start now. So I just want to welcome everyone to our first monthly training for Automation Guild 2025. Elite members. So you are all elite. So thank you for joining us. Today, we have with us, Laveena, who's a testing expert. She's been part of The Guild for a while and she's talking about a topic. I think it's really, really important about accessibility, The European Act of Accessibility is coming up and I think if you do anything with software, especially if you're in Europe, especially the U.S time kind of lags behind, so I'm sure U.S will do something similar. You need to be aware of what's happening. So really excited to have Laveena join us. Just so you know, this will be recorded and it'll be uploaded to the community later on as well. And if you have anything or any questions to ask any time, just raise your hands and I'll be happy to ask you a question. You can ask your question too, Laveena of when, when it's appropriate. So Laveena, welcome to The Guild. Good to have you.

[00:02:41] Laveena Ramchandani Thank you so much, and thanks for having me, Joe. Really lovely to always be in one of your events. Welcome to my talk on Are You Ready for the European Act of Accessibility? So the reason I'm giving this talk is not because we want to wait for any legislation to come in place to act for accessibility, but to also be aware of what this is about and how we can act before it comes into place, or just always be thinking about inclusive design. So before we get started, a little bit about myself. I've been in the testing world for over 10 years now. I think it's my 11th year this year, and I actually fell into testing. I had no clue what software testing was about because in my degree, they only spoke about black box and white box testing back in the day. The first ever project I got with a consultancy called CGI, they said we want a test analyst. So I was like, let's go for it. And that's how I got into testing. I'm a blogger, I've hosted events in the past. I'm an avid speaker. I speak in quite a lot of events, do tutorials, even been a trainer at the Coders Guild, a member of the British Computer Society and the specialist group of software testing. I currently work at EasyJet as a quality engineering manager as well. And one of the quotes I've really, really liked to talk about a lot, which is by Tim Berners-Lee, is the power of the web is in its universality, Access by everyone. Regardless of disability is an essential aspect. So this is really important because why are we waiting for things to be developed and then think about accessibility? Why can't we embed these things before? Why can we be more socially aware ahead of time? So some pictures that I always like to obviously discuss about when I talk about accessibility is how many of you must have ever walked on a footpath and fallen over or had tripped over because the floor is uneven and I go with a buggy with my little one and even if the buggy is moving at its pace, I still trip because it's just uneven and it's not a great design. Or how many of you have gone to a supermarket and actually me being a short person, I can't really reach to the highest level to get what I need. I need to always call for someone to help me, whether that's at a supermarket or any shop really. And then the push and pull process. How many times some doors make the mistakes or some companies make a very bad design and there is a push process, but you pull and all the other way around, there's a pull process and you push. Sometimes I've ended up even banging my head on the door because I don't know where I'm going. These are just some common errors that we get in the design of everyday things. And this is a really good book to read as well if you are keen about why things are designed the way they are designed. So it's called The Design of Everyday Things by Donald Norman. And this how our systems work as well. We tripped, we cannot get things from our applications. We are stuck. So we get a trap, keyboard trap for example, if we are using only a keyboard. And I just wanted to put things in perspective to our website applications. That's why I put these real world images to showcase how our applications also struggle with these things. So according to the WHO, there are an estimated 1.3 billion people experiencing significant disabilities. This represents 16% of the world's population or one in six of us which means improving accessibility increases a company's reach immensely. As you can see this picture by Microsoft and I really really appreciate this picture is Disability cannot be something known as a permanent disability only. We have to bear in mind it can be temporary or a situational disability as well. I remember when I had my little one, I was sometimes giving him a snack whilst typing an email and that's a situation disability, right? Or right now, I'm wearing contact lenses because I won't be able to see all of you or the screen. I've got a permanent disability as well that I'm short sighted, I need glasses. So we need to think from all of these perspectives and build things to support permanent, temporary, and situational needs. A really interesting question that keeps coming again and again, do we really need to wait for a law to come into place to act? Because why is it that companies always have to sort of rush their development teams or engineering teams that, oh, the European Act is coming, or the VPAT is updating, or the Section 508 is updating in the U.S, for example. We need to sort of hurry up and look into accessibility, check that our web applications are audited and we are compliant to all of them. Why is it that we wait for a load to come in place to be worried about things? Why are we not thinking ahead of time? If we are so worried about thinking about other non-functional needs in our applications such as security testing, such as performance testing. Why is accessibility testing always never thought of really? Why is it that we think of it at the last moment? Or why is it, that we think that the application we are building is only for our customers' needs, so we're going to make sure that it's accessible to customers, but never think about the people internally. There might be people who might be colorblind, there might be who might working with one arm, with a temporary disability, why are we always a bit partial to things? Why don't we think about inclusive designs? Why are we not jumping ahead of time and building these things in properly? So the answer to this is no, we don't need to wait for a law to come in place. We should act ahead of time. We should talk about these things early and shift left with them, which I would come to in a bit. Some accessibility issues. So A11Y is basically a shortened version of accessibility. It's because accessibility has 11 characters, so we've just shortened it down. And some common issues include poor color contrast, cannot navigate with a keyboard, so you have a trap on a website, inaccessible form, so you try and click to access a form and basically the form would never open up. Non-responsive mobile design. So you're trying to work on a product on your mobile, but it's actually not responding as it should. Missing old text form images. If someone is having a screen reader, you should always have a little description and a meaningful description under images so that the screen reader can describe that for you. Improper use of headings. What I mean by this is you start with header one and then you straight away jump to header four. What about header two and three? We should go by process, not by jumping into different heading styles. Text size and line spacing issues. So if you are using a type of text size, be consistent with it. Don't keep changing throughout. And then line space issues. Sometimes you might have double spaces and the screen reader might get confused as to why there's too much space between this sentence and not the next. And inconsistent navigation. What I mean by this is you might be starting at a header level and then you should be going down to the subheading, but you're jumping into an image straight away with your screen reader because that's how it's been coded. It's very, very confusing for someone, say for instance, who's blind, who is trying to book, for example, flights to go to a holiday or maybe ordered pizza from Domino's. Why should that person struggle to do basic things like order a pizza? They should be able to navigate, choose the toppings they like, have a very smooth process that has little to no issues until the checkout and until the product arrives to them, right? Should be seamless. But are we doing that seamless work? Are we actually putting that much effort into our engineering teams is a big question.

[00:11:03] Next section, which is the importance of accessibility in design. So of course, let's understand mainly the definition of accessibility. Accessibility refers to the design of products, devices, services, or environments for people with disabilities. It encompasses ensuring that individuals with various physical, sensory, and cognitive abilities can use them without barriers. So this is the definition we should go by if we are trying to make strategies or anything to help people understand and stakeholders understand. Inclusive design principles. Why should we have these? It's because inclusive design involves creating solutions that are accessible to the widest range of users. Us as testers, we are always looked at like type of end users or UAT users. We will naturally, by using the product, become so comfortable with it that we might even not think from accessible ways. We definitely need to either have the right individuals in-house to test the products. Or have the right sort of tools to tell us that we are accessible or not. And again, with inclusive design, as it says, key principles include flexibility in use, simple and intuitive interfaces, and equitable use that caters to diversibilities and preferences. The benefits of accessibility for users. So of course, it enhances user experience for everyone, not just those with disabilities. And this is something that so many people have been telling me that if we build the product that is very good accessibility wise and gets good audit reports and everything. Generally like the users really enjoy using it. It's so easy to use, it's understandable, it may not be very fancy, but it's doing what it's meant to do. It leads to higher user satisfaction, increased market research, compliance with legal standards, ultimately benefiting organizations, and society. At the end of the day, getting a good reputation for something that may not be fancy or flashy lights and all of that, but actually doing the job that it's supposed to do. Some real world examples of accessible design. So examples of accessibility design include screen readers for compatible websites and even mobile. Plugins to assess a web and mobile as well. So by plugins, I mean on Chrome, you can actually go and put tools like Axe, Wave, and other tools that you, or even Lighthouse, to just do quick checks and understand what are the issues that you're seeing. Real world examples include also wheelchairs or accessibility for buildings. I remember when I joined this company, EasyJet, I could never find a lift in the office and I asked someone, what if I come one day with a broken leg? How do I make my way up to my desk? And no one could answer that because even the receptionist didn't know how to access these lifts and where they were. However, now the design has changed and they're very obvious where the lifts are. Of course, air travel services offering assistance to passengers with disabilities as well. So you can obviously in real world now, when you book your tickets, you can actually ask for support. They give you buggy services, they give you wheelchairs and whatnot. These are sort of real-worlding examples of accessible design and inclusive design, I would say.

[00:14:35] Laveena Ramchandani So going on to the European Act of Accessibility, so this is something that's coming in the next two and a half months-ish or nearly three months, but let's have a look at an overview of what this actually is and who it impacts. So the European Act of Accessibility is a legislative framework aimed at removing barriers for people with disabilities across the EU essentially. It promotes equal access to essential services, ensuring inclusivity in both the public and private sectors. This should not only be thought as within the EU, but if you are working with a customer who is in the EU it also impacts you essentially. So your product might be a tool placed in France. So of course, we need to think about that. And the one interesting bit is that when I was researching about this, I came across this timeline. The EAA has not been thought of for 2025 recently, it's been there since 2019 where it was first published and then in 2022 adopted actually. And in 2025, it will be enforced so companies have to actually showcase they are compliant. And by 2030, the deadline for removing inaccessible product. So they're giving you time for five years to actually plan this thoroughly. Have the right sort of audit tools or audit companies to come audit your applications for you. Have the WCAG 2.2 applied to your products so that you are compliant with how this law is going to be going forward. And also, within the five years, most likely, if you do comply with everything that this law is putting out. Then you should be in a safe place and your tool should be accessible really. So key objective of this law really is to improve accessibility for public transport, buildings, and digital services. And when we think about digital services, it's literally all of us working online really with any tools, any companies, and how that is going to really be impacted by the law. This initiative seeks to create equitable environment where individuals with disabilities can participate fully in society. I think this law will showcase how good we are with these three areas, public transport, buildings, and digital services. And I can already foresee a lot of news reports coming out when this law comes in as to how many companies are not doing the right thing. But this is our chance to actually use our learnings from the past. It's giving us five years to work on it so that we are safe within the law and then actually have this inbuilt into our strategies as part of non-functional testing. Again, we do not have to wait for a law to come in place to think about this, but now that we're so close to it, we have to start thinking of adding this as part our ways of working. And it's a mindset shift. It takes a lot for us to sort of bring this onto the table and I'll get into that in the next few slides as well.

[00:17:54] Joe Colantonio Laveena?

[00:17:55] Laveena Ramchandani Yes.

[00:17:55] Joe Colantonio Who made your company aware of this law? I don't know if that's a dumb question. Is it that the testers job is to say, Hey, this law is coming into effect. We need to get on top of it. Or does it come from the top down?

[00:18:06] Laveena Ramchandani I'm the person making people aware in my areas, the areas that I'm working in IT and e-commerce, but I've not heard anyone or any email from HR or from marketing or sales showcasing that we are working for this rule, for this law. It's a bit of a, how shall I put it? There is an agenda for it, but it's not being promoted within the company because I'm- advocating for this. A lot of different areas are coming up to me and asking for tips and actually getting my input on their systems and applications that they're building. But there's no such communication coming from top down really. It's more about I'm going around making awareness, which is a bit of a, how shall I put it? Not an odd one. It is again raising awareness, but it should not be this way. I would expect it to be top down. I'd really appreciate if a law team was talking about this on our old hands or something telling us that this rule is coming out next year and we should also focus on this within the company. We are a low budget airline and we need to not only focus on our digital services but public transport as well. It comes into both areas and the buildings as well because our check-in counters and things are within that building of the airport, right? It's something that should come from, I think it should be right to come from the low side of your company. But I've not heard of anything as such, not only here in other companies, big consultancies, never hear anything.

[00:19:50] Joe Colantonio Oh, okay, okay.

[00:19:53] Laveena Ramchandani I think-.

[00:19:53] Joe Colantonio Disturbing.

[00:19:54] Laveena Ramchandani It is disturbing, but it's an opportunity as well, if you think about it, it's a opportunity for us to go and make noise, but noise in a positive way that will be taken very negatively as well. It's one of those where we have to focus on how we communicate this with our stakeholders, which I will actually talk about, I think, in the next few slides. Perfect. A timeline for implementation. So the law is set to be implemented by June 2025, 28th of June actually, providing a clear timeline for organizations to adapt their services. I think in June, there will be something that you will see that will be all publicly available to all of you. If your companies are communicating this to you, then they should be able to provide this to your as well. And this timeline then encourages proactive steps to ensure compliance and enhances accessibility, gradually avoiding last-minute changes. I would take this opportunity to plan properly with your team and work on a strategy that includes accessibility throughout your development process. It should not be something that comes at the very last minute. It should be always something that's spoken from day one in your planning sessions. Again, who will be affected? Quite a lot of companies are going to be affected, including stakeholders, including businesses, public institutions, and service providers, really. I would say a big chunk will be affected. And as I said, if you are even in the U.S working for a product that's in the EU, I'd start understanding how it's gonna impact you and how you could actually help with testing, really.

[00:21:30] Laveena Ramchandani Okay, so shifting left with accessibility testing. So the main bit, how actually do we talk about this, advocate about this and how do we bring it so that we start acting on it? What does shifting left mean? So shifting left does not mean that we're just gonna move and shift left. Shifting left refers to the practice of addressing accessibility concerns earlier in the software development life cycle. How I feel about this is, imagine you're baking a, in the COVID times, there was this cup where you would put all the cupcake ingredients inside it and put it in a microwave. And imagine you're making a blueberry cupcake in the microwave. Would you rather make that cupcake and put it in the microwave and once it's fluffed up and put the blueberries on top or would you rather put the blueberries inside so that they burst and the flavors come out and the cupcake is more delicious? Think about it from that analogy. If you're gonna put the Blueberries inside you're baking accessibility into your systems. If you're gonna leave the blueberries on top, you are acting very last minute to accessibility, leading to a lot of changes, a lot costs, a lot defects and a lot retesting and reshuffling and all of that hassle that comes last minute leading to bad reputation and your cupcake won't taste as good either. So think about it from that perspective always. The importance of early testing is basically conducting accessibility testing early in the development process maximizes outreach and user's satisfaction. What you can actually do is if you have budget as well, you can hire people with disabilities who are open to testing, who will give you real and honest feedback as well. If you have that opportunity, use that. Identifying issues sooner can result in lower costs and reduce the risk of non-compliance with accessibility regulations, ultimately leading to better overall product quality as well.

[00:23:33] Laveena Ramchandani Tools and techniques for accessibility testing? So a variety of automated and manual tools are available for accessibility testing. Popular ones that I've already mentioned, Axe, Wave, Lighthouse. For automated checks. You can actually automate with Axe. I'm actually right now trying to build a pipeline that does our audits with Axe. And every time we merge, this pipeline would run and give us throughout all the vulnerabilities before we actually merge it into the right environment. While we do manual testing by users with disabilities, it reveals real-world usability insights as well. If you have the budget, I would definitely ask you to invite UAT testers who come with a disability, a permanent situational or temporary disability, who can actually give you real insights of how they feel when they're using your application.

[00:24:26] Working towards the change. Developing an accessibility strategy. So what does this mean? This means having a strategy that's not only a testing strategy, it's a strategy that the engineering team is also included in, but includes other things other than automation testing, CI/CD pipelines, DevOps, cloud integrations. It should also talk about accessibility as well. Why should we have this? It's because it would assess your current practices, it would basically allow you to become better at what you're providing quality-wise, it would help you identify gaps earlier, and it will really lead you as a team, as an engineering team, to have clear, actionable objectives. Basically you would be setting clear and actionable objectives as a team and moving forward so that your SDLC includes everything as well as accessibility testing in it. And again, this strategy should align with the broader organizational goals or values that exist in your company and incorporate guidelines from the EAA 2025, ensuring all team members understand their goals in achieving accessibility compliance. Again, it's not really easy for us to bring a law and not train our members, it might come to them as a little bit of a shock as well so we should be a bit careful how we're going to do this and provide the right sort of tooling training and a lot of other sort of training that could help our teams see the vision that we're trying to provide. Engaging stakeholders and teams. This is super important as I said sometimes me being an advocate, I've gone across to provide an opportunity. And it's been seen as a threat, or why are you telling us this? We don't have budget, we're just doing a B2B product, we're not doing a B2C, and it makes you think, and it just showcases that people don't want to put time or budget into thinking about this. But involving stakeholders, as it says, is crucial for successful accessibility initiatives. It fosters open communication with all parties, including development teams, management, and users with disabilities, to ensure diverse perspectives are included in the decision-making process, leading to more effective and inclusive designs. I know it can be a bit daunting and a bit frustrating when people are not understanding your vision, but it's not just you who's trying to do this. If you all do it as a team, you're working as a time towards the same goals. So I would suggest it might also mean that we need to work on the way we communicate, how do we change our communication to get more engaging conversations and to persuade teams that we should be looking into these things as well. So it might mean that I need to work in my communication skills or I need present something in a manner that my stakeholders understand better. Maybe that could be images or pictures or diagrams rather than just legislative information because that can be sometimes a bit too timely, monotonous, and maybe something that stakeholders might not be understanding at their levels. We need to understand how to engage stakeholders and how to have the teams on board with this as well.

[00:28:05] Joe Colantonio Laveena, quetion, are these rules generic or someone asked a question in the chat or the application, should they depend on the application and target audience? For example, if it's a tracking application for cycling, should we build it accessible for blind people who are hardly the target audience, like how do you know when to build it for accessibility? I don't know if that makes sense.

[00:28:29] Laveena Ramchandani You're saying that the application is for cycling?

[00:28:31] Joe Colantonio Yeah, for the example, say the applications for cycling. I mean, in theory, you're probably not going to have someone that's blind, but-.

[00:28:38] Laveena Ramchandani Of course. Yeah, I think that is all to do with market research and who your actual-

[00:28:45] Joe Colantonio Hey Laveena, you need to cut off.

[00:28:45] Laveena Ramchandani They might not want to cycle, but they might be intrigued in understanding what this application really does. Let's think of accessible designs for the people that do not have disabilities either because an inclusive design means not just people with disabilities but people without disabilities should also be comfortable to using it. So yes, we might not see someone blind cycling but you never know. They might want to see how the application works with a fellow colleague or a friend or someone. Always focus on it's not just for people with disabilities but it's for an inclusive design. Inclusive way of working together with the society and being socially aware really. So I hope that answers the question.

[00:29:32] Joe Colantonio Do you know if they're enforcing that say, you have a cycling application. It's not built for blind, people that are blind. Would they be targeted or would they be fined? Do you know how that's going to?

[00:29:46] Laveena Ramchandani There are penalties involved, but I think if you clearly define the end users somewhere in an FAQ or somewhere on your applications, then that could be something clear for these people. They might think that oh that this is a company that we should be looking into for a penalty because I don't see accessibility but if you state it somewhere on you application in the FAQ section or just speak to some sort of law team in your company to understand should we be looking into this or not and get something written officially, then that is something that you should not get penalized for because you're setting up your clear goals and you're showcasing that this is for a specific target audience and most likely we don't need to go with the European Act of Accessibility. I would actually work with internal teams first, get something officially signed off with directors, with CEOs, and that's when I would get enough confidence that I don't need to worry. I would not just leave it to an engineering team to sign this off.

[00:30:54] Joe Colantonio Perfect. Nice.

[00:30:54] Laveena Ramchandani I think you need to hire people to sign this off, and then it should be like, okay, now we can focus on other things that we've thought about this. Perfect. Training and awareness programs, of course, implementing training programs on accessibility best practices enables teams to understand the importance of inclusive design. Feel free to sort of showcase how to use these plugins like Axe, Wave is a really good one as well. Equal Web is really good as well, it provides you an auditing report as well as it throws out vulnerabilities of what a specific page is not doing right. And you should have people who have used this before and they can basically set up a little workshop or just showcase the team how to use these things in the correct manner. And this would make the team also feel a bit inclusive that we are not just being told to test, we are also given the right training on how to do it so that we can provide the right sort of quality at the end of the day as well, and report on the issues as well. Measuring success and compliance, so tracking progress towards these accessibility goals can be achieved through regular audits and user feedback. As I said, if you have the budget, invite some people with situational, temporary, or permanent disabilities, and actually ask their real feedback as well. Establishing key performance indicators, or KPIs, related to accessibility ensures that organizations remain accountable and compliant with the European Act of Accessibility 2025, while also enabling continuous improvement in design processes. I would always have some sort of audits going on, whether you're doing this online with EqualWeb or any other tool, or whether you are calling a company like ShowTrust. I think the one we use is called ShowTrusted. They come once every year and they provide a good report. And then we basically move them into our backlog items and we work and do a re-audit again. Again, auditing also works really well. So for the cycling company. If you did do an audit and the auditors came and said to you, you have clearly defined your end users, you've clearly defined everything, your application is accessible, but it does not come under the Act, then you can use this report as well to showcase that if someone wants to penalize you, you can showcase them the audit report and say, we've been audited, they clearly stated this, why are you penalizing us? If you have these regular audits, it helps. Every case basically. Conclusion and call to action. The summary key points of this talk is basically not waiting for a law to come in, acting before it or just making sure that you are including this as part of your development. However, the European Act of Accessibility aims to enhance digital inclusivity for all users across the EU by 2025, giving you five years to adopt all of it. I'm not sure what process they're going to do to basically penalize people by 2030, but I'm sure they will have ways of understanding what product is accessible versus what's not, and then companies get communicated about that. The key points include the importance of adopting accessible designs, the necessity of early testing, and active stakeholder engagement to ensure compliance and improve user experience. A good- task as well that I really enjoyed doing at Deloitte was whenever I would test for accessibility, I would sit down with a product owner and be like, so what do you understand by what I've tested here? Do you understand what I'm trying to do or improve? And just having this basic conversation would tell me if this person is understanding what accessibility testing is bringing onto the table or not. We don't want stakeholders to just be like, okay, it's important, let's bring it in. We don' want to be penalized, but we want them to also be part of it and understand it and breathe it really to be able to showcase the KPIs to their stakeholders in the future. Next step for organizations. Organizations must evaluate the current accessibility practices and align them with the European Act of Accessibility requirements. Consider forming dedicated teams to continuously assess and improve digital accessibility methods while prioritizing compliance and user engagement. My suggestion would be for you to research which team is actually looking into this in your company and discuss with them about your tool and ask them what is their plan for the next few months, two years, and if they know which team's going to work on it and if you could support them with any strategy work or any knowledge that you have that you could bring to the table as well for them. Encouraging an accessibility culture, building an organizational culture that prioritizes accessibility, involves regular training and awareness programs. Engaging employees to all levels ensures a commitment to inclusive practices and fosters an environment where accessibility is a shared responsibility. That's why I said, if you are testing something involving some of your team members to look at what you're doing is including them and helping them understand better as to why this really matters. And this is something that I drew up of what good looks like. What good looks like is when you are doing a feature planning session, in this session you can actually discuss the features that you're looking into basically to be developed and tested for accessibility. You should basically identify tasks that could be focused on accessibility testing and that very initial meeting in your scrum teams or agile teams. When you go down to the design team, you should work on designs maybe via Figma or other tools that you have and have an accessibility plugin which is called annotation on Figma and create any designs with these annotations in mind. Figma basically allows you to create frameworks and basically any sort of mobile design or web design but with annotations telling you that this would be a header one, header two, header three, header four, it goes very processed like in a processed way. And then If a developer or a tester were to come and look at the design, it would be so much easier and understandable as to how to develop this now.

[00:37:32] In the next stage of given test, or if you're doing this as you're incrementing in an agile way, developers should write their code with accessibility in mind and follow best practices and basically showcase some code or anything to the testers as well so that you are all sort of working in a collaborative process. And testers should use the accurate tools when it comes to testing as well. So I know in the past I've worked with some testers who are using their mobile phones with a voiceover on their phone. And I was feeling like maybe using our personal phones might not be a good idea. Maybe we should use a tool or maybe we should have company products available to us where they're totally unbiased products. We just load up the application on it and we test it. I think that works wonders as well. And then when you're on the deployment stage, build a pipeline with Axe, for example. So every time that you're merging and sort of creating a build, you know that the build might not pass because you found a vulnerability. You'll have to go fix it before you actually proceed. And of course, remember to audit any of your accessibility work because it can come handy. You never know when. ShowTrust is a good company to use, not sure if they do something in the U.S, but would be good to look into. And ask them the right questions and ask them like this bicycle app question. That would be really good because they could be an official provider who could actually write a report for you saying that you've clearly defined your users and this is not a tool for people with disabilities that are permanent, for instance. The law should not apply to this application. So this is how we should really be working towards. We should have a pipeline to deploy into production with accessibility checks. And that is what good could look like for all of you. I know it's not an easy process. It's a lot of conversations. It's lot of stakeholder management and expectation management. And it could be something that you end up doing on a side as a mini project with some other advocates. But I will tell you one thing, it will be something that you'll really feel really proud about once it's in place. Actually doing this as a mini project with a certain set of advocates right now in the company on top of the work we already have as well because otherwise it's not going to get done ever. It's up to you how you want to do it. But as Joe asked a very good question at the very start, should it come from top down or bottom up? I think, if it comes from top down, it's really good, the whole company knows, but if it comes from bottom up, there's opportunities for us to really discuss about. You have the power to make the changes. Are you doing it? I think we should all be very socially aware and make these points very obvious into the workplace we work into and with the colleagues we work with. Sometimes there are colleagues who are aware of these things. They've worked with these tools, but because we are not talking about it, we don't discuss enough. Let's all of us be socially aware and make our applications more accessible and with inclusive design. Thank you very much and I hope you enjoyed my presentation. I hope I didn't waffle too much.

[00:40:59] Joe Colantonio Laveena, we have a few questions again, a bunch of claps in here. Monesh wants to know, who should take the responsibility of creating accessibility requirements, PO design. I believe testers would do the test against the requirements, not ad hoc accessibility tests.

[00:41:16] Laveena Ramchandani Could you read the question again to me, or if it's on the chat, I'll read it.

[00:41:20] Joe Colantonio It's in the chat.

[00:41:21] Laveena Ramchandani Who gives you the responsibility of creating accessibility requirements, a product owner or design? I believe testers would do a test against the requirement, not ad hoc access. Yes. So a product-owner would be really good to make your epics for you. I work with a really, really good product owner who puts everything into perspective with acceptance criteria, what's in scope, what's not in scope. And then basically, testers plan their testing according to that epic. It shouldn't be that they're ad hoc testers that we just ask them, could you please check this for us last minute or something? We should have this all planned in. And I think POs should be the best persons to actually make an epic for accessibility in your backlog. I hope this answers your question, Monesh.

[00:42:10] Joe Colantonio And then follow up, you can always just turn your audio on. That's fine. If somebody have any questions. Let us know. What's the first step you think the easiest thing for people to get started, they heard us and they want to go back to that company. What do they do?

[00:42:25] Laveena Ramchandani I've actually seen Chris, I think. No, not Chris, Stephanie. Stephanie, she's put the links that I sent her about the Web Content Accessibility Guidelines and the European Act of Accessibility. I would suggest all of you to have a skim of that and try and understand what this is saying. You are all gonna get very confused when you read the WCAG 2.2. It's not very easy, but if you can simplify it by using any AI tool. I would definitely say, look into that, understand that, and it should be very clear to you as to how you can make your applications much more simplified with the right sort of best practices. So I would start from there. And of course, read about the European Act of Accessibility. That one should be simple to understand, but compare it to the U.S. Law as well. There's a VPAT in the U.S or the section 508. And understand how this one differentiates to the one in U.S. And then you will see what certain countries do specifically versus other countries. I think my camera is switching off on its own for some reason. I don't know if you can see it.

[00:43:38] Joe Colantonio But I think your internet is kind of wonky, so I think I cut off the video.

[00:43:44] Laveena Ramchandani Okay, perfect, but that's where I would start with Joe reading from these two links on the chat and then going from there onwards really.

[00:43:53] Joe Colantonio That's a great tip. Actually, you could feed it into something like Claude or ChatGPT, the law, and then do your company. Here's your software and say based on my software and based on this law, these guidelines, what should I focus in on us? What are some best practices?

[00:44:09] Laveena Ramchandani Absolutely. Absolutely.

[00:44:13] Joe Colantonio MCC wrote in the chat, you mentioned several times, Axe. How do you recommend using it? Do you recommend it through the plugin that exists for tools like Cypress, Playwright, et cetera, or maybe the CLI tool or even the paid version?

[00:44:27] Laveena Ramchandani Yeah, so the paid version, the difference with the paid version is that it analyzes different pages throughout. If you're keen on getting one test done for all your pages on your website, then go for the paid versions. But if you want to do it one by one, then use the free version. You can do a mix. You can a manual and automated one. So you can actually, first of all, start getting used to Axe manually with the plugins and just get a feel of how this works. Do you understand the vulnerabilities or not, if the developers are looking into these vulnerabilities or not. So start exploring with your manual Axe , which is on Chrome. But then what I would suggest is, stick it into Cypress or Playwright, and then actually use it from that perspective as well. I'm actually using it on Cypress, it works wonders. It really is helpful. And you can also try it on the CLI tool. However, I found CLI tools a bit It would just come up with vulnerabilities, but I would prefer it on Cypress because I would be able to understand it better through that tool. I think it's up to all of you, whether you prefer it on things like Cypress and Playwright on a framework, or do you prefer on a CLI tool. It's all dependent on your choices, but there are choices available, I would say.

[00:45:47] Joe Colantonio Just to add to that, people go to Test Guild courses. We actually have a course for about accessibility testing using the plugin with Cypress. If that's something you're interested in, check it out. So Laveena, you said shift left. So I'm curious to know, you know how developers do unit test before they check in code, can they run these scanners automatically, or is it like more of a manual process where they need to manually look at it and run some of these checks themselves?

[00:46:15] Laveena Ramchandani I think these checks, if they are actually writing unit tests, there's nothing stopping them from yet running these tests on Axe on the CLI quickly. It's nice and easy that way they are in the environment where they are building these unit tests before they make them live in production. It's a mindset shift here really, that we want developers also to understand the perspective. And if they are going to use these tools, it really is, how should I say, an amazing change really, because they're really understanding the point of view of doing this. And they're not just leaving it to the testers to do the manual testing here or automated checks, but they're actually going themselves, making an effort on this tool like Axe. And understanding so that they build the right unit test and provide the solution appropriately.

[00:47:08] Joe Colantonio You have it here when doing more like exploratory accessibility testing, maybe crowdsourcing it to people that actually have site impairment or something like that to try to work their site.

[00:47:20] Laveena Ramchandani Absolutely. Absolutely. And I think that's why I always keep saying that if there is the budget when you're within your company, invite people with disabilities and let them do a bit of exploratory testing. You never know what you're going to find. It's a world of, I don't know, it just, you end up with random things that you never even thought you would ever find because us testers, we are testing day in and day out. We may have missed something crucial or a developer might have missed something crucial. And it can happen, it's very natural, and we shouldn't be upset about this, but we should use the opportunities with real users who are actually going to use our tool and understand from their perspective of how they would feel. Are they feeling even happy with our tool? Are they feel upset with our tools? It just gives us a lot of feedback to work on this and provide the best quality possible.

[00:48:13] Joe Colantonio Right. If anyone else has any questions, I'll give it one more minute. If not, we'll just.

[00:48:17] Laveena Ramchandani I'm sorry about the birds.

[00:48:21] Joe Colantonio Chris says, he loves hearing the birds, so it's a nice change of pace. It's good thing. You get some lot of birds over there though in the UK.

[00:48:33] Laveena Ramchandani It's new, it's been coming recently and I actually appreciate it.

[00:48:41] Joe Colantonio Absolutely. All right, Laveena, any parting words of wisdom? Great session, by the way. You get a lot of claps, a lot love here. So before we go though, any parting words of wisdom you want to leave The Guild.

[00:48:51] Laveena Ramchandani I would say that, just like you treat other type of testing or any other type of add-ins, like to your application, to make it amazing, think about accessibility too, don't leave it to last minute, it just creates a lot of chaos and it just shows us that we are not very socially aware as individuals in the society. Let's be socially aware. Let's build more inclusive designs. Let's reach out to more people. And not just to a small fraction. I think that way we receive better reputation, better quality products, and you will see the results yourself.

[00:49:31] Joe Colantonio Great piece of advice. Thank you again, Laveena, for joining us today. Really appreciate it. Thank you for kicking off 2025 for us.

[00:49:38] Laveena Ramchandani Thank you so much. Thank you for having me.

[00:49:40] Joe Colantonio Thanks everyone. Thank you everyone for joining.

[00:49:42] Laveena Ramchandani Thank you. Bye-bye.

[00:49:44] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/A545. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:50:18] Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:51:01] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.