PLATO Panel Talks: Levelling up Accessibility Testing

Here at PLATO Panel Talks, we’re passionate about accessibility testing and helping to create an accessible web for all. To mark both National AccessAbility Week in Canada and Global Accessibility Awareness Day, Mark Pope, a Partner and Web Accessibility Specialist at Pope Tech, and Abhishek Gupta, the lead of our accessibility practice at PQA sit down with host Mike Hrycyk to dive into how developers, designers, and testing teams can level up their accessibility testing and make accessibility a consistent and integral part of all things digital.

Mike Hrycyk:
Hello, everyone! Welcome to another episode of PQA Panel Talks. I’m your host, Mike Hrycyk. Today we’re going to talk about accessibility testing with our panel of testing experts. We’ll get to them in just a second. I did want to say that we have another podcast where we talked about accessibility last year, and you can go back and look at our history. And that one specifically talks about learning to be an accessibility tester and the path and the journey that people went on to becoming accessibility testers. Today in our talk, we’re going to dig a little deeper and talk a little bit about the tools and what it is and so at this point, I’m going to turn it over to our panel of experts to let them introduce themselves. And we’ll start with you, Mark. Please tell us about yourself.

Mark Pope:
Yeah. Hey Mike, thanks for having me on the podcast here. I’m Mark Pope and me and my brothers own Pope Tech, which is a web accessibility scanning and reporting platform. So, our mission for our platform is to empower organizations and their web accessibility creators to be able to help create accessible content for their websites so that people with disabilities have equal access to the content.

Mike Hrycyk:
Awesome. So how long have you been in the accessibility space?

Mark Pope:
So I’ve been in it personally for about three years. Pope Tech moved into it a couple of years before then, before accessibility. We were a web app and development company. So many of your listeners may come from that background of whether they’re developing apps for themselves or for clients. And we were doing it for clients and along the way, we were introduced to accessibility and learned about it. And as we did, we were using the WAVE tool, which we may or may not talk about more, but it’s a one-page at a time checker and we just decided: “Hey, how can we expedite this process of checking one page to going site-wide?” So that’s what we’re doing. But like I said, I’ve been doing this for about three years and Pope Tech for a couple of years, more than that.

Mike Hrycyk:

Awesome. Well, thanks. And we’re definitely going to hear more about that as we go through. Abhishek, why don’t you tell us about yourself?

Abhishek Gupta:

Hello Mike hello, Mark. Nice to see you here. And thanks for again inviting me to the podcast. So I’m Abhishek Gupta. I’m the Director of Service Delivery here at PQA testing, based out of Toronto, Ontario. So I’m responsible for leading all the projects here in terms of service delivery when it comes to Ontario and GTA, but when it comes to accessibility, I also lead the testing center of excellence here at PQA, all the testing initiatives, when it comes to accessibility, I’m the one with my team who is responsible for leading the initiatives. I’m also acting as a subject matter expert on certain client projects when it comes to accessibility.

Mike Hrycyk:

Awesome. Thanks, Abhishek. I’m still excited about it so I’d like to talk about just slightly Abhishek, can you tell us just a little bit about the certification program that you built for us?

Abhishek Gupta:

Oh absolutely. That is one topic close to my heart. So I think it all started with helping clients. Clients were reaching out to us and in terms of accessibility, this is not the new type of testing we are doing. We are in this space for more than 10 years now. But while we were helping the clients and new laws and rules were rolling in, and not only new laws and protocols, there were new tools, new testing guidelines. We started thinking that are we giving the best shot when it comes to accessibility? Then we set up a discussion here with the leadership in part about why not train all the testers into this particular space. It is a trainable kind of type of testing. And then I got approval from the leadership that yes, go ahead and build a full plan. The training plan for the new testers, for the existing testers, for our people on the bench. And then we prepared a full plan for six weeks of training, right from the basics of accessibility to the tools, the free scans, the automated scans, WCAG. And all the leaders from this particular space from our company came and trained all these set of participants. After the training was done there were certifications being handed over to the participants who scored more than 65 %. And there was a criteria that not only they had to give the assignment back to the trainers in terms of screen readers and scanning. They had to also go through the EDX web accessibility, fundamental training which is a free amazing training. I already did it myself. So I nominated that also to the team. So out of all these great criteria, we then handed over PQA certified web accessibility, fundamental trained, certified professionals. And I’m proud to say that in the last months we certified 22 PQA professionals who are ready to start on any client projects along with the existing SME team.

