Accessibility For Everything

In many cases Accessibility and Accessibility Testing are done as late in the game processes and done to make sure that a level of compliance is met for those who most need that accommodation. This misses out on the fact that many more people could benefit from having Accessibility features integrated into their products and that the benefits of accessibility go well beyond those who need last-mile technology the most.

Subhash Chhetri and Karan Ahuja join Matthew Heusser and Michael Larsen to discuss their philosophy of Accessibility For Everything, and how making every element and process accessible makes products and services better for everyone that uses them.

References

• Disability Impacts All of Us
• ARIA
• WCAG
• Education and Outreach Working Group
• Deque University: Digital Accessibility Courses
• Accessibility and Inclusive Design With Michael Larsen
• Future Proof Your Software: Design Inclusively

Transcript

Michael Larsen (INTRO):

Hello and welcome to The Testing Show.

Episode 116.

Accessibility For Everything

This episode was recorded on May 18th, 2022.

We often look at Accessibility and Accessibility Testing as something done late in the development process and to an often minimal level of compliance. To discuss the idea of Accessibility For Everything, Subhash Chhetri and Karan Ahuja join Matthew Heusser and Michael Larsen and talk about how making every element and process accessible makes products and services better for everyone that uses them.

And with that, on with the show.

Matthew Heusser (00:00):
Welcome back everyone to the show. This week, we got a special treat for you. We have the accessibility practice developers from QA Infotech and QA InfoTech was acquired by Qualitest in 2021. Subhash Chetri who is here with us was actually one of the first members of that practice, which grew to a group large enough that Qualitest wanted to acquire it. He’s got 10 years of experience working accessibility to explain for us, let’s be honest when it comes to testing, it’s very easy to get siloed into manual or exploratory or functional testing, and to forget about the other things. So let’s talk about how to bring that in and why it’s important. So welcome to the show Subhash.

Subhash Chhetri (00:50):
Thanks.

Matthew Heusser (00:51):
We also have Karan Ahuja, we’re gonna get to in a second. Before we do that, Subhas, can you tell us a little bit about really quick, a career perspective on what you’ve been doing at QA InfoTech and how things are for you now at Qualitest?

Subhash Chhetri (01:08):
Currently QA InfoTech. I am in the position of architect. So I’m having 10 years of experience. And as you mentioned, I was the first one of two employees who had joined in the accessibility team, and it was the year 2011. So since then our team has grown tremendously because initially we were only two employees. Now we are about 50 guys in our team. So my role here is to look after the whole team. I am engaged in testing, then analyzing the requirements also, and providing training to new joinees, and new employees like documentation purpose. So these are my current role in the organizations.

Matthew Heusser (01:54):
Okay. Thank you. This is a pretty international episode. We’ve got Michael on the west coast, Matt on the east coast, Subhash and Karan are calling in from India. What time is it for you?

Subhash Chhetri (02:09):
Oh yeah, I’m currently based in Noita, India. So it’s the suburb of Delhi.

Matthew Heusser (02:14):
And what time is it for you right now?

Subhash Chhetri (02:16):
Right now it’s 6:20 PM.

Matthew Heusser (02:20):
6:20 PM. It’s 8:50 AM. So you got a half hour mark in there for me (AM). And it’s 5:50 AM for Michael. The technology has made it possible for all of us to work and collaborate all over the world, anytime, but there’s still a large group of people that are left out because maybe they’ve got a visual impairment or some other reason they can’t interact with devices. All of it is because we just didn’t think about it and didn’t design it because all the technology is there for us to do it right. That’s what we’re here to talk about today. Kiran, welcome to the show.

Karan Ahuja (02:56):
Yes. Thank you.

Matthew Heusser (02:57):
And I know you’ve been with QA InfoTech for a couple of years. Can you tell us a little bit about how you came to the company and what you’ve been doing?

Karan Ahuja (03:04):
I have joined the company in 2019. Subhash also trained me for the team. And I’m working as a testing engineer, accessory testing engineer, and my work is to do software testing, accessory testing on various plan projects, like websites, documents, and we have to create bug reports for the client. And I’m improving my skills in the field of accessibility as time goes on.

Matthew Heusser (03:32):
Thank you. I was surprised when I got the meeting invite to this, to start talking about this, for two things. First of all, QA InfoTech really has a reputation in this space for accessibility, but also the headlines kind of shock. Maybe not shocking, but surprising… Accessibility for Everything for all of your software. If you define software, you should be thinking about accessibility. And maybe it’s a criticism of our industry, criticism of my background. It’s usually an afterthought. It’s usually, “We gotta’ do this thing because some government person said we had to.” The idea that, “No, no, no, no, no. Everybody matters. Everybody should be included.” I think that’s good. Can you tell us a little bit more about that, Subhash?

