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

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way O the test Illumination Testing Podcast Guiding testers with our nation awesomeness from ancient realms to modern days, they lead the way. Oh, the testicle of nature Testing Podcast.

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, Lavina, 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 workflows. 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. Want to learn more? Definitely. Head on over to automationbuild.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 Lavena all about. Are you ready for the European Accessibility Act? Let's check it out. 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 Lavina, who's a testing expert. She's been part of the Guild for a while and she's talking about a topic I think is really, really important about accessibility. The European act of Accessibility is coming up and I think if you do anything with software and especially if you sell in Europe, especially the us, time kind of lags behind. So I'm sure us will do something similar. You need to be aware of what's happening. So, really excited to have Lavina join us. Just so you know, this will be recorded and be uploaded to the community later on as well. And if you have anything or any questions to ask anytime, just raise your hand and I'll be happy to ask your question. You can ask your question to Lavina when, when it's appropriate. So Lavina, welcome To the Guild. Good to have you.

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. So I've been in the testing world for over 10 years now. I think it's my 11th year this year and, 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. So 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. So 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 at the British Computer Society and especially List Group of software testing. I currently work at EasyJet as a quality engineering manager as well. And one of the quotes I really, really like 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't be. Why can't 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 sort of fallen over or had a trip, tripped over because the floor is uneven and I go with a buggy with my little one and even I, 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. So 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 other or 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 what way I'm going. So 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 Everything Everyday Things by Nielsen Norman. And this is how our systems work as well. We trip, 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 web applications, right? So 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 1 in 6 of us, which means improving accessibility increase as a company's reach immensely. As you can see, this picture by Microsoft and I really, really appreciate this picture is because 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 situational disability, right? Or right now I'm wearing contact lenses because I won't be able to see all of you on the screen. So I've got a permanent disability as well that my 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. So 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 Application 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 are going to make it 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 people who might be working with one arm with a temporary disability. Why are we always a bit partial to things? Why do we 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 will come to you which I will come to in a bit. So some accessibility issues so a 11Y 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 alt text from images so if someone is having a screen reader, you should always, 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 so what I mean by this is you start with header one and then you straightaway jump to header four. So what about header two and three? We should go in a very 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. So 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 being coded. So it's very, very confusing for someone say for instance who's blind, who's 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 and a 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. So next section, which is the importance of accessibility in design. So of course let's understand mainly the definition of accessibility. So 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. So why should we have these? Is 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. So we will naturally by using the product, become so comfortable with it that we might even not think from accessible ways. Right. So 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 diverse abilities and preferences. So 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 up product that is very good, accessibility wise and gets good audit reports and everything, generally.

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 accessible design include screen readers for compatible websites and even mobile plugins to assess a web and mobile as well. So plugins I need, 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 are 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. So these are sort of real world examples of accessible design and inclusive design, I would say. Okay, 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 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. So 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 these a tool placed in France. So of course we need to think about that. And the, 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 their compliant and by 2030, the deadline for removing inaccessible products. 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. So this initiative seeks to create an equitable environment where individuals with disabilities can participate fully in society. So 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 are so close to it, we have to start thinking of adding this as part of our ways of working. And it's a mindset shift. So 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.

Lavina.

Yes.

Who made your company aware of this law? I don't know if that's a dumb question. Is it the tester's job 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?

So I'm the person making people aware in my areas, the areas that I'm working in, IT&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. So it's a bit of a, how should 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 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. So I'd really appreciate if a law team was talking about this on our all 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 everything are within that building of the airport. Right. So it's something that should come from. I think it should be right to come from the law side of your company. But I've not heard of anything as such, not only here, in other companies, big consultancies never hear anything.

So I think it is disturbing. But it's an opportunity as well if you think about it. It's an opportunity for us to go and make noise, but noise in a positive way that will be taken very negatively as well. So 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. So a timeline for implementation. So the law is set to be implemented by June 2025, 28th of June, providing a clear timeline for organizations to adapt their services. So 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 you as well. And this timeline then encourages proactive steps to ensure compliance and enhances accessibility gradually avoiding last minute changes. So 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? So I would say a big chunk will be affected. And as I said, if you are even in the US working for a product that's in the eu, I'd start understanding how it's going to impact you and how you could actually help with testing. Really? 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? So what does shifting left mean? So shifting left does not mean that we're just going to move and shift left. Shifting left refers to the practice of addressing accessibility concerns earlier in the software development life cycle. So how I feel about this is imagine you're baking a. You know, 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. Right.

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? So think about it from that analogy. If you're going to put the blueberries inside, you're baking accessibility into your systems. If you're going to leave the blueberries on top, you are acting very last minute to accessibility, leading to a lot of changes, a lot of costs, a lot of defects and a lot of 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. So the importance of early testing is basically conducting accessibility testing early in the development process maximizes outreach and user 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. So 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. 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.

So yeah, while we do manual testing by users with disabilities, it reveals real world usability insights as well. So 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. Okay, so working towards change. Sorry, I should have Working towards the change. So 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 included in, but includes other things other than automation testing, CICD 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 to you, as a team, as an engineering team, to have clear, actionable objectives. So basically, you will 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 ACHIE disability compliance. Again, it's not really easy for us to say, it's not 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. So 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. This is not something we're going to do for B2. 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 team 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 to 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. So we need to understand how to engage stakeholders and how to have the teams on board with this as well.

Are these rules generic or someone asked a question in the chat or the application? Should they depend on the application and targeted 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, but.

So you're saying that the application is.

For cycling, for the example, say the applications for cycling. So I mean, in theory you're probably not going to have someone that's blind.

But of course, yeah. So I think that is all to do with market research and who your actual.

Might not want to cycle, but they might, might be intrigued in understanding what this application really does. So I think 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 disability should also be comfortable to using it. Right. 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. Right. So 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.

So, so do you know if they're going to be enforcing that, say you, you have a cycling application, it's not built for blind people with blind. Blind that blind. Are they. Would they be targeted or would they be fined? Do you know how that's going to work?

There are penalties involved, but I think if you clearly define the end users somewhere in a FAQ or somewhere on your applications, then that could be something clear for these people. They might think that, oh, 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 your 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 are 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. So 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.

Perfect.

Yeah, I think it. You need higher people to sign this off and then it should, should be like, okay, now we can focus on other things that we've thought about this. Perfect. So training and awareness programs. Of course, implementing training programs on accessibility best practices enables teams to understand the importance of inclusive design. So 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 a 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 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. So 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 Active Accessibility 2025, while also enabling continuous improvement in design processes. So I would always have some sort of audits going on. Whether you're doing this online with Equal Web or any other tool, or whether you're calling a company like Shore Trust. I think the one we use is called shoretrust. They come once every year and they provide a good report and then, 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, so why are you penalizing us? So you, if you have these regular audits, it, it helps every case, basically. So conclusion and call to action. So 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. And then 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. So 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. You know, 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. Because we don't want stakeholders to just be like, okay, it's important, let's bring it in. We don't 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. So, next step for organizations. So organizations must evaluate their current accessibility practices and align them with 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. So 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 to years and if they know which team is 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. So 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. So I think 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. So you should basically identify tasks that could be focused on accessibility testing at 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. So Figma basically allows you to create frameworks and basically any, any sort of mobile design or web design, but with annotations telling you that this would be a header 1, header 2, header 3, header 4. 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 in the next stage of dev and 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 as. 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, so 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 SureTrust is a good company to use. Not sure if they do something in the us 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. So 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 a 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. So it's. 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? Bottom up? I think if it comes from top down, it's really good. The whole company knows, but it comes. If it comes from bottom up, there's opportunities for us to, to really discuss about.

So 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. So 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.

No, not at all. So, 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.

So could you read the question again to me or if it's on the chat, I'll read it. Who do you think the responsibility of creating accessibility requirements? Product owner or design? I believe testers would do a test against the requirement. Not ad hoc. 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 new 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 are 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.

Mohnish, follow up. You can always just turn your audio on. That's fine. If you have any questions, let us know. So the first step, you think it's the easiest thing for people to get started. They heard this and they go back to that company. What do they do?

So 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 going to 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 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 US law as well. There's a VPAT in the US or the section 508 and understand how this one differentiates to the one in us. 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.

Any, but I think your Internet is kind of wonky. So I think it cut off the audio, the video.

Okay, 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?

That's a great tip, actually. You could feed it into something like Claude or chatgpt, the Law. And then, yeah, 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 or something? What are some best practices?

Absolutely. Absolutely. Yep.

So MCC wrote in the chat you mentioned several times, Axe, how do you recommend using it? Do you recommend using it through the plugin that exists for tools like Cypress playwright, etc. Or maybe the CLI tool? Or even the paid version?

Yeah, so the paid version. The difference with the paid version is that it analyzes different pages throughout. So if you're keen on getting one Test done for all your pages on your website, then go for the paid version. But if you want to do it one by one, then use the free version. You can do a mix, you can do 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 Tool 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. So 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 it on a CLI tool. It's all dependent on your choices. But there are choices available, I would say.

Just a headshot, people go to test guild courses. We actually have a course for about accessibility testing using the plugin with Cypress. So if that's something you're interested in, check it out.

All right. Yeah.

So Lavina, 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. These checks themselves.

I think these checks, if they are actually writing unit tests, there's nothing stopping them from 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. But I think.

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 are 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.

You have a HERO recommendations when doing more like Exploratory accessibility testing, maybe crowdsourcing it to people that actually have sight impairment or something like that to try to work their site and.

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, you end up with random things that you never even thought you would ever find. Because us, as 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 feeling upset with our tool? It just gives us a lot of feedback to, to work on this and provide the best quality possible.

Great. So if anyone else has any questions, I'll give it one more minute. If not, we'll just.

I'm sorry about the birds.

He loves hearing the birds. So it's, it's a nice change of pace. So it's a good thing.

You get some loud birds over there though in the uk.

It's new, it's been coming recently and I, I actually appreciate it.

Yes.

Absolutely. All right, Lavina, any potted words of wisdom? Great session by the way. You get a lot of claps, a lot of love here. So before we go though, any potting words of wisdom? We want to leave the guild.

I would say that just like you treat other type of testing or any other type of add ins like to your application, you know, 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. So 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, you will see the results yourself.

Great piece of advice. Thank you again, Lavina for joining us today. Really appreciate it and thank you for kicking off 2025 for us.

Thank you so much. Thank you for having me.

Thanks everyone. Thank you everyone for joining.

Thank you. Bye bye.

Thanks again for your automation awesomeness for links to everything of value we covered in this episode. Head on 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 and 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. 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@test guild.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 team tackle real world challenges. We're excited to collaborate. Visit test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

With lutes and lyres the bards began their song A tune of knowledge a a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.