Mike Hrycyk

Awesome. Thanks, Abhishek. I think it’s a really good thing, right? It helps people understand that they’re good at what they’re doing and, that they have the fundamentals and it helps us go out and help people understand that we’re serious about it as well. So I think that’s really cool, but maybe that’s enough of blowing our own horn. So, let’s get back into the questions. So the first question I like to ask is what are we talking about when we say accessibility, there are lots of definitions out there, what it means, what are we talking about? What is accessibility testing? So let’s just start there and start with you, Mark. Tell me, how do you define accessibility?

Mark Pope:

Yeah, that’s a great question I think the simplest way to think about web accessibility is just having equal access for all people to digital content that’s on the internet. That’s probably the easiest, most simple definition I think of for that, but really the focus here is removing barriers for people with disabilities. And some easy examples to think about is if you are able to hear and you’re deaf, you know, watching a video is a very different experience for you than someone who has a full hearing. And so having something like captions included on the video that is accurate, then remove a barrier for you that allows you to engage more equally in that content. So providing that equal access and removing barriers for full access is, I believe, the goal of accessibility here.

Mike Hrycyk:

Awesome. And I’m going to ask Abhishek the same question, but given how many times I’ve heard him say, and I don’t think it’s going to vary much. Abhishek?

Abhishek Gupta:

Great definition Mark couldn’t think better. But yes in terms of barriers and absolutely removing barriers from the set of people who are into this category of disabilities. And we have to understand that we are not talking about a small percentage. We are talking about on the globe one person in every five people is facing some type of disability. So this percentage is very huge. And if we, as leaders, as testers, developers, or owners of the organizations are not thinking about them, it is a social injustice as well, I would say. So for me, web accessibility is more than designing applications to let these people use the way other people are using. It is more about making sure that we all are supporting this initiative across the globe.

Mike Hrycyk:

So what is the role of testing and accessibility then? Cause accessibility, it’s not synonymous with testing. So what is the role of testing? Abhishek?

Mike Hrycyk:

Yeah, sure. At PQA we live and love testing. So yes, when it comes to web accessibility. So this is, this is a kind of a confusing kind of word, which I see when people talk about web accessibility. Sometimes people think that it is only to test websites. Accessibility testing has to be applied to every product. Be it’s like a website or mobile application, native application, which you are installing on your phone or be it, these Microsoft documents. Every sort of this particular application has to be made in a way that it should be accessible by all the people, including disabilities. Now, when it comes to testing – testing should start from thinking about how the end-user should be using them. And when it comes to accessibility, there are protocols, there are requirements that are already designed by W3C and these requirements are known as WCAG principles. Now, these are the requirements that are kind of non-functional requirements, which every tester should understand. And then they should go back to the project requirements and see how they can test these requirements and finally find bugs and retest them in a normal, typical testing cycle. But one thing which the testers should know is this is non-functional testing. So they have to get trained on first understanding these requirements and secondary, there is a different set of tools over here. I believe most of us are aware of screen readers. These tools are the only way where blind people and people who are really hard of hearing and blind, both are able to use them through braille and other devices. So it is about knowledge of that tools and knowledge of the requirements. So that combination is what is needed for testing teams to be able to support this type of testing.

Mike Hrycyk:

Thanks, Abhishek. I do have to warn you, Mark, Abhishek is very passionate about this. So if I give him a little bit, he can talk for the rest of the talk about it. So

Mark Pope:

No worries. Like, it’s always fun listening to other people on this stuff.

Mike Hrycyk:

So did you have anything to add? What is accessibility testing versus accessibility?

Mark Pope:

Yeah, so, you know, I think Abhishek summarized it and provided a good overview of it, but you know, I would only add that, you know, it’s, it’s something that’s done intentionally. And I think Abhishek was emphasizing that too, that you’re going about and subjecting, whatever you created, that digital content to, certain tests to see if it’s going to work and function for the people with the disabilities. And there’s a variety of tools to help with that, as well as like Abhishek was saying like, you can even take screen readers and use your website or your documents or whatever you’ve created in the same way, a person with a disability might and try it out that way. So there’s a whole spectrum of testing here from tools to identifying issues, to actually using the tools that people with disabilities use to try it out.

Mike Hrycyk:

Awesome. So why don’t we talk about accessibility and when we talk about people who are differently-abled and using things and having access – it all seems really obvious to me that this is a necessity and it’s something we should be doing. Why do you think there are still organizations out there that are producing content or sites or whatnot that aren’t accessible Mark?

Mark Pope:

I think a lot of reasons why individuals aren’t producing just kind of accessibility content natively out of the box of what they’re producing is a lot of times its just awareness. It’s not on the radar. I mean, if you go back to how a lot of, I mean, the web is amazing, right? People started learning coding by popping open a text document and writing some basic HTML. A lot of people are self-trained, they learnt how to just generate content and create it on their own. Obviously, you know, you take courses and other things to help to build on this. But I think one of the things is most of those courses don’t cover accessibility. And most of the time when people are just testing out things on their own, they’re not looking at, you know, the requirements of the people who wrote the internet rules, like the W3C that does the WCAG requirements. And so they’re, they’re sort of self-taught, and they’re just not aware of it. I think that’s probably the biggest barrier. And after that, it’s motivation and prioritization. And so organizations who might be aware, do they have the buy-in from their central core leadership at their company? It’s, it’s obviously easier to get accessible content created if they have that buy-in from that leadership. And so the culture of organizations as they focus on how do we want to include people with disabilities if they have that culture or not plays into this immensely as well, too, I believe

Mike Hrycyk:

Just to follow up with that and then I’ll give it back to you Abhishek. Do you think that if you had a development force at a company and they were fully aware of what the standards are and how to comply with them? So testing aside, which is an added cost, would there be a giant additional cost if the developers were just developing in an accessible manner?

Mark Pope:

You know, the cost might come on levelling up in accessibility to be able to do that, but as people become proficient in that the cost for creating accessible content really isn’t that much more. A lot of accessibility is especially on websites. That’s what I’m more familiar with. Right? A lot of accessibility barriers would be removed if individuals coding that would just follow the basic semantic HTML. And so, you know, in the long run, it’s probably cheaper and it’s probably not as big of a barrier as people think, but there is a curve of getting levelled up and understanding what it takes and how to do that. But we believe anybody can get started in web accessibility. Now it does take time to become an expert, but anyone can get started and start making improvements in accessibility. And as you do that, you level up and then you’re able to implement more improvements, having something like the WAVE browser extension or the AXE browser extension installed in your browser. And just before you deploy a website, checking it to make sure that, you know, any of the low-hanging easy identified errors are taken care of before it ever launches it’s a good first step in levelling up. And I don’t believe that takes that much more time.

Mike Hrycyk:

And has you said maybe one of the steps as if we added it into our education? So when you started having computer science grads coming out, it’s just the way they code would also help –

Mark Pope:

Right. For sure.

Mike Hrycyk:

Abhishek, anything that add on, on this. Why is accessibility not a priority?

Abhishek Gupta:

I think awareness, as Mark said, is one of the key reason behind why people are not thinking how important it is. But I was really questioning myself that still, even if the awareness is coming through channels, digital medias and lawsuits, and these ADA, and AODA all these lawsuits and protocols are so much been shared across still why organizations are not taking that step? I think that it’s, it’s about leaders who are still not aware about what is this whole, web accessibility about? Everyone is aware that, okay, the HTML was developed through an organization named W3C, but what we are not thinking is that the same organization W3C has also came up with the WCAG principles and guidelines, which tells that yes, HTML is how people are accessing this internet through these browsers, but you cannot just use it, not thinking about people with disabilities. So you just follow these guidelines also and make it more accessible. Now people are not thinking the other side of the coin, the implications of not following them. So there are laws and there are lawsuits. I was reading an article the other day due to COVID and the recent surge in using digital media there are lawsuits increasing by 50% compared to the last quarter and still organizations are not using it? I think more education in terms of when new employees are joining, there should be in the KT plan about maybe accessibility training or training to the leaders as well, a training to the development team as well. But it is not that costly. And there is not such a big learning curve. And I’m not saying it only by reading it, we have done it here. Most of the testers now at PQA are either certified or fully aware about what this is. So we have done it and we feel it is more about training and awareness. If all the organization can start this at the level where it can be supported by everyone, just in six months, it’s going to be a very big difference the way the organizations are going to treat accessibility altogether.

Mike Hrycyk:

Well, it’s kind of a point. I mean, one of the services that, that all three of us are offering is coming in and doing accessibility testing. Well, part of every accessibility testing engagement, at least for us. And I’m assuming for Mark, you can confirm in a second is that we teach the developers what they did wrong and how to do it better next time. And so if you don’t do your training upfront well, but you do have to have some sort of compliance statement around accessibility and your testers will come in and show you where you did it wrong and then teach you what you did wrong so that you can do a better next time. Realistically, if you train your developers first, you’re going to save some money on the testing end. I assume that’s something you do when you go in Mark?

Mark Pope:

Yeah, our product is a platform. And so we focus on trying to help them use that platform and level up beyond that, to start moving into a lot of the other testing on their own. And so that’s mainly our focus. Is it okay if I loop back around for a second?

Mike Hrycyk:

For sure!

Mark Pope:

Yeah. Sorry about that. But we were talking a second ago about you know, the awareness and the culture and the laws and different things. And what popped into my mind was an experience that I had was I attended an accessibility conference and a lot of these conferences, you know, obviously they are bringing in people like me to the conference or selling products and things like that. And then there’s also a lot of accessibility advocates and then also assistive technology users. People, different disabilities are there as well, too. And at that conference, I saw that there was an individual who was blind and he was trying to get to another end of the building at the other end of the conference center. And he was using his cane and he was navigating the way that people told him he needed to go, but he kept running into a wall because instead of the hall just going straight, it actually did a Y and did a fork and it went straight still into like a coffee shop. And you had to actually take a little bit of a left and then immediately take a right to be able to keep going in the direction that he wanted to go. And he tried repetitively to do that on his own, but was unable to, until, you know, someone explained that to them and help guide them that way. But just watching the mounting frustration that he was experiencing, just trying to walk across the conference center was very enlightening to me about the importance of this type of work. And so with awareness, a lot of times, a lot of people who create digital content, they’re like, yeah, yeah, I know stuff needs to work for people with disabilities. And they like get that. And they’re like, I care about people disabilities. They get that, but they haven’t really stopped to look at their product through the lens of someone with a disability. And many times when I’m working with individuals and companies, and we start taking a look at their website, you know, all the errors that are detected in an automated way, they’re surprised at how many are there. And what would be even more insightful for someone is how does a person who is blind navigate your enrollment forms, or are they able to, you know, just actually watching the frustration of someone trying to access what they developed or what their developers developed or what their company has created. I think that’s the sort of awareness that really drives home understanding when they’re like, you know what? I am actually part of this problem, this person can’t access their bank account. This person can’t purchase my product that I believe is amazing for everyone because I haven’t considered accessibility.

Mike Hrycyk:

And I think it’s important to state because you might have people check out just from the idea, they might react to your story, which I think is a great one and say but I can’t just assign everything with straight lines. And I think the point is that, yes, you should try and design with straight lines when you can, when this is part of your viewpoint, but that’s not the only thing that you could do. You can also ensure that you have a framework of the capability of giving directions in a way That it helps you navigate that Y without running into the coffee shop, right. It doesn’t have to be, you have to be super simple it’s that you have to have a way for it to work. And there are tools to help it work.

Mark Pope:

One thing I also saw at those conferences where the participants who engaged in some of the services where they had volunteers actually being their eyes. And so they’d have like an ear Bluetooth headphone in there, and they’d be holding their phone in front of them as they’re walking along and someone is guiding them through directions and, you know, thinking about things like that, you know, when there are barriers, how do we navigate that? You’re absolutely right. It’s not always just develop it with the straight line. You know, don’t put anything complicated on your website at all. Right? I don’t think that’s the right answer. It’s like, how do we help them get to the end goal? Like you’re describing. Absolutely agree.

Mike Hrycyk:

Alright. So we’re going to jump into tools in just a second, but before we get to tools, I always like to have the discussion of static versus dynamic and what’s important accessibility. And so I’m going to throw that at you Abhishek, to help us understand what the differences are?

Abhishek Gupta:

Great question, Mike, this static and dynamic testing always comes no matter which type of testing a tester or an IT team is going to handle. But when it comes to accessibility, this becomes a way more point of discussion. Where static scans on accessibility are so easy to do and there are so many open source tools, which are either your browser add-ons or some installation for your desktops and mobile, but in just few seconds, it’s just a click of your button. You would get the entire scan of your webpage. And not only the scan is going to tell you how severe it is in terms of accessibility, bugs. Some tools are going to even categorize them. Okay. You know, there are eight critical bugs on your page and you are violating these requirements of WCAG principles on this particular guideline. And you get to go through, let’s say 10 pages in not more than five minutes, and you get the current state of your application. And you can really generate that report, show it to your leaders, show it to developers, designer, and they can start thinking during the design phase itself. So that is what static scan is no company or IT team should not apply it. But the bigger question is if the IT team even aware that there exists these static scan tools in the market? So that goes back to awareness and training part. Now coming on to the dynamic part. Now there is a false assumption as well within these teams that, you know what I’m already doing, accessibility testing, and maybe the lead or the manager might just look at these static scans report and that might give some good green numbers telling that no errors and things like that. The percentage of that particular test coverage is just like 20-30% not more than that. Because if you want to really complete the test coverage on accessibility requirement, you have to apply the dynamic testing. Meaning you have to apply a tester to really go through your screen readers, to go through your synthetic voice of your entire text. You have to really play your videos and audios on your application to make sure there are captions, there are transcripts and much more. So if we don’t think about dynamic testing, then your accessibility testing is just done 20-30%. The problem is that because of this lack of awareness, a lack of training, some organizations are making the false assumption and taking a very big risk. Thinking that a one hour of accessibility testing on a project plan is what just they want to do. And they are not applying the dynamic testing, which is a big risk and can really be a major issue for the entire product or the company.

Mike Hrycyk:

Awesome. I think I agree with that. Mark?

Mark Pope:

Yeah, totally. I spend a lot of my time on phone calls with people explaining accessibility testing and you know, one of the false questions, and we wrote recently wrote a blog about this the two big myths in accessibility. And one of them dealt with just being able to automate this fully, you know, even with script, not even do anything,which we talk about there, but part of it for people that are like, “Hey, if I get like zero errors, am I accessible?” And I have to spend a lot of time explaining to people. It’s like an iceberg and there’s different layers here. The stuff above the water is about, depending on what statistics you hear about 25=40% of accessibility errors and how it’s counted can be fully automated. But the rest of it is like the iceberg what’s underneath. And that does require, you know, automated tools like our platform and the WAVE tool will identify things as alerts that are like, “Hey, we believe this is an error, but it requires human inspection.” And so it’s also going to point out things to inspect. And then also there’s categories for manual inspection as well too, that are going to be pointed out. And those are kind of the three levels, right? One that’s like the fully above water, fully automated testing that can be done entirely just with tools, identifying that pointing out what you need to go fix. And then there’s items that are sort of there at the water line that are partially detected. But you do have to confirm, yes, this is an issue or not an issue. And then there’s items that are fully underwater that as Abhishek was talking about, that’s that dynamic testing, you’re going to have to pop up on the screen readers and look at the captioning and other things to be able to ensure that that is accessible.