Subhash Chhetri (04:18):
So basically whenever any product or any software is designed or built, it is built upon the perception that the person using, he would be perfect to use it. So that’s why we see most of the products we see today. These are inaccessible and we have also experienced that, unless any law is there, many industries, they do not think about making them accessible to all users, but if we implement accessibility in each product, and then it expands the customer because different customers have different needs, depending upon their physical and mental abilities. We can see that. Now the perception is changing a little bit. Now we can see that some industries, there’s no legal compliance. Then also they come to us and they want us to test their applications. But numbers are very low, still many industries do the testing just because the government has implemented some law.

Matthew Heusser (05:29):
Yeah. There’s laws, but we wanna be… get out in front of it. There used to be an idea in software that if the customers see it, if you’re YouTube, if you’re Google, if you’re Microsoft, if a million people are gonna see it, in the past, some people have had the attitude, “Uh, yeah, yeah, yeah, yeah. We gotta’ do it for our big stuff. That’s gonna be used by millions of people. But if it’s gonna be used internally, if it’s gonna be used by five people, accessibility, that’s just a waste of time.” When I think about the people that could be unable to use software because of an attitude like that, breaks my heart. If it’s one person it’s too many. Could you talk about the business value of accessibility?

Subhash Chhetri (06:20):
If we implement accessibility to any product, it really adds the market value because the different users, different customers have different needs depending upon their mental and physical ability. So whenever we implement accessibility, it really helps. I remember in 2013, we were testing one application from, uh, Pearson Project. Once we done with the project, then the project had came to us from the client side. He told us that, because of this testing, they engage with another university. Like that, it adds value. Whenever you implement accessibility, it expands the customer. There are many numbers of people who have some type of limitations. I can say it is a disability, but some types of difficulties in accessing the product. Many people may have low vision impairment, even though it would not be visible to others. So if we implement accessibility in product, that really helps those people also.

Michael Larsen (07:33):
So I can direct this to either Subhash or Karan, and here’s something that I’ve personally dealt with when it comes to testing accessibility projects. One of the areas that I find interesting is the fact that in many cases, if you are an admin user, or if you are dealing with the admin features of a product, those oftentimes are excluded from accessibility requirements. We were working on a project and I said, “Hey, there’s no accessibility capabilities. Or there’s some issues here that are not being addressed in the admin console.” The answer was, “Yeah, the admin console does not need to be accessible. It’s defined as such.” That was considered okay. And there was a part of me that thought, “So, wait, are we saying that if you have visual impairment or audio impairment or something that requires a last mile need for accessibility, you’re effectively locked out of administering the application?” And for me personally, I thought that was bit insulting. Also. I oftentimes deal with the fact and I discuss when I do talks about accessibility, situational disabilities, in the sense that any of us can be temporarily put into a situation where we have an impairment that affects us in a way to where accessible technology would be helpful. And I would argue that in a case of a situational disability, that might even affect an admin, wouldn’t you think?

Karan Ahuja (09:15):
Yes, you are. Right? Because they already thought that a non-disability person can become an admin.

Matthew Heusser (09:22):
Yeah. It’s when you think about it, we’re actually locking things out and let’s get real specific. I was looking this up this morning, 3.5% of the population have vision impairment and about 7% are some kind of colorblind. So if you have a designer who is designing palates, that is not considering whether your font will work with your background. You could have one out of 15 people who just can’t use your software. Imagine what a 7% boost in sales right now would mean to the company’s bottom line. Imagine what a 7% increase in productivity right now would mean to your company. I think those are things that we need to start talking about in terms of real numbers. I think there’s a clear business case for inclusion. And I suspect that by looking at things like, “Wow, these drop-down menus are really weird. You have to be able to use a mouse to get to them. You can’t get to them from a keyboard. That makes things really awkward. Let’s design it so that you can.” I suspect you’re increasing usability, which is going to increase your broad overall clickthrough rate.

Karan Ahuja (10:35):
Yes, you are right. Disability percentage is higher than they say.

Matthew Heusser (10:40):
Right? There’s other kinds of

Karan Ahuja (10:41):
Those things show companies are ignoring their user base.

Matthew Heusser (10:44):
There are other ways that a user could be limited by the user interface or ability that are outside of the two things that I mentioned. Now we’re talking double digits and speaking of which, for both Karan and for Subhash this is personal, in that every time they do manual testing, they’re also doing accessibility testing because of some personal limitations, which they’ve turned into strengths with this particular job. I don’t feel like it’s my place to talk about it so much. Do either of you want to talk about your challenges?

