.png){kind=icon}
The third Thursday in May is dedicated to Global Accessibility Awareness Day (GAAD). This day celebrates digital accessibility efforts, and also sparks conversations about accessibility with designers, developers, and tech leaders all over the world.
In 2015 we created our accessibility team to support our clients who want to launch inclusive products to a global audience. Last year we started a partnership with the Oregon Commission for the Blind to onboard testers with disabilities on our team. With many years of experience in the accessibility sector, we asked our accessibility experts questions about accessibility testing and working with testers with disabilities.
Transcript for video:
Paige: Thanks for watching this video on Global Accessibility Awareness Day (GAAD). In this video we will be meeting with a couple of our accessibility experts to discuss the various challenges in Accessibility and what it’s like to work with testers with disabilities. I’d like to introduce Nicholas and Abdul.
Nicholas: Hello, I am Nicholas, and I am the project manager for accessibility testing at PLUS QA.
Abdul: And hello, my name is Abdul, and I am a QA Analyst with the accessibility testing team at PLUS QA.
Paige: To begin, let’s start with why do you think Accessibility testing is important?
Abdul: I’ll take this one. Well the first is the moral perspective, which is that it’s the right thing to do. Accessibility noncompliance means exclusion of a lot of people. The second is practical. One out of every four people living in the United States self identifies as having a disability. That’s 25% of the population that has a significant buying power. People with disabilities have a significant amount of influence on the consumer choices of friends and family who are not disabled. And so, these are important considerations, business considerations, as to why one should actually pursue accessibility.
Nicholas: From a technical standpoint, if you assume that accessibility is something that needs to be included in your project, it’s much like functionality or UI testing, any growing backlog of bugs, is increasing your technical debts and getting to them sooner rather than later is only going to help get to the eventual compliance. And on the note that is it necessary, there is a strong legal precedent set now for digital accessibility being a requirement. So yeah, it’s always, it’s better sooner rather than later.
Paige: Why is automated testing not enough for accessibility testing? And why do you think it is valuable to have people with disabilities on your team?
Nicholas: So, as far as the automation portion of that question goes; I think that automation is a very useful tool, even in accessibility, it can, it can take care of a decent amount of work for you. Things like contrast values when we’re talking about color contrast you can automatically check color values and make sure that they’re within the right range. you can check HTML formatting, with automation, and really a pretty wide array of things. And that is great and definitely worth looking into. I would say, because of the complexity of accessibility issues, automation should be thought of as supplementary when testing accessibility. I think right now the standing number is something like 30% of issues might be caught by automation, and that would probably be on a good week, and the rest of the testing would be done manually. So yeah, I think that automation is a fine tool, but I think people analyzing these accessibility problems that are present in a lot of software today, it requires a human mind still, at least now. As far as why it’s valuable to have people with disabilities on your team, or on my team specifically, I think I could defer to Abdul on that one.
Abdul: Yeah, I would say that our team comprised of primarily sighted testers, do phenomenal work in accessibility testing. We use the Web Content Accessibility Guidelines as, as a rubric for testing, and have been really quite effective with that as a framework. As a blind tester, I feel that I am able to bring added perspective to evaluating accessibility issues. For me, accessibility challenges are very much a lived experience, and I think in some ways the team, is able to benefit from kinda analyzing accessibility that may not fit cleanly within the rubric of the WCAG.
Nicholas: Yeah, it’s a valuable perspective to have on the team; I think that it’s one thing to read these fairly technical, fairly dry Web Content Accessibility Guidelines, which are great, and presume to know how they should be implemented in software and what a user who maybe is blind needs from the software. But it’s an entirely different and better thing to have somebody who has lived that experience confirm and assist you, in, in figuring out exactly how to categorize accessibility violations and also maybe how to flag things that you might not associate with, y’know, rule 1.3.1 on, with any given issue.
Paige: What would you recommend for someone who has disabilities if they wanted to get into the IT field?
Abdul: I think the first thing that I would say is: be curious, be humble, be open, be eager. That’s advice that I would give to anybody, disabled or no. The second is that if you feel that you’re qualified for a job then apply for that job. And the third is that if you’re called into an interview it is true that employers are not allowed to ask you about your disability but that does not mean that they don’t have questions in their head about your disability. And, so you want to create a space where you can discuss and talk about your abilities as somebody who actually has a disability. I think that that kind of information really goes a long way towards a positive outcome for the interview. The fourth and final thing, so let’s say that you’ve been hired and perhaps you’re apprehensive about what you have to offer your team. And the thing to bear in mind is that you have a perspective that is unparalleled. Disabled individuals have been using technology that’s been at the leading edge for a very long time, and way before these technologies have been mainstreamed. Text-to-speech has been used by the blind and visually impaired since the early 1980s; motor-impaired individuals have been using speech recognition since the mid-1990s. And these technologies have now been mainstreamed in personal digital assistants like Amazon Alexa or Google Home or Siri. Today we talk about how we can use augmented reality, artificial intelligence, and wearables y’know to enrich our lives in the future, and disabled individuals are living that future now. And so this is, this is unique insight that you can bring into a team that is focused on innovation; y’know a team that values innovation is a team that values that kind of insight.
Paige: So what do you enjoy about working with the PLUS QA Accessibility team?
Nicholas: It feels like my team’s business goals are based off of compassion and inclusion, which can be kind of hard to find in a position sometimes and it makes going to work fairly, easy; I don’t need to think up reasons to go to work, it’s pretty clear cut. And it’s also pretty fun to analyze these scenarios with constraints on them; it’s an enjoyable position.
Abdul: Yeah, I don’t really have much to add to that, I agree with it all. I would say that the abbreviation that we use for our team is A11y, which is an abbreviation for accessibility. But the word ally is apt; I feel that every day when I come to work that I am among allies, people who are committed to the cause of advancing accessibility in the digital space. And it’s lovely that I have these individuals as my colleagues and, and my friends. So, yeah.
Nicholas: That is a big part of what makes it enjoyable, that we can say that we’re at least doing our best to, to help make software accessible and make sure that everybody can use all kinds of different services that are in the digital space.
Paige: What are the challenges in testing that you have experienced so far on both web and mobile apps?
Nicholas: There are always challenges in, on any QA team and most of those are in common with an accessibility testing team, but there are couple of unique challenges that you might face with accessibility testing. A good example of one of these challenges might be the way that UI components are named. There can sometimes be sort of a disconnect in terminology. UI components often are named after their visual counterparts in real life. For example, you might call a UI component a card because it is shaped like a postcard. That isn’t going to mean very much to a user who is blind; that information won’t be present to them. So that can be a challenge; I know that we’ve, we’ve, especially writing tests, I’m not saying “hey, go to the card” cause that just doesn’t mean anything to a screen reader. So that’s definitely a challenge to be aware of. And I would say that there are a few other scenarios, I mean, differences between platforms is another thing. I know that in functionality testing you’re always going to see differences between a maybe like a native mobile platform and a web platform. And some of these issues are augmented in the accessibility realm. You have, typically a webpage can have quite a bit more to it than a smaller mobile application; just a more complex page, more menu items, more ways to leave the page, and with all that complexity that often will translate into an information overload for a screen-reader and a screen reader user; hard to parse through all of it and make heads or tails of what’s happening on that screen. On the other hand on a native device you might not have that problem, the constraint of size will often make the UI more simplified; that’s fine, but also those constraints will pare down functionality that might’ve been useful to a screen reader. So it’s tricky to find a balance and you find that differences between platforms might cause some interesting accessibility issues to navigate.Paige: At what stage of a project should someone consider accessibility testing to be part of their plan? Why do you think Accessibility testing is a subject that product managers, designers, and developers need to consider on every project? Nicholas: I know that we’ve talked about this, Abdul and I have talked about this quite a bit; I guess I’ll let Abdul take the design phase.
Abdul: [laughs] Well yeah, I was gonna say every phase of the-
Nicholas: Yeah! [laughs]
Abdul: -project. But the design phase certainly sets the tone for the entire process. It informs how engineers will go about implementing y’know the, implementing the design; it informs how QA teams will go about assessing accessibility. So this is crucial because I think that considering accessibility only in phasing following the design phase often y’know means a crude technical debt.
Nicholas: I think a lot of companies probably find themselves in this situation; where they feel like, “well we already have a product, we’re not building it from scratch here, and we just want to make sure that what we have is accessible.” But it’s pretty rare to find a company that is not working on something new in their software realm. And the sooner that you get your design team on board with accessibility, the sooner you kinda just like put a block in the large amount of new accessibility violations you’re going to find if it’s not kept in mind in the design phase. Beyond design, certainly, just like you would with functionality testing, Abdul and I both do a lot of this, what we call pre-release testing, which is really just making sure stuff works before it gets released. It’s just as important for accessibility as it is for functionality or UI testing, and maybe more so, especially right now probably a lot of companies are getting their developers trained in accessibility or maybe don’t have a ton of expertise in accessibility yet I think that making sure that you have somebody who knows what to look for looking over your software before it’s released is really important. Y’know it’s the old adage of how much more expensive it is to fix bugs after they’ve been pushed into production, you lose business money just from customers and you lose developer hours from triaging it back into the engineering phase. And when you add the fact that you need this extra level of expertise in accessibility development and just know-how, how to make sure that you’re following the WCAGs, so it’s almost more important that you pre-release testing with accessibility. I guess the last phase, at least major piece of the software development, as far as a QA team is concerned, you where you would want to involve accessibility testing is the after-release or what a lot of people call regression testing. It’s probably a good idea to at least periodically audit software after it’s been released, especially while we’re in a stage right now where a lot of companies are pushing for accessibility but aren’t quite there and don’t have a ton of experience maintaining compliance. So it can be quite useful to just make sure you’re taking a look back in cause things break in production all the time, from a lot of moving parts and large software and accessibility issues are no exception. And as we were saying before for pre-release testing sometimes they can be fairly time-consuming to fix but they need to be fixed. So yeah, these periodic audits will save a lot of trouble. Even just light regression testing that’s going on is a wise move. These are all services that PLUS QA does provide; we can review designs and make sure that they’re headed in the right direction from an accessibility standpoint. We can advise and help revise these things so that you reduce the amount of time engineers spend having to go back and fix these things, what the designers have to spend revamping their designs all over again, because y’know some guideline wasn’t kept in mind. That’s a lot of time spent, and it’s fairly frustrating. We also test a lot of pre-release accessibility testing; it’s a huge part of what we do, preventing things from getting out there into production. Especially right now in this current climate, legally-speaking, it’s good to have the peace of mind that you’re not releasing accessibility violations into production. And a great way to start your process of getting up to compliance and getting some sort of assurance that you’re not a risk in the accessibility realm is starting with an audit and then maybe just having recurring audits going on into the future until they’re not necessary anymore. Which is something that we often start with with a client.
Paige: Are there legal consequences for not including accessibility?
Abdul: PLUS QA is not a law firm, and we are not legal practitioners here. What we can say is that there is mounting legal risk associated with noncompliance to accessibility standards. And the WCAG, web content accessibility guidelines, is a recognized standard in case law herein the united states. Nicholas, do you have more to add?
Nicholas: Yeah, those WCAGs, those are what we base most of our work off of. Of course it’s on all of our clients’ minds that there is some legal risk involved in this field now. those guidelines do have standing in court. So while we don’t provide legal advice per se, the guidelines that we do follow are legal precedent so that’s helpful. I would also say, just to address the risk of not having any form of accessibility testing or design review; since 2013, I think from 2013 to 2018 there has been a massive jump in federal cases to do with accessibility law in the digital space. I believe it’s like 273% increase from 2013 to 2018. So that’s certainly something that is worth mitigating that risk, as its a common topic in the courts these days.
Paige: Nicholas, how has your perception and process about accessibility testing changed since testers who are blind have joined your team? What has it changed for the team?
Nicholas: Well, it’s changed quite a few things about how we work as a team and we’ve modified a few processes. It’s also brought a lot of insight to the team. we can very confidently prioritize issues, I can ask Abdul for his opinion on whether a certain accessibility violation if it’s fixed if that will have a broader impact than another one. Y’know, from his perspective, what are the most severe issues, what deserve the most attention; that is very helpful insight and perspective that we get from having people with disabilities on our team. Our processes have changed in a few way, I think for the better. We have to, we write a lot of test that we can follow along with. And we have to make sure that we aren’t introducing new tests that rely on sighted, that rely on sighted users or use terms that only sighted users would make use of. But y’know as an accessibility testing team, that’s par for the course.
Paige: Thank you Abdul and Nicholas for joining us today.
Abdul: Thanks for having us.
Paige: And thank you for joining us on Global Accessibility Awareness Day. If you have any questions about adding or incorporating accessibility testing to your project please visit our website or send us an email with your details so we can partner you with our accessibility team.