Many of us working in digital accessibility feel that IT departments treat accessibility as a low priority. However, other compliance areas like privacy and security get a high priority. We’ve noticed that IT executives tend to view privacy and security from a risk-based perspective. Accessibility typically operates from a civil rights perspective. In this episode, we’ll talk about whether we should flip the script and start approaching accessibility differently.
What is a risk-based perspective? Instead of trying to make everything accessible — which is impossible for most robust modern websites — a risk-based perspective prioritizes areas where problems are most likely to occur so they don’t happen. IT professionals follow this approach to privacy and security because they know that they can’t guarantee that a privacy or security breach won’t occur. By aligning with a risk-based approach, accessibility could fit the model that IT professionals already use and respect.
What are some of the disadvantages of this approach? It’s human nature to only focus on high-priority items and ignore lower-priority items. Hence, following a risk-based approach means that some content may never become accessible. This could include, for instance, content that is not public-facing or employee-only content.
At a fundamental level, this discussion comes down to two models for achieving important societal goals. On one hand, there is the civil rights approach used in laws like the ADA. This model focuses on individual rights and discrimination. It can also be a perfectionist because any violation is considered a failure. On the other hand, there is the risk-based approach that accepts that some failures may occur. The goal instead is to focus on the areas that are most likely to cause the most harm.
Thomas Logan: Hello everyone, this is Thomas Logan from Equal Entry, here with Ken Nakata of Converge Accessibility. In this episode of A11yInsights, we’re talking about how to communicate effectively with Chief Information Officers around the requirements of digital accessibility.
What Can Accessibility Learn from Privacy and Security Fields?
Thomas Logan: I know this has been a hot topic for Ken because he brought it up to me recently. So Ken, why is this something you’ve been thinking about?
Ken Nakata: For me, this topic’s been coming up a lot in working with Colorado government CIOs. As you know, Colorado required local governments to comply with their new digital accessibility law, HB 21-1110. And that law allows local governments to comply if they can show that the product that they choose best meets the accessibility standards, through things like vendor demonstrations or third-party testing, VPATs, and other means of proving accessibility.
But steps like third-party testing are expensive. So, CIOs and working with domains like privacy and security, they tend to think about things in terms of risk because they know they can never guarantee that their systems won’t be breached. So, when we reframed that the steps needed for verifying accessibility in terms of risk, CIOs tend to be much more responsive.
We have to remember that the penalties for non-compliance in the world of privacy and security are enormous compared to what they are in the world of accessibility and sometimes it doesn’t even equate to the level of harm that’s inflicted on the person.
So for instance in privacy, if somebody calls your telephone number and your telephone number was listed on the do not call registry with the FCC, technically, that company can be forced to pay about $50,000 in penalties just for that one call, which is just an annoyance to you.
By contrast, if somebody makes their website inaccessible, and a person with a disability tries to access it, and they can’t, that’s a fundamental civil rights violation. And, at best, you’re looking at maybe a couple thousand dollars of penalties. The impact on the user is a lot more significant when we’re talking about accessibility than it is with privacy.
Thomas, you used to work at Microsoft alongside privacy and security personnel. What do you think?
Thomas Logan: Yes, Microsoft was the early 2000s for me, so I was there during the Windows Vista timeframe. Exciting place. Exciting time to be at Microsoft. But I was definitely struck by the understanding at that time, even that there are these areas of compliance and governance, and they generally stay the same, but the top three, I would say, are privacy, accessibility, and security.
In my recollection of the 2000s, security was the most built out, and I remember being, fresh from my undergraduate computer science degree, being told I was responsible for a threat model, for the security of Windows Vista, and feeling, wow, I really have no education or understanding of how to complete this or do this.
But I guess my takeaway from that point is, even at that time, security was viewed at such a high level that even though, we could argue about maybe it wasn’t the effective way to roll out compliance to make people with no knowledge responsible, the fact that I was required to complete documentation for security but not for privacy or accessibility shows the relative importance that I think organizations put on these areas of compliance.
At least at that time frame, security was the most dominant concern.
And then as we’ve discussed, privacy has a lot of laws and requirements that are very clear cut that when you violate them, you’ve created a problem. These are things that you need to do as you build and develop software. So, I think even from that starting point of the early 2000s for me, it made sense to see accessibility as this requirement, but what we’re seeing and what we’re hoping to change is to make that be a little more even, and the fact that accessibility is just as important, if not more important, than these in certain cases.
So, I really agree with what you were saying that the inconvenience of receiving a phone call when I didn’t want to receive a phone call is a lot less than not being able to complete my taxes, for example, because I can’t use a screen reader. To access the software, I need to complete my taxes independently.
So, I think this is a really, good place to frame it, and I guess this is also exciting about where we’re at now, at this point 20 years later, that it feels like accessibility is still on its process of maturing to the same level as privacy and security. But we have a lot more work to do. Ken, from that thought process, why do you think accessibility has taken this long to mature? And also, why is accessibility inherently difficult from a risk assessment perspective?
Why Is Accessibility Difficult from a Risk Assessment Perspective?
Ken Nakata: That’s a great question, Thomas, and I think it comes down to this idea of accessibility compliance being a civil rights matter as opposed to a business risk matter. A consequence of that is that when we think about things in terms of that civil rights perspective, whether we know it or not, we tend to equate it with an all-or-nothing kind of perspective.
And that any violation is going to somehow be perceived as this fundamental civil rights violation and so it just can’t be tolerated. And that kind of thinking just doesn’t seem as though it fits in with the way in which most CIOs work.
But, I guess that one of the things that gets me is that there are so many applications, web-based applications out there. And so many software applications where they’re constantly evolving and that they never are fully accessible, like every single aspect of the app being accessible.
So, I think it’s a little bit naive to think about it, just to keep go using the civil rights perspective. And another consequence is that as we’re fleshing out here, if it doesn’t fit in with the existing models that CIOs already use, then it’s not going to get the same amount of respect.
But Thomas, you worked at Microsoft, you’re used to very complex applications with a web-based interface, why is it that you can’t ever get to the 100% pure accessibility on these applications, even though multi-billion dollar companies are developing them?
Thomas Logan: My first response is tying it back to security and privacy. I think it’s the exact same answer. You can’t get to 100% secure or 100% private. So, I think accessibility fits into that realm just from a big-picture point of view that you can never be perfect unless you’re AI (artificial intelligence).
And hey, let’s all critique AI. I don’t think AI is perfect yet either. But the idea there for accessibility, I think, is that the number of requirements and the number of ways that you can technically fail accessibility is huge and broad. The biggest critique of the Web Content Accessibility Guidelines (WCAG)is that they’re very long, and they’re also a little open-ended and open for discussion and debate.
I’ll segue with that with saying the initial section 508 was a lot less clear, so I think WCAG is much further along in providing that guidance. But because technology is so varied and complex, the ways that you can fail an accessibility success criterion are pretty varied.
And I do think that, just having an understanding thought to why security is viewed more importantly than accessibility, there is some logic to the idea that with security, generally, the risk applies to all of your users, where in accessibility, depending on which violation we’re talking about, it applies to a percentage of your users.
And some violations apply to a very small percentage of users. And that’s just something difficult about the way the Web Content Accessibility Guidelines are written. They’re coming from the right place of the importance and the impact of the issue, but they don’t consider the number of people that could be affected by the issue.
And so I think that just is one big barrier that you can’t really look at a lot of the issues in accessibility the same way security, where I think in general security affects everyone. Accessibility, just by its nature, it won’t affect everyone. It could affect like a large portion of the users, but it won’t affect everyone.
Ken Nakata: Yeah, I agree with that. The difference is that, to me, with accessibility, you’re going to have a very small number of users, or, a smaller number of users, a minority of your users, that are going to be severely impacted by an accessibility barrier, and that accessibility barrier won’t affect anybody else. Your typical non-disabled user is not even going to notice it. Whereas, in other kinds of violations, you can have that same, like security or privacy, that same type of issue. Even though it might not be everyone’s data, but it could have been everyone’s data, and that kind of breach really can be generalized across all of the users.
Prioritizing and Fixing Accessibility Issues
Ken Nakata: Thomas, you and I are both consultants in digital accessibility, and we both do a lot of testing, and I think that when we’re looking at websites we build in this idea of risk into the way in which we approach things as well, to a large extent. Do you want to talk about that?
Thomas Logan: I’ve been consulting in accessibility for way too many years at this point, but I think what I’ve learned in doing accessibility consulting is what we’re discussing, that basically if we’re being honest, no one ever complies with the Web Content Accessibility Guidelines, and it becomes more of a matter of how detailed are you going to be in the number of violations or how detailed are you going to be in fixing and addressing the issues that impact people with disabilities the most.
And I think I’ve prioritized with my company, after learning from years of work with other companies, that I really want to make sure the product works for the main use cases and the main reason the product even exists. So my process at Equal Entry is a 100% always focused on how people use the product.
And my philosophy, I still completely agree and adhere to the philosophy of WCAG, but I do believe that if you, can’t show that your homepage is accessible or your most used feature is accessible, why are you looking at all these other areas and aspects of your technology? And so my process has been I do keep all the success criteria in, but I view them from the perspective of the impact to the user.
I’ll be honest, like I don’t think I can always be the person speaking on behalf of the user. I think we, we all know this, but there is something to be said for certain violations in accessibility are very clearly blocking and or very clearly stop someone from completing the task.
For example, if you have to listen to a CAPTCHA requirement or see a CAPTCHA to log in to a site, and you’re blind. If that’s a requirement to use your visual sense to log in, clearly blocking. And some of these items like that, which are so obvious and egregious, I would love that to be more prioritized or from a risk assessment point of view.
That should be weighted more heavily than just A or AA that we have in accessibility. Because even with A, that’s still so much stuff to consider. Generally like I run my process that way, but I have to work with my clients and explain my process is focused on your core scenarios.
We want to work on getting your core scenarios fixed first. I don’t want to go into these other areas until we’ve demonstrated your primary functions work. And truthfully, I feel like I’m still living in a place where it’s a lot of effort for a lot of companies to get even the primary functions completely working for accessibility.
And that’s something where I think we have to be realistic as a group and as an organization that even with these new laws coming, we have to be realistic. Let’s make sure that we’re getting incremental improvement, and that it is realistic. Because I guess for as many years as I’ve been working in this industry, for the most part, it’s been unrealistic.
There’s an unrealistic expectation that you’re going to be fully accessible and it’s never met or realized. And so I feel like we need to have this conversation in our industry. And I’m glad you brought it up because it’s like, how can we still hold on to all these things that I value and I think are important, but also have a pragmatic approach where we see results and we don’t just have data and spreadsheets and reports.
We actually have things that work for people with disabilities. So Ken, I’d like to pose to you, because you’ve been working even more years than me, what do you think is an acceptable accessibility risk, or what are some criteria for evaluating an accessibility issue that you would be comfortable with putting out there as things that could be lower priority or higher priority.
Accessibility Risks
Ken Nakata: Well, working with state and local governments, it’s a lot easier to prioritize applications because they use their applications in so many different ways. For instance, if an application has a lot of public exposure, then obviously that raises its priority. Not to say that internal applications or things that employees are using are aren’t relevant, they certainly are relevant, but it really ultimately depends on, how many people are impacted.
And also, do I know whether people with disabilities are going to be using that system? Also, if you’re talking about a public entity, another factor would be what the overall cost of that application is, because what cost this is also going to be probably reflective of the cost to replace it with another application.
So, that gets into the risk level that’s associated with that because if you’re a big public entity, you don’t want to have to spend another $200,000 or $300,000 to replace an application that you just got. Another factor that I can go into that is the amount of man-hours that are required to put it to create that system or to change that system.
So, if you have a giant content management system, and it’s going to take weeks and weeks of work to transition to another CMS system, that’s certainly a factor. But you add in all those different factors, what we’re finding is you can prioritize based on risk of, what the, category of product we’re talking about. And so one of the strategies that we’re developing with the CIOs is for those really high risk things, you want to put in a lot more dollars and making sure that you fix them.
So, that would include things like having the vendor provided accessibility demonstrations or hiring a third-party consultant like you or me to come in and actually assess that product before you end up buying it and evaluating the competing products. Figure out which products meet your business needs and then within that pool of products, which one seemed to be the most accessible and then actually comparing use cases like the way in which you’re actually going to be using the application.
Comparing the products in terms of accessibility, between those different vendors, both in use case testing as well as vendor demonstrations. And then, of course, collecting your VPATs and your ACRs and getting user feedback from, and collecting this and Googling the app to see what other people just generally say in the wild about the application.
And then collecting all that data, and coming up with a fair comparison between them to say, yeah, we chose the best product in terms of accessibility. But all that takes a lot of time and effort. And so for a lower priority application, say it’s something that’s only being used by five people in the public works department to figure out which potholes to fix.
And the only people that are going to be using that data are those five people and none of them have disabilities because they all have to be out there fixing potholes. Then in that case, we’re not going to go through that same kind of level of effort. It’s in that case maybe, VPATs and ACRs, might be good enough.
Thomas Logan: I want to chime in. I think we’ve discussed this in a previous episode, but I really think the democratization / transparency of this data is very important because to address the cost barrier, it becomes I just was looking up on ChatGPT, so I’m quoting ChatGPT here, people.
There’s 90,000 local governments in the United States. So, if there’s 90,000 different entities, and all of these entities have the example you just gave, even if five people are using that service, when you multiply that, in tech we always have to think in that big scale, it really is something where maybe the smallest entity can’t test that application.
But if that application’s been tested by three other entities, that data or that information if we could have a way for that to be available, we could really reduce that piece. And I think that is a big area that accessibility does require real testing, and it needs input from people, but we just don’t have a way to expose the information.
“Hey, I already tested that.” or “Hey, I’m the person with a disability that needed this. It didn’t work for me.” I think that would be great still for our industry to be thinking about how do we get that information disseminated or shared. Because from a practical, pragmatic perspective if you can reduce the cost of that data.
Maybe you could get more of an influence than on purchasing an accessible product. Because if you say, “Well, to purchase an accessible product I need to hire these companies, and I need to do all this testing.” Most organizations say that’s too expensive.
But if you say, “No, here’s the data, this is not an accessible product, or they haven’t been able to demonstrate that they’re accessible.” They should be out of the running, and they should have that influence on them to work harder.
Sharing Information
Ken Nakata: There is some effort to actually share information in that regard. It’s still very early on, but organizations like National Association of Counties or National League of Cities are, beginning the thought process around how do you share that the testing results so everybody doesn’t have to test things.
Unfortunately for Colorado, they were the first ones out and coming out with their accessibility requirements and they required everybody to meet WCAG a year before anybody else does in the country. Colorado entities, in particular, they’re intergovernmental entities. They go by the acronym CML for Colorado Municipal League or CGAIT, which is basically the Association of Colorado Governments and their IT.
Their folks, they’re also realizing, hey, we have to start sharing information about this stuff because it’s pointless for all of us to be testing all the same applications. And even from the vendor perspective, I think that makes sense because if I’m producer of a common CMS, I don’t want to be getting 50,000 test results. I want to be able to just look at one high-quality test result and say, “Okay, I’m fixing this thing according to this.”
Thomas Logan: Well, I hope that’s encouraging to hear that there is some progress being made, and I also hear you on Colorado having to lead the charge a bit here. They’re a little bit ahead of the rest of the country, but we’re going to be seeing this more and more as this law from the DOJ takes its hold across the U.S. Our conversation today has been really interesting to me.
I’d love to hear from you all, our listeners (readers). Do you have opinions on what should be an allowable accessibility risk? Do you think nothing should be allowed? Do you have items where you would say, “No, that’s minor, that’s not important. I’m okay with that being in the product. Let us know. Add your comments and we’ll be happy to respond. Thank you so much for your time and we hope to see you in our next episode.
New Accessibility Training
Here’s the 1-hour crash course you’ve been looking for to help you prepare for the DOJ ruling on digital accessibility. Learn more about the course and sign up.
If you have questions related to the accessibility of your technology, please contact us to discuss how we can help.