Karan Ahuja (11:15):
Yeah. It is challenging to work as a, non-sighted engineer in a broad company, but our company is very helpful for us in this case. And other sighted engineers will help us if we find any tests, which we are unable to complete.

Matthew Heusser (11:34):
So you got a visual impairment. Can you explain to us how we’d think about that or what that means or how that impacts your life?

Karan Ahuja (11:41):
You can identify it. Like, for example, I can say that if you have a total vision, I can see just 10% of that vision. So you can relate with that and use websites and other things with that vision percentage.

Matthew Heusser (11:58):
Yeah and Michael was saying before we started that he does a lot of accessibility. He’s kind of a name and accessibility, but if he turns the lights off and goes into a closet, he can experience what it’s like to have limited vision. Or if he turns the brightness down on his monitor, when he is done, he can just turn it right back up. And people with impaired vision don’t have that. And to be sensitive to that and to try to include them, I just think it makes you a better company, makes you a better people.

Karan Ahuja (12:26):
We can train our mind, but you cannot replace the actual experience of that disability.

Matthew Heusser (12:35):
Subhash, do you wanna tell us a little bit more about your experiences?

Subhash Chhetri (12:39):
So, in my experiences, since I’m, also blind from the very beginning, since I was four and five years old, I studied the braille because at that time, when I completed study braille was very imminent. So I studied using the braille. If I compare before 10 years, let’s say, at that time, there were so many challenges because technology was not developed too much. So suppose in India, whenever we travel to anywhere, we had a problem that whatever we are going, we had to ask driver or the co-passenger, “What exact location is there?” Because of now the technically being developed, we can use Google map to track our location. Because of this technology, it is changing. Still, there are a lot of challenges in our daily life, but yes, with the use of effective technologies, we can minimize this, but it also depends on the business owners to develop such products, which can be usable by all types of people, despite the different disabilities.

Michael Larsen (13:54):
One of the interesting things that I talk about is there are a number of ways that we look at accessibility from a broad range of issues. Most of the internet, and most of the features of our world are made for normative users because, frankly, that’s the broadest population. It just is. But at the same time, I always like to tell people that we run the risk of locking ourselves out of environments, because at some point in time, if we are lucky enough to live long enough, every one of us is going to deal with some kind of a disability, whether that be visual, auditory, mobile, cognitive, there’s something that’s going to affect us. And again, as I indicated earlier, it doesn’t necessarily have to be a chronic condition. It can be a secondary or situational disability that we deal with. Maybe briefly. My example is I am over the age of 45 and because I’m over 45, I am now in the farsighted category.

Michael Larsen (15:07):
I need reading glasses to be able to interact with my computer system in front of me, even with large font. If I take my glasses off, much of the screen in front of me is illegible and difficult for me to use. Not to the point to where I necessarily need to use assistive technology, but I could see that at some point that will probably be in my future. I guess what I’m trying to say is, what is something that we can help encourage testers and organizations to look towards accessibility, not so much as, “Oh, this is an accommodation we need to make.” It’s literally the way that many people will interact with your product at some point in time.

Subhash Chhetri (15:57):
Yeah. So adding these points. So I think there are two things, because of which the products are built un-accessible. So first I mentioned about the perception. In a general perception, each product is built considering that the person who is using would be a perfect one. And second thing is lack of awareness. So many people, many developers and designers, they may know that some people might face difficulties, but they are not aware how to make these things accessible. So I think the basic gap is the accessibility is not discussed in the classroom, I think, that our technical courses, whenever one is doing the technical degree. And in my personal experience, when I talk to other engineers, when I ask them, “Have you ever studied Accessibility in your technical degrees? So they just said, “No, it’s new for me.” And they got afraid after listening that they have to work in accessibility. So I think basic gap is accessibility is not considered as the part of the curriculum, classroom curriculum. So if it is included, then definitely people will be aware about it. After that, when they go to the professional world, whenever they design any product, then they will know these things and they will implement accessibility from the very beginning.

Matthew Heusser (17:25):
Speaking of accessibility from the very beginning, that’s a good point. A lot of accessibility work is testing. And we think of it as testing, we call ourselves accessibility testers. You bring us in and we look at your website and we say, “Oh, that color and that color, I tested it with this scanner.” And, “Oh, you’re relying on this image to be clicked on. You’ve got no alt tag.” Those kinds of comments, it’s all after. It seems like this is the kind of thing that can be done as part of the design process early in the process. In Microsoft products, you know, there’s going to be a file menu with open and save and exit, and it’s gonna be in a certain order. There are predictable standards for customers. If you build a Mi… a Windows product, you know how to build it, what’s it gonna take for us to make accessibility part of the requirements, part of the design starting out, and then how would our jobs change to help contribute to that? If we think of ourselves as accessibility testers.

Karan Ahuja (18:33):
According to me, you can add ARIA/HTML. You can use basic tagging process to make websites because sometimes developers use designing coding languages to make links or buttons accessible. If you use basic tools, basic coding language to make button and links, now they will be accessible by default.

Subhash Chhetri (18:56):
So adding onto the point, if we have to implement accessible from the very beginning, the very foremost thing is that there should be training guide to the designers. And second thing, there should be wireframe testing to be conducted whenever any product is being designed. If at that time in wireframe testing, if we’re gonna call these issues, if we address those challenges, then it can be implemented from the very beginning. If there is no testing included in the design phase and when the product is built at that time, it’s not easy to revert these changes. We cannot implement accessibility after finishing the product. We cannot add too much. We can only add a few things, but over a product, we cannot make it properly accessible.

Michael Larsen (19:51):
One other thing I could possibly put in here. Very often, we look at the WCAG standard and we say, “As long as we meet the WCAG standard and we are in compliance with those items, then we’re good. We’re accessible.” And yet, you can make a product that’s compliant. In other words, it meets all the criteria. It checks off all the boxes. That might work if visual impairment were the only disability to deal with, but you also have auditory. You also have cognitive. You also have mobility. And because of those, you can make a site that is a hundred percent accessible and absolutely miserable to use, not just for those people with specific impairments, but for those people who are just normal everyday users. And so it’s important to have a human element to that. I could have a limitation here. My limitation would be, sure, I can understand these things. I can look at the criteria. I can even experiment with them and make sure that they work. But because I don’t have a primary disability that I live with a hundred percent of the time, I’m missing a lot. Am I presenting that right?

Subhash Chhetri (21:06):
Yeah, definitely. If we go through the compliance, it’s like a law. Anyone can have different definitions. Also, if we include the human element, that it really adds. In our industry, what we do is we perform the accessibility testing based on the WCAG, but as well as we provide other issues, which may not directly fail those criteria, but also we report these issues. Also, we just tell the clients, if we implement these features, then it’ll benefit those users. So we perform the testing. So in our daily process, also what you do is we have categorized the issues like some directly fails the success criterias. So we will fail those and some issues which may not directly fail, which is not included directly in the WCAG. Still, these are the issues. So we report these issues and we tell them that these are not mentioned in WCAG, but these are the necessary requirements for the people. Technology is changing and the needs of the people are also changing. Apart from this, technology is growing complex day by day. So we cannot stick to the document only, because document it is not possible to update the document in a daily basis because WCAG, there is 2.2 version is coming, but there’s a lot of discussion going on. So when it finally comes out, at that time, technology may become more advanced. So for that, we have to include a human element in our testing process.

Matthew Heusser (22:55):
And on that note, I think you nailed it. I don’t know that we have much more to add. I will ask if people are listening to this, we kind of assume an informed audience. We’ve had another podcast some time ago on basics of accessibility, but it’s possible that our audience listened and said things like, “What’s WCAG? or where do I go for more?” Where can we send them that’s more than just, these are the requirements, but is more in the area of here’s where you can really learn how this impacts people and what we can do to make their lives better. And we’ll have complete text in the show notes. If people want to read it and click a link, tell us where people can go for more.

Karan Ahuja (23:40):
You can access WCAG guidelines on W3C portal, and you can also look at Deque University, they’ve been training with access courses. There are courses about basic facility guidelines.

Matthew Heusser (23:58):
We’re gonna get those links from Karan and Subhash, and we’re gonna put them in the show notes.

Karan Ahuja (24:04):
Yes. Sure.

Matthew Heusser (24:04):
And you can search for the show on Qualitest dot com. If you’re listening on iTunes, you can search for the name of the show and Qualitest and bring ’em all up. Just follow the link, click and learn all about how to implement accessibility testing, which frankly it’s just another skill in your back pocket. I think Michael has a talk or two about it. We’ll probably link a video.

Michael Larsen (24:25):
I do. I have a few and I also have some papers that I’ve written for the Pacific Northwest Software Quality Conference in regards to both accessibility and inclusive design. And I’d be happy to draw attention to those. Thanks.

Matthew Heusser (24:37):
Inclusive design. That’s I really think that’s a great… Accessibility is kind of, “What? Huh? You know, do we have to put a handlebar on this bicycle so that little kids can ride it?” No, that’s not what we’re talking about. I mean, that’s part of it, but it’s really a lot more to it. There’s really, I think, a sweetness, you start talking about inclusion that I think matters. So thank you for being on the show today. I appreciate it.

Karan Ahuja (25:02):
Thanks.

Subhash Chhetri (25:03):
It was nice to join.

Michael Larsen (25:05):
Thanks for joining us.

Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.