Quality Sense Podcast: Gev Hovsepyan – Accessibility Testing

Welcome to another episode of the Quality Sense podcast! Today I’ll share with you an exchange I had with Gev Hovsepyan. He’s the Head of Product at mabl with over a decade of experience in Software Product Management, Analysis, and Development for B2B SaaS and PaaS products. He is also an Agile advocate with proven ability to successfully capitalize on emerging market trends at large and small companies. 

In this episode, we’ll discuss the topic of Accessibility Testing, its importance, how to make it a part of your development workflow, and more.

Episode Highlights

• What is Accessibility and why should we care about it?
• Gev’s experience with Accessibility Testing
• Is it possible to automate it? How much of it?
• How Gev sees the future of Accessibility Testing and his advice for testers to get ready for it

Relevant Links:

Follow Gev on LinkedIn
Gev’s Book Recommendation

Listen Here

Episode Transcript

Federico:

Hello, Gev. It’s an honor to have you here in the show. Welcome.

Gev:

Yeah, my pleasure, thanks for having me.

Federico:

How are you doing today?

Gev:

I’m doing fantastic. I’m in Boston, weather is nice which is rare, but enjoying it.

Federico:

Amazing. So, first of all I would like to hear your story, how you started working in software, how your job nowadays is connected to software testing and software quality, just to let the audience know a little bit about you.

Gev:

Yeah, absolutely, happy to share. I started my journey in technology with my focus on mathematics, so I went to a special school in mathematics and transitioned into university focused on applied mathematics and computer science, where I did a lot of engineering and applying mathematical models to code languages and whatnot, and that led me into the economy as a software engineer.

So, right after the university is a starting to software engineering where I worked on various languages like image processing. I worked with actually hardware systems as well, and did that for about four years. And throughout those four years, I built a really deep passion about kind of making technology accessible to people because I realized that how much power I had as an engineer and how much respect I got as an engineer.

And then that made me think a lot about, “What would happen if we make this really powerful tool accessible to others, and empower others to be as cool as I felt at the time when I was doing engineering?” So, that really made me think about the product manager career where I can have that impact. And since I transitioned into product management, I really worked on kind of technology products that empower people that are less technical to participate in technology economy.

This Low-Code, No-Code movement, simplification of the technology and training people that traditionally are not trained as engineers. Yeah. In the past eight years, I’ve been doing product management for Low-Code, No-Code space, first focused on application development, and now I’m part of Mabl focusing on Low-Code test automation.

Federico:

Amazing, and I really like how you explain accessibility in a different way, how to make technology accessible for everyone, right? This is all about. This is going to be our main topic today, and I wanted to ask you what’s your experience on accessibility testing?

Gev:

Yeah, I think as I said, spending the technology space for over a decade, and throughout that time, I really seen a lot of products where accessibility either isn’t really considered or it’s considered when it’s too late, right? It’s almost like afterthought than versus like actual requirement for the platform. And that made me somewhat upset emotionally, and maybe even ethically that we’re not really thinking about people that may not be able to access that technology.

And certainly on the business side it also made me wonder why people don’t think about accessibility because 15% of the world population has some sort of disability. So, it seems like a significant market that people aren’t really thinking about as much as they should.

Federico:

Yeah. And there are different ways of accessing disabilities, right? Because we tend to think first in the people with some sort of disability, then you also have the contextual disabilities, but also another thing that I was discussing with a friend recently, people from our age, we started to use technology in very young years and we are getting old. And as we get old, we are losing our abilities to interact with the technology and with different devices. So, it’s also something that is going to be more required, as I see it, in the future because more older people are using technology nowadays, right?

Gev:

Oh yeah. Absolutely. Again, I’ve done a lot of research because we’ve strategically focused in this domain for the past couple of quarters, and as I said, if you read for example, The World Bank Report they say about 15% of people have disabilities. And when you try to get deeper, you realize that a lot of that disability is identified in more developed Western countries.

And when you get a little bit deeper, you realize that a lot of that comes from the fact of more modern medical systems and access to healthcare and whatnot makes people live longer and perhaps get more exposed to the challenge later in their life, and certainly there’s big population that unfortunately experiences disability earlier in their life, but certainly age is a big contributor to that 15% number.

Federico:

Amazing. So, I think the first questions I have for you I think they are already answered, which is how could you explain what accessibility is and why should we should care about it? Do you want to add something else about that?

Gev:

Yeah. First and foremost, I think it’s really the right thing to do, but also there’s really a huge business opportunity that companies need to think about. It’s also important to highlight that a lot of countries are adopting accessibility standards as a law. And if you look at the kind of world map and countries, it’s not only countries like you would think, like U.S. and Canada and whatnot, a big part of Europe has accessibility as a law right? Australia has accessibility as a law. Japan has accessibility as a law. So, it’s not only the right thing to do, it’s not only the business opportunity in segment. It’s also a law and the need to comply with the law.

