When we think of making a website accessible, we often think of making sure a screen reader works to help navigate a site or to make sure we have alt tags for images. There are of course many other areas to consider and ways in which looking at accessibility can go well beyond making a site usable for people with disabilities and towards making sites and services more usable and effective for everyone. Matthew Heusser and Michael Larsen welcome Aditya Bangari and Riya Sharma to discuss how we can adopt an Accessibility Mindset and how that mindset can help guide us towards a more inclusive user experience.
Panelists:
References:
- Accessibility Testing Services
- Accessibility Means the World: Deliver a Digital World Without Barriers
- India’s Accessibility Policy
- W3C Web Accessibility Initiative: Before and After Demonstration
- Color Contrast Analyzer
- Jeremy Sydik: Design Accessible Web Sites: (Pragmatic Programmers)
- The Dos and Don’ts of Accessibility
Transcript:
Michael Larsen (INTRO) (00:00):
Welcome to The Testing Show.
Episode 108:
The Accessibility Mindset? This show was recorded October 28, 2021.
When we think of making a website accessible, checklists of requirements are often what we consider or to make sure an assistive program or tool works with our sites. In this episode, Matthew Heusser and Michael Larsen welcome Aditya Bangari and Riya Sharma to discuss how we can adopt an Accessibility Mindset and how that mindset can help guide us towards a more inclusive user experience.
And with that, on with the show.
Matthew Heusser (00:00):
Thank you, Michael, for the introduction as always welcome back to the show. Today, we’re talking about accessibility, and to do that, we’ve got two guests who are sort of new to the Qualitest family, but not new to accessibility or development. They came in through the QA Infotech acquisition out of India. We have Riya Sharma. Welcome to the show, Riya.
Riya Sharma (00:23):
Thanks.
Matthew Heusser (00:23):
Riya comes from a development background, JavaScript, React, CSS, front-end software development. You are in Delhi, India. Did I get that right?
Riya Sharma (00:37):
Yeah. Right.
Matthew Heusser (00:38):
And our second guest is Aditya Bangari.
Aditya Bangari (00:42):
Yes. Thank you for having me.
Matthew Heusser (00:44):
Welcome to the show, Aditya. Similarly, you’ve got your software developer background, but you’re actually from Northern India and I’m going to try it. Is it Manital?
Aditya Bangari (00:56):
Nainital, the City of Lakes.
Matthew Heusser (00:56):
Welcome back to the show. When we usually we talk about accessibility, it’s a checklist. It is things that we do to prevent lawsuits. It is no fun and boring, so let’s get someone else to do it or let’s do it cheaply. You’ve got a different perspective on it. That accessibility is a mindset. Can you tell us what you mean by that?
Aditya Bangari (01:21):
Sure. So what I mean, Accessibility is a mindset it’s like Accessibility is just not only related to our websites. It’s a mindset we have to set. We need to be inclusive of everyone in the world. We can see exclusivity everywhere. If I am a bank owner and I am constructing my bank building, if I don’t have a ramp for the wheelchair bound peoples the bank would not be accessible to those number of peoples. Similarly, I’m having some shopping mall or a restaurant, and I don’t have these kinds of facilities, which makes my shopping mall or restaurant accessible to certain kind of people. We are not designing our building, keeping in mind the inclusive design. So we have to create this mindset. We have to be inclusive of all types of people, whether they are visually disabled or mobility disabled. And the web has the potential to bring an unprecedented level of independence, to people with disabilities, people with disabilities who cannot easily leave the house or may encounter barriers outside the home. They can perform tasks like shopping, banking, working, and even watching entertainment or playing games with the help of the web, but only these websites are built with the Accessibility mindset. So I would like to say Accessibility does not happen by accident. It has to be purposefully planned, built and tested. And if we have inaccessible websites, these kind of websites deprive our users with disabilities of experiences and opportunities.
Matthew Heusser (03:07):
So when I think of accessibility, realistically, it is going through all of the images and making sure that they have alt tags, going through the whole website and making sure you can navigate it. If you only have a text reader and making sure that everything renders properly, sometimes people can do some funny stuff in JavaScript that a screen reader can’t get, but a human might be able to see. And that’s usually after the whole site is developed, I’m going to go on and they’re going to have to make a bunch of changes. So we have to code it twice. So you mentioned accessibility from the beginning, from the design, I guess I could see that done with kind of an obnoxious checklist in your hand. I don’t get the impression that’s what you mean. So I’m going to ask Riya, how do you do accessibility design from the beginning?
Riya Sharma (03:55):
From the initial state, we have to make sure that while designing any of the application, we are using Semantic HTML tags. Let’s take an example for creating simple buttons. So rather than to take a div and provide a role or any state, we have to create that button using button tag. If I talk about any other element like link, then in the initial state, if we’re using anchor tag to create any element, then it is accessible in its initial state. Rather than to fix it later on by providing any role or any state in div or any other tag that is not semantic to that link. So that’s the few steps we make sure in the initial state while designing any of the application that we are using semantic HTML tags and the structure of the application is sequential. So that tools like NVDA focus, move sequentially in the order of the application.
Michael Larsen (04:51):
Hey, I hope you don’t mind me jumping in here. Normally I’m just a co-commentator on these, but accessibility is kind of my wheelhouse in part it’s one of the things I talk about consistently at conferences and it’s something that I’m an active advocate for. So there’s a couple of questions I have here. I’m curious as to how disability is viewed specifically in India versus how we view it in the United States. I’ll just start right here and say, this is an opinionated comment. I do not mean any disparagement. This is just my experience talking. And at least in the United States, accessibility is unfortunately too often an afterthought as in after we’ve designed something and everything’s working good. Suddenly a lawsuit comes up… let me be a little more charitable. A large organization wants to be able to use a product, but that large organization has a contract with the federal government or something or with a large institution. And that institution has requirements that the product be accessible. And by virtue of that, now a retroactive or a reactive process goes into play to, okay, now we’ve got to go figure out how to make our product accessible, which again goes against having an accessibility mindset in the first place. I’m curious, do you deal with those issues or is that as common an issue in India as it is in the United States?
Aditya Bangari (06:27):
So in India, it’s like, we can, you can say it’s still in a development kind of phase. Like we are looking towards this issue of Accessibility, like 20%, more than 20% of our users are not able to use our website due to some kind of disability they have. So we are looking into this direction, but we don’t have sturdy law for this. We have a guideline for our government. That’s at least for government, that site should be accessible to everyone. So we have a guideline for that. And 90% of our government websites are accessible. That sites like labor.gov.in, or like ministry of home affairs, these websites are accessible to everyone.
Michael Larsen (07:18):
Okay. Thank you very much for that. Let me shift gear for this a little bit. Now we’ve talked a little bit here about the accessibility mindset. One of the things that I like to discuss and I get into as well, there are two principles that are complimentary. We have accessibility and accessibility is specifically being able to give access to people with primary disabilities or profound disabilities through additional technology, if necessary so that we can get the information and the product and the service to them. Along with that, there is also the concept of inclusive design. And the idea behind inclusive design is that you make a product that is as usable as possible by as many people as possible without requiring that last mile technology. It seems that sometimes these two get conflated or they get confused. Have you found that this conversation is a complimentary one or is there confusion about the two, whether it’s an accessibility issue or an inclusive design issue, or do you find that those are things that come together and that you discuss coming together?
Aditya Bangari (08:39):
I would definitely say like, it’s a different issue for different situations. I would like to say, if you are creating something from scratch and you are not incorporating accessibility, right from the start, there’s a problem there because if you’re not incorporating accessibility, right from the start, if something of like a lawsuit comes up or like you said, a certain organization comes up to you and says, we want accessibility. And at later stage it will be quite difficult to incorporate it because most of your components are already built up and you are going to be doing patchwork for that component, and it will be quite complex. But if you are including it right from the start and you are using semantic HTML, and like Riya said, we are using proper tags for every component, for every element we are building. Then I think the issue will be resolved then and there only. Another kind of situation is we have already a website built 10 years ago and we want to make it accessible. We need our ADA compliant developers who are pro in this. They can identify an issue very fast and are able to resolve it. And they have knowledge of these compliance and guidelines and they are able to fix this issue.
Riya Sharma (10:01):
I would like to add one point. There are some situations also where suppose we are having five or six issues. In rare cases, there may be a chance that five of them are of accessibility issue, but one or two can be of design issue. And we have to make that component again from the scratch, because that can’t be fixed with accessibility states or rules. So that is the case of inclusive design, where we have to make that component from scratch.
Matthew Heusser (10:27):
So let me ask, then, we’ve talked about a couple of different ways to think about accessibility. Aditya just said that you want to have developers who understand these concepts and not clean it up later, but start with it in mind. And I mentioned this kind of after the fact approach of getting someone to test it and then make a big list for the end of the project. Are there misconceptions around accessibility? Do people sort of get it wrong and those hinder this process? I’m really impressed by the sort of noble way we’re describing it, of we’re going to make our applications open to everyone. And we’re not going to have barriers for people. So tell us some of these misconceptions around accessibility or myths and legends that people get wrong.
Aditya Bangari (11:17):
Yeah, there are myths and misconceptions around accessibility. And we often come around with clients who said it benefits only a small minority, why we should do it? So these are the misconceptions about accessibility, like accessibility benefits only a small minority. It’s true that when you design with accessibility in mind, you have to think specifically about people with disabilities, but the benefit of Accessibility extends far beyond just people with disabilities and the same principle that makes a website good for people with disabilities also make it good for people on mobile devices and for people who access websites on different brands of browsers or on different brands of computer or an older browsers or computers, accessible websites are easier for search engines to index and catalog and making the sites easier for everyone to find. Not just people with disabilities, accessible website are also better for people who are aging, who may be losing their eyesight or their hearing or mobility or their cognition. It’s easier for them to zoom up and look at this content. One more myth we can talk about is accessibility is hard and expensive. Sometimes client say It’s very hard for our developers to do, and it’s very expensive. Well why we should do it? I would like to say the cost of accessibility is reasonable when compared to the cost of the alternatives, if you are incorporating Accessability right from the start in your application, you don’t have to care about it later in your development process. Maintaining an equitable system is actually cost effective. So I would like to say creating an accessible system does cost money, but failing to create an accessible system can turn out to be even more expensive in the end.
Michael Larsen (13:08):
Especially if you end up getting sued. With this, If a company decides to take on a responsive design project, meaning scaling the site for tablets or for phones or for desktops and all that, much of the process done for baking a site responsive, interestingly enough, gets you about 80% of the way there for making your sites accessible. It’s a neat little add on, but if you go that effort and you use a lot of the libraries to do responsive design, a lot of accessibility features come along with it. And also accessibility doesn’t mean that your site suddenly has a whole lot of bolt on stuff, and it’s not going to be usable, or it’s not going to look right. There’s a site that W3C uses. They have a before and after site where you can see this is a non-accessible site and this is an accessibility site and you can just jump between them and the sites to the naked eye look identical.
Matthew Heusser (14:10):
I’m told that your team has developed a checklist for designers for accessibility. You can give it to designers so that before it even comes to tests, it’s going to have 90, 95% of the things that we need. And I’m told that it’s short. So could you tell us a little bit about some of those items?
Aditya Bangari (14:30):
Sure. I have a list of a few component sections to keep in mind. First one on that list is page title. Whenever we come on a website, the first thing our screen reader reads is the page title. This page title should be informative enough for… suppose we are talking about a visually disabled person. So it should be informative enough for him or her to understand that what the website is about. I go into the qualitest.com. It should say Qualitest Software Testing Company or something like that. It should be definitive enough. The next component on this list is the headings. The headings are title for a certain section. These should also be made while keeping in mind what a paragraph or the section is about. And the one thing a screen reader person can do with the help of headings is they can directly jump from headings to headings and skipping like whole sections in screen readers. They can navigate the site in a very fast manner. The next thing we have on the list is the navigation region. Navigation region, we have top navigation region in most of the websites. So we have home, about us, team section. So we have these links on the top of our website, a small bar. So our navigation region should be carefully designed.
Riya Sharma (15:59):
So let me go further. Next is color contrast. In our application, we have to make sure that color of any image of any element is passing the basic standard ratio that is given by the guideline. That is 4.5 ratio to one. If it is not, then we have to change the color of the background with respect to its pull down colors so that it matches with the standard. One tool also came to check this ratio between foreground and background color of an element that is Color Contrast Analyzer. That is a tool to check. If I talk about images, we have to make sure that we are providing alt tags to every image. If it is a decorative image, then we have to make sure that focus is not jumping over that we have to provide other hidden or any like hidden property to that. So that focus is not reaching decorative images. Next one is responsive design, like for any application, if you’re are designing from the scratch, we have also to make sure that accessibility must be there in a responsive design light. If I run that application in mobile or in any big screens than any of the element will not break or any other role or state of that element will not be reduced on that level. That’s are some of the sections that we have to keep in mind for the accessibility.
Michael Larsen (17:22):
I can also add one more that I frequently bring in. Whenever I give a talk about accessibility, it’s not a checklist. It’s more of a 10 principles idea, and I will gladly make this available. It’s also available in Jeremy Sydik book. Jeremy’s the one that I got this information from design accessible websites, and he has what are called the 10 principles of web accessibility. I won’t go through all 10, but some of the ones that I think are really interesting and valuable are the ideas that you really only think about your technology as being capable of sending and receiving texts. And that’s, as far as you should go with assistive technology and one that I really appreciate and like is user’s time and technology belongs to them. Not to us. You should never take control of either without a really good reason. And then just like you have here, there’s a bunch of the things that they’ve already talked about in regards to components and sections. But I also like the idea that what you should do is progressively enhance your content and then also allow it to degrade gracefully. The key principle here is if you’re doing an accessibility redesign, what you don’t want to do is just throw everything in at once. That can actually be an overwhelming experience and you could make your site a hundred percent accessible and then release it to your customers. And they could have a devil of a time trying to actually use the site. You’re compliant, but you’re unusable to the very people that you want to use it because you’ve overwhelmed them. And if you decide to make major changes and you take something away from them that they’re used to, it’s the same problem. I find that interesting, and maybe we could make a document and I can encourage Qualitest to post it, and they can put it in the show notes.
Matthew Heusser (19:13):
You know, I see that Michael in government websites, like you’re trying to renew your license plate or something, and they simply have no incentives to make it pretty or good because you have to renew your license plate. They have a monopoly on license plates and they have a checklist of things that have to do to make it accessible. So the site is a hundred percent accessible, but incredibly painful to navigate if you’re just everyone. And I think there’s a combination of system forces there where that’s just what you’re going to get because they don’t have any incentives to do it otherwise. And I wish I had some way out of that. I’ve spent most of my career in commercial software, driven by a free market where if you made a horrible user interface, the customers would go somewhere else. And that tends to have the effect that we hope for.
Michael Larsen (20:06):
Well, if this is anecdotal and I don’t know if I can speak out of turn just yet. I do know from the talk that I delivered at PNSQC just a few weeks ago, I was talking about accessibility and there was another talk that was happening that was being given by some IT professionals for the State of Oregon. And they were discussing some of their challenges and some of the things that they’ve been working on and what needs to be done on that end, we’ve actually been talking back and forth about, well, Hey, you know, we’d liked your presentation. We like some of your ideas. What do you think? Could we possibly get together and talk about some of this? Yeah, please. Let’s. Because I think that is the case that I think a lot of people miss Aditya and Riya, maybe you can comment on this as well. Maybe this has been an experience you’ve actually had where in the process of doing an accessibility project, you’ve met all the requirements and you’ve made your site accessible, but at the same time, your usability has diminished or become frustrating in a way that wasn’t intended. An unintended consequence. Basically, I know that that has happened in some projects that I’ve worked with and we’ve had to find a happy medium. And sometimes you have to just say, I know we wanted to go to the far end of being able to qualify for this, but now it makes the site very difficult to look at in other perspectives. So you have to balance like what works for one disability might be diametrically opposed to what will work for another.
Aditya Bangari (21:35):
Yeah. I would like to debunk this fear of ugliness. Certainly there are some ugly designs out there for people with disabilities, but I think that’s more of a failure of the imagination than a necessary condition. If you want to create ugly design, you’re free to do so, but the company should not use this excuse of accessibility and designs for people with disabilities can be just as beautiful or as ugly as designs for anyone else. That part is up to the product, I think. That’s my view on this.
Matthew Heusser (22:10):
Okay. I think that we’ve covered the topic well, and that’s our goal for the podcast. Before we get going, Riya and Aditya, are there any… Micheal recommended a book. Is there any website or any book or any link that you could recommend our audience read to help them learn more about this topic? That’s sort of valuable, but a quick read or places that can go see you? Are you doing any webinars or anything?
Aditya Bangari (22:39):
I think we have our Effective Accessibility Webinar. Yeah. It’s on our Qualitest site. There was also a couple of questions from the audience and we have answered that so we can probably give that link.
Matthew Heusser (22:56):
Sounds great. I’m sure it’ll be in the show notes. Thank you so much. Uh, Michael, you have anything interesting going on you want to talk about?
Michael Larsen (23:04):
Depending upon when this show comes out, I will be participating in the Online Test Conference in a couple of weeks in November, and I will be actually talking about accessibility, primarily the do’s and don’ts so a lot of what we’ve discussed here today, which is great. The nice thing is, is that with this conversation, I want to say thank you to Aditya and to Riya because you’ve given me some additional key areas that I can probably enhance that talk with now. So thank you very much. I really, for very personal reasons, appreciate this conversation.
Aditya Bangari (23:41):
Yep. No problem.
Matthew Heusser (23:42):
All right. And with that, I think we’re going to call it a day. Thanks for being on the show. Folks, look forward and get to know you better and seeing more of your round. Thank you.
Michael Larsen (23:51):
Thanks a lot.
Aditya Bangari (23:52):
Thank you. Thank you for having us.
Riya Sharma (23:52):
Thanks.
Michael Larsen (OUTRO) (23:52):
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.