Mike Hrycyk:

So I haven’t heard it described this way, but it seems to me that there’s two classes of tools. And the one class of tools is the tool actually going to be used by a person who’s disabled, right? So it’s a screen reader that’s the active screen reader that they use. And what we’re going to do is tested actually kind of traditionally in the way we test software all the time, it’s run through the functions of make sure they work. The other class of tools is, and maybe I’m wrong. Maybe there’s eight classes of tools, but in my mind the other class of tools are the ones that are going to programmatically scan. So one of the really big simplistic ways of looking at HTML is you have to put in the appropriate tags so that the tools that are assistive will be able to do it. Is that a good way of looking at it as a two different classes? Or it’s already known and they’ve actually got names? Maybe Mark we’ll start with you.

Mark Pope:

Yeah. I think that’s a fair way to look at it. I sort of look at the two in conjunction with each other, right? And so the automated testing, it’s doing a couple of things as you’re going through and you’re testing the website, you’re identifying those low hanging fruits. You’re fixing those errors, but there’s a couple of things that are happening there when you’re fixing up errors. Obviously you’re removing errors in clutter from that website and issues. That’s going to make some later of that manual testing that dynamic testing easier because you removed clutter. And the other thing that happens as you’re using those tools, you have to get into the documentation of the tools and it describes, Hey, here, a person with a screen reader is going to experience these sorts of issues because of this air. And because you’re reading that and thinking about that slowly what’s happening is you’re being educated that people with different assistive technologies are approaching a website very differently than you might be approaching it without that assistive technology. And you’re getting an education on how they might approach the website and what to do that actually helps prepare people for using these later tools and testing. A lot of the customers who come to me are very new with accessibility and they’re like, okay, if I got to do screen reader testing anyway, shouldn’t I just start with that? And I’m like, you absolutely could, but I’d recommend the automated testing because what I was just describing, like you’re fixing low hanging fruits, you’re removing errors. If you go through the process of fixing the fully automated errors, then move on to the automated, detected human confirmation errors, and then move on to using a tool like the WAVE tool to guide you through some basic manual testing first. By the time, you do that sort of process – when you get to keyboard testing and screen reader testing through the easiest screen grader testing and keyboard testing, you could do because first off you removed a lot of clutter out of the way first. I mean, even if I’m going to a third party expert to audit my site, I’d want to remove all that low-hanging fruit first. Cause I don’t want them spending their time identifying things that I could have detected at a much cheaper rate right.? And so you’re removing clutter, but then you’re also leveling up in accessibility. So that then you are able to get to that point. And that’s really what we’re passionate about. I mean, wewent through this process and we’re like, “Hey, we can help you guys move through this process of leveling and accessibility.” So that by the time you’re done, you’re like, “Hey, I know that people at these different assisted assistive technologies are able to go through this process.” And again, it’s a leveling up. But if it’s done in a very systematic way, using these, these, these automated tools first and then segwaying into the manual testing, we believe that organizations can level up and it’s possible. And it also provides a strategy for going about it.

Mike Hrycyk:

That’s right. Like I’m a huge proponent of, of having the automated tools that you can tie to your build process so that you can fail fast and fail often. And you know, what, if I have to fix a tag the tenth time I have to fix it, I probably won’t do an 11th time. And hopefully it’s only the second time. But it’s that failing fast that, that helps you learn and helps you overcome. Abhishek anything to added to this?

Abhishek Gupta:

No, I think absolutely couldn’t agree more that our approach based on learnings we are doing, based on the past projects we have done, we would always recommend to start with some automated testing audits, free scans. Take a look at the stock of the situation and then apply the dynamic testing based on the areas where automated tools have given you a guess that this is the area, explore more, which is outside the capability of automation tool. And then do the dynamic testing only on that part, submit the results back to designers and developers, get the new bill on those fixes and then do the full dynamic testing. But what we also want to suggest is then apply the automation testing in the CI/CD pipeline or your regression automation. So that when a full final testing has been done on a product ongoing enhancement should be applied to a regression approach of automated testing. So I think that would give a high level of confidence to the product teams to move forward with their product enhancements.