And there is no shortage of lawsuits in the U.S. I mean, we’ve seen 40% year over year growth in lawsuits, especially in the e-commerce space in the United States, so certainly something to consider from business perspective.

Federico:

Yeah. I was going to mention before that accessibility is one of those characteristics like security or performance that you pay attention when you already have a problem. So, you realize how bad it could affect your business after you had an issue.

And in one of our customers a few years ago, we started to work on accessibility because they had a lawsuit, right? It’s after you suffer something like this that you start thinking, but actually it should be in the opposite direction. We should think about our users first and not because… Yeah, cool. According to your experience, how tests typically find accessibility issues today?

Gev:

Well, in most cases they don’t. In my experience, a lot of time accessibility testing or let’s call it accessibility audit, if the companies have something, it happens outside of kind of your traditional development process.

So, first a lot of companies don’t have it, let’s start from there, right? Which is some companies have it because of all the four reasons that we highlighted. And if they do, in most cases it’s almost like a dedicated SME group that sits outside of your traditional development organization, and they do accessibility audits once a year or twice a year.

And a lot of that effort is manual and they have subject matter experts and they write reports and those reports gets published as an accessibility report, and ultimately a compliance attestation, right? Which is obviously, in a lot of cases, when those audits happen, it’s too late in the cycle, because the product is developed, it’s in the market, it’s being used. And you do a once a year audit and you find a lot of problems, which then go back into your kind of product organization to be addressed, well the next thing you know they’re competing priorities. It’s a huge backlog of issues that needs to be addressed. So, that’s been my experience, for most part, in the current state.

Federico:

So, I understand that there are lot of challenges following that process, and probably that’s why it takes so long to fix those issues. It’s probably very expensive. In my experience, when you provide a report and an audit report, as you were saying, to a customer, we’ve a lot of issues because when we get involved, there are already many things that you should fix, right?

It’s really hard to prioritize which issues are more important or can have a bigger impact. The backlog is really bad, and probably you repeated the same error once and again in every single webpage or corner on your application. So, how can we change that? What’s a better approach?

Gev:

I think that the better approach is really to transition from thinking about accessibility as an afterthought, and more thinking about accessibility as a requirement and part of your development process, right? If you think about your day-to-day, let’s call an operation at the development team level. If you go to the smallest unit in the engineering organization, you have a backlog, you have features or product investments. If you’re prioritizing, it gets to engineers, they create a branch, they work on the feature as part of that they have hopefully some kind of continuous integration and continuous testing process. They write a feature, they run their automation to make sure the feature does what it’s supposed to do, as well as what feature works well with the rest of the technology. They deploy and there you have the feature.

Well, right now, because accessibility is not part of that process, then later in the process they have an audit and you get the problem that we discussed. Instead, you should bring accessibility into that process and enable your team to test accessibility as they are building the capability, just like you would test any other requirements of your capability. So, that way while you may not address all your accessibility needs, you will have a very strong head start.

Federico:

Yeah. Probably you will address not most, but many or the most important issues that could appear later on, right?

Gev:

Yeah. I mean, if you look at like automation technologies, you can’t automate the entire accessibility. I think there is no such a thing like, “Let’s automate it and we are accessible.” It’s more like you are more accessible, less accessible.

Now, if you can automate half of your accessibility and you can, right? Current technologies enable you to automate about 60% of test cases or use cases based on the standards defined, that content accessibility guidelines. If you do the 60% upfront part of your development process, then your downstream effort is a lot smaller. And therefore, you achieve compliance a lot faster because 60% is just a regular operation at the team level.

Federico:

Yeah. I feel that we need to not only to generate more conscience about the issues and the importance of accessibility, but also be trained more about how to do it, because 60%, according to the standard as you said, but there are many things that you still need to check, let’s say manually, right? And try to experience like a user will experience the application when using a screen reader or some other artifacts. But having that 60% covered doesn’t guarantee the user experience, but at least get us closer, right?

Gev:

Yeah. And the idea is to make as much effort to ensure accessibility early in the cycle as you can. So, you are absolutely right. The user experience, I mean, how do you know if for example, the specific button is effectively positioned in the UI and it’s accessible from that set? So, there is still good amount of manual effort that needs to happen and audit needs to happen, but more work you do earlier, the better off you are with your accessibility objectives.

Federico:

Yeah, absolutely. According to your experience, do you have any advice on how to coordinate the manual efforts on the automation efforts, following for example a continuous integration methodology or something?

Gev:

Yeah. I think the first and foremost is to… It’s very important for teams and companies to be very intentional and strategic about accessibility testing. What I mean by that is you need to effectively plan the scope of your accessibility testing upfront. You can use test case management tools, whatever organizations you use, but you need to be able to say, “Okay, this is the scope of my accessibility testing.”

Then you need to be able to clearly identify your strategy for that scope. Part of it can be automated, part of it needs to be done manually, part of it is in the UX domain, and then be able to track your progress across your Dev Ops pipeline or the innovation pipeline to make sure that you have an effective way to track the state of work. And automation software or solutions is just part of the answer, it’s not the entire answer. You need to have a bigger strategic plan for it.

Federico:

Yeah, absolutely. How do you see the future of accessibility testing? Maybe do you have advice for tester to get ready for that future?

Gev:

I think I can see… Right now, as we discussed earlier, the technology and the libraries really enable us to automate about 60% of accessibility testing. But I do see a world where that number increases predominantly by leveraging more modern intelligent technologies. So, more modern image processing technologies, certainly machine intelligence can be a huge play in their ability to do semantic search on the UI can be very, kind of text semantically understand the text can be a huge improvement for accessibility.

I think over time probably the next, I would say three to eight years, those technology is going to get adopted and that will help to increase the automation coverage to 80-90% hopefully. So, if anything, I would encourage people to look for those trends and to understand what are the companies that innovate beyond the basics. But as a starting point, let’s use the basics.

Federico:

At least, yeah. Sure. Can you tell us a little bit about how Mabl is helping testers nowadays with automation and adding some support for accessibility testing? Because I know you are a product manager, we can see that you are very concerned about the practice, and probably you are having an impact on the tools that we can use in order to include accessibility testing into our products in our development cycle.

Gev:

Yeah, I think before I do that, maybe two minutes of kind of couple of sentences I want to share about what’s happening in the quality space, and then I will talk how Mabl is helping with that transformation.

So, historically the industry has been focused on quality QA kind of function, which is almost like a function to be a gate to make sure that the quality of the product is ensured as you progress to different stages of the product, most importantly to production. I think we’re really seeing transformation from quality assurance mindset to quality engineering mindset, which is more of a practice to make sure that the software you produce is high quality and it is high quality as early in the cycle as possible.

And that practice also focuses a lot on the quality beyond the functional requirements of the software, because the quality engineering practice starts looking in the software from different functional, nonfunctional to… because quality is really not only the functional aspect, it’s also the nonfunctional aspect. And ultimately, the end-to-end journey and the experience that users get.

What we do at Mabl, we really enable quality engineers to be able to deploy test automation effectively in the Dev Ops pipeline that ensures that quality, not only the functional quality, but nonfunctional quality. So, our way to address that is to deliver unified and modern SaaS intelligent solution that enables people to not only the functional testing, but also nonfunctional testing in a unified experience, and do it as early in the pipeline as possible.

That’s our approach, and we also… the experience, we focus on the Low-Code experience a lot because we want to make sure that everyone has the ability to participate in that innovation pipeline at the company. That’s our approach, so effectively to summarize what we do, we innovate on behalf of our customers, and we focus on the Low-Code unified, intelligent SaaS test automation solution.

Federico:

That sounds amazing. I never thought about the Low-Code as an approach to make the technology and the development, and the design of the technology, and the innovation, as you said, more accessible for more people, right? Maybe this is another way to say it. I have one more question for you, which is if you have to recommend a book, which one will it be? It could be related to accessibility testing or whatever you like.

Gev:

That’s a good one. I am currently reading a book called Collaboration Overload by Rob Cross.A lot of us… Especially actually it’s relevant in the DevOps transformation where we think about part one of the kind of cultural aspects of DevOps is collaboration and making sure that there’s very proactive collaboration across the teams.

And this author is talking about the other end of the collaboration, which is what happens if you collaborate too much? And how do you know if you are having the collaboration overload? Because as a product manager, if everyone wants to collaborate and you are in the center of everyone, will you get a collaboration overload yourself? And what’s the impact of that on your productivity and or your overall mood, whatnot? If anything, I would encourage people to read that book. It’s been very interesting so far.

Federico:

Very interesting. Very interesting. Again, as a final question, I’d like to ask you, if you have anything else you recommend the audience?

Gev:

I would encourage people to, especially quality professionals, to focus on business outcomes as they are kind of focusing on the quality of the software and focus on customer experience, because we do a lot of research and in our research, it comes up very clearly times and times again, that there is a huge correlation between the test coverage and the overall quality of your product and your customer experience.

Really encourage everyone to think about customer experience and think about how quality engineering as a practice enables you to deliver better customer experience, especially now where more and more people are engaging with companies in the digital platform, right? Because everything is getting digital these days.

And then certainly will encourage people to check out our journey and how we at Mabl help quality engineers to deliver effective customer experience through delivering effective code coverage. We have a free trial that I encourage people to sign up and see how we’re trying to disrupt the space with our Low-Code intelligent, unified platform approach.

And if there are any questions, I’m here to help, and that’s where maybe they can reach out to me in social media. Check out my LinkedIn, drop me a message, and learn more what we do and how can I help in their journey.

Federico:

Amazing, amazing. Gev, thank you so much. It’s been a pleasure to have you here in the show and stay safe and talk to you soon.

Gev:

Yep. My pleasure. Thank you.