Mike Hrycyk:

Awesome. Alright. So I want to make sure we have a little bit of time to learn more about the Pope Tech platform, but so why don’t we start this way? Abhishek tell us about a few of your favorite tools and what they do with, and then what we’ll do is have Mark come back and tell us how their tool relates to what you’ve just talked about. So Abhishek kickoff.

Abhishek Gupta:

Sure. So we’ll start with the static testing and the auditing tools. So, AXE tool is from Deque System. So this is an organization who are making amazing tools in the market exclusively for accessibility. So they have their flagship AXE and there are very amazing tools and free tools in the market. So AXE, my favorite. Everyone is aware about WAVE, but that is my go-to tool in comparison to AXE. I like both. The third one, which we have started learning and which was already in the market is these browser APIs, which are coming build in your dev tools. So lighthouse in Google and Edge are the other tools, which I would always suggest people to apply. So this is on the static side. On the dynamic side, we have screen readers. So NBDA for Windows, Voiceover for the iOS are the tool screen leaders, which I would highly recommend. And other than that, it is, it is more of your keyboard accessibility, and manual testing, which a person should apply.

Mike Hrycyk:

Awesome. Thank you. I have a check. So would it be fair to say that it’s unfair to pigeonhole, but for the most part, the static tools are looking at, say it’s web based, are looking at the tags and the structure of the HTML code that you’ve put together and making sure that it will work with other tools. I think it does a little bit more than that, but that’s the core capability, right?

Abhishek Gupta:

The core capabilities, exactly. Finding something missing, absolutely missing link, missing attributes. So that is something and also color contrast tools. So, sorry, I missed that one. So there are color contrast tools, which are either inbuilt these WAVE and AXE and there are color analyzer tools built in separately as well. Yeah. So these, these are the things or testing criteria is where we would never recommend manual testing to start with. So machine is the best way to uncover those defects.

Mike Hrycyk:

Okay. So Mark, I’m going to hand it over to you. How does your tool relate to that?

Mark Pope:

So the Pope tech platform is what we’ve done is we’ve partnered with WebAIM, which does that WAVE tool Abhishek was talking about. The WAVE tool by itself goes one page at a time testing, their free one anyway, goes one page at a time checking pages for accessibility. And, and it has six testing categories that deal with accessibility errors with contrast errors is the second category. Those are the fully automated testing categories. And then it goes into alerts which are automatically detected, but human confirmation category that does that. And then the other three categories are designed for manual testing, guiding you to identify things for manual inspection or identifying things later that you would then maybe highlight with, for additional testing with keyboard or screen reader testing. And so a lot of individuals love that WAVE tool it’s designed by WebAIM. And like I said but WebAIM is a nonprofit group out of Utah State Eniversity that is solely dedicated to web accessibility. They do web accessibility trainings, education evaluations audits, and they develop that WAVE tool and use it internally on their own audits as part of that auditing process and being the great nonprofit group, they’ve just released it for free. And that’s where we came along is we were starting to work on accessibility for our clients’ websites. And we started going this one page at a time is great, but can we expedite this process in a platform and generate site-wide scanning and reporting. And now we’ve grown to the point where we can provide that site-wide scanning and reporting not just for, you know, a website and all of its pages, but for the most complicated organizations out there that have portfolios of websites, you know, like universities or government entities with potentially thousands of websites with millions of pages to help expedite this process of scanning and reporting and assigning results. Creating a grouping structure where individuals view the results for the websites they’re over and so on. So the way to think about us is yes, we’re taking that WAVE tool, which we believe is a great tool across the board for accessibility experts of all levels. It has a visual interface as well as the code view and those contrast checking tools, but it’s a tool that’s one page at a time we’ve taken that and made it site-wide

Mike Hrycyk:

Awesome. That sounds really good at like, it really takes a focus tool that makes an enterprise-wide, which is what a lot of bigger companies who avoid strenuously the idea of accessibility because they feel that there’s a cost, but it’s really important. So I think that’s good. I think that I’m going to check that tool out. Thanks Mark.

Mark Pope:

Yeah. Come check it out. Just let me know, or any of your listeners, right.

Mike Hrycyk:

Awesome. I assume it’s pope.tech?

Mark Pope:

Go to pope.tech and just submit a request to do a call. You know, Pope Tech is owned by me and my brother. So it’d be one of us jumping on a call with you. And one of the things we often do for organizations at the get-go is, yeah, we talk about our platform, but we can also go through and we’ve got blog articles on a number of topics, including this. But, you know, creating an accessibility strategy. So if you’re just new to accessibility and don’t know where to get started, we can help you figure out what would be a great strategy to start moving forward using these automated tools first and then leveling up so that you can keep moving on after that.

Mike Hrycyk:

Awesome. That’s great. So we’ll include a link to Pope Tech in the episode information, so listeners can go there and that’s great. So we’ve, we’ve kind of run out of time. I know that Abhishek could talk about accessibility for days and I really find it interesting too, and I can talk about it, but in the interest of our listeners, we’re probably gonna wrap it up here. So maybe just as a conclusion, let us know what are the next big steps that any organization that hasn’t thought much about accessibility, what are the first steps that they should take to start down their journey? And let’s start with you, Mark.

Mark Pope:

Yeah, I would say the simplest thing to do cause it’s cheap. It’s easy to do is just go to wave.webaim.org and download that free WAVE browser extension. Or Abhishek mentioned the AXE one. That’s a great one, too. A lot of developers love that one as well, too. They’re both great tools. But download one of those free tools and just start checking some of your websites as an easy thing to do is just bake it into the deployment process. You know, you often look at a website and a testing environment before you deploy it live. And so just hit that scan and check that page and fix some errors before you ever deploy it live and just start there where you’re at and slowly level up. Like I said, there’s some great resources. We have a great organizational web accessibility strategy article on our blog at blog.pope.tech that can give you some other ideas of getting started. But just choose something one or two little things to do and start doing them, that WAVE tool or the AXE tool just doing that. And some basic checks is a great way to just get started.

Mike Hrycyk:

Thank you. Abhishek?

Abhishek Gupta:

A hundred percent agree that every IT person should go and download these tools or make extensions to their browsers and just look at your own product, what you are developing or testing to see where you are. And along with this, the leaders of the organization should plan for maybe an introductory sessions from the trainers to really see what it is all about and why we should be thinking about accessibility. What I get surprised by is that whenever I see enterprise level project plans, I can see functional testing, is there performance testing is there, security testing timelines are there, but I’m still surprised there is no timeline when it comes to accessibility testing and sign off. I think again, going back to awareness once the training has been done, I believe that accessibility should find a spot on every project plan for any product rollout or announcement.

Mike Hrycyk:

And I think so that training could be any number of durations long. I would like to say that that we’ve developed a one hour session that has a bit of time for questions that really gives you a foundation and starts you with the questions that you need to ask. So the very initial investments not have to be big at all. You can spend an hour, get your stakeholders and your developers and your testers in a room, and they can have a baseline understanding of just at least what accessibility is so they can start building a plan. Alright. So I would like to thank you the panel for coming out and joining us. This is a really great discussion about accessibility and some deeper dives. I thought when we started, maybe we were going to spend a whole bunch of time on WCAG, but you know what I think the focus that we had is really good. If our listeners are interested. You can kick off the conversation and continue it on our social media or our website, or if you’d like us to delve into different parts of accessibility, let us know. And we’ll see. I mean, we’ve already got two talks. We’re always willing to have a third or fourth. So remember, you can find us at PQA testing on Twitter, LinkedIn, and Facebook, or on our website. You can find links to all our social media and the website and the episode descriptions as well as information on the Pope Tech platform. If anyone out there wants to join in one of our podcasts chats or has a they’d like us to address, please just reach out. We’re really open. And we like talking about things. If you are enjoying our conversations about everything, software testing, we’d love it. If you could rate and review PQA Panel talks on whatever platform you’re listening to us on. Thank you again for listening and we’ll talk to you again next month.