Demystifying Accessibility in the Procurement Process [TRANSCRIPT]
JENA WALLACE: Thank you, everyone, for joining us for today’s session, which is called Demystifying Accessibility in the Procurement Process. My name is Jena Wallace. I am a content marketing specialist at 3Play Media. A quick self-description, I am a white woman with light brown hair. I’m wearing green cat-eye glasses and a black shirt. Today, we are excited to have Kim Hodges with us. Kim is director of Digital Accessibility at the University of South Carolina. And thank you so much for joining us today, Kim.
KIM HODGES: Thank you for having me.
JENA WALLACE: To get started, I’d just like to do a quick overview of your career journey. How did you find yourself in this role of director of digital accessibility at USC? What has your career progression looked like?
KIM HODGES: Oh, that’s a great question. It’s been an interesting one. I got started working in digital accessibility as an independent consultant. A lot of that was facilitated through some of my personal needs that I had when I was in college. I lost my sight and was visually impaired for just shy of eight years. And during that process, I was in college and was struggling with the move to online platforms because accessibility was a challenge. Especially back then, it was definitely not in the state that we have now.
And so I started helping my own university’s IT department, at that point, provide me with accessibility options and walk them through that. And that just kind of dominoed into a career, basically. And I’ve worked for an EdTech company based out of New York as a director of digital accessibility. I was the chief accessibility officer for a web consulting firm for six years. And then during COVID, I had the opportunity to come on here at the University of South Carolina and help them build a digital accessibility program kind of from the ground up. And that’s been exciting and fun and challenging. And that’s what leads me to where I’m at today.
JENA WALLACE: Cool. Yeah, that’s really interesting. Thank you for sharing your background with us. I find that a lot of folks, including myself, who have been drawn to accessibility are here because we have experienced becoming disabled in some way ourselves. So that’s always interesting to hear the reasons why people are into it. So what was it like building a digital accessibility program from the ground up? How crucial was it to prioritize accessibility?
KIM HODGES: Very. And I’ve had the pleasure and, also, challenge of working with over 25 universities throughout my career. And that’s kind of spanned from everything from the more technical remediation side to the full program building, like I’ve been doing here at the University of South Carolina. It’s been interesting, especially coming into environments where there’s, maybe, an awareness of accessibility. But it’s very obvious that people don’t know where to start or how to maintain compliance and policies and procedures that support digital accessibility within their respective organizations.
And at the University of South Carolina, I’ve been very lucky. The administration has been very supportive of the work that we’re doing. The IT department and the CIO have been very supportive of what we’ve done. And it’s been fun and interesting, especially because when we look at state and governmental organizations, there are certain state requirements that we have to adhere to. But then each organization functions kind of as their own little ecosystem and their own little microcosm of departments that independently function, even though they’re under the same umbrella.
And so when you’re looking at something like digital accessibility and communicating that across a larger audience, it’s really about relationship building. And for me, that’s one of the fun parts of the job is it’s about awareness and education and relationship building so that people understand the importance and then are more willing to integrate digital accessibility into what they do.
JENA WALLACE: So you’ve mentioned relationship building as a big priority when it comes to implementing digital accessibility. Are there any insights around how that plays with the legal and regulatory aspects when it comes to digital accessibility?
KIM HODGES: Oh, absolutely. And I’ll try not to dive too far into that question because that could eat up all our time, just that one. But it’s definitely important, especially from the legal, regulatory, risk management, all of that that encompasses these larger organizations. An example being is I work very closely with our procurement team, which is kind of why we’re here today, which handles a lot of the contract specifics around procurement and product purchasing, but also with our internal legal team to make sure that things like contract language are specific enough to cover us from a liability standpoint, as well as hold vendors responsible for certain levels of accessibility.
So that’s just one piece. Like I said, I could go into that for the entire amount of time. But that kind of relates to what we’re here to talk about a bit today is making sure that we’re covering ourselves from a liability standpoint while also doing the right thing from a digital accessibility standpoint.
JENA WALLACE: For sure. So going into doing the right thing and the social responsibility. On the other side of the legal and regulatory, what are the benefits of investing in digital accessibility for organizations, beyond just ticking those boxes and meeting those requirements? Could you speak a little bit about some of the other benefits that it has?
KIM HODGES: Oh, absolutely. And there’s a lot that people don’t realize. And frequently, when you’re working within this area, especially I can speak from working as a consultant, that primary concern was, do we check these specific boxes to meet criteria and compliance criteria? And while that is important, that’s really just a very small piece of it.
And the benefits, user experience is a big one. And it’s one that I’ve noticed a lot, especially when we talk about different content management systems, and learning management systems, and seeing the accessibility changes, especially in a university environment, and how that can positively impact students. When we start making adjustments to account for digital accessibility in those types of environments, you end up getting a lot of feedback from all of the users on the increase in usability, the increase in efficiency in a lot of different areas.
And that’s just one small facet. But when you start paying attention to things like universal design and UI/UX implementations and even case studies that you can do on different user styles and user types, you will really see just a broad spectrum benefit when you start accounting for digital accessibility in a lot of those environments.
JENA WALLACE: Yeah, definitely. So I think that’s a great point and a great segue into talking about what we’re here to talk about, procurement, and what I know you’re excited to be talking about today. So let’s talk procurement. How can organizations incorporate accessibility considerations right from the beginning of the procurement cycle? What are some of the key steps?
KIM HODGES: Absolutely. So each organization is different, especially when we’re talking about procurement processes. But for a lot of state organizations, there’s a state procurement process. There’s policies that support that. But even if you’re not a state-run organization and you have a procurement process as part of your business model, generally speaking, getting digital accessibility involved as early as possible is usually the best way to go.
I partner digital accessibility frequently with a lot of other compliance checks, like security, and privacy checks. And so it fits right in line with those. At the university– and this is a fairly recent development– we have language in our solicitations for RFP that specifically address what our requirements are from a digital accessibility standpoint. And then as part of that, when we’re vetting the different proposals that are coming in throughout that RFP process, we’re asking for documentation to support certain levels of compliance, which generally speaking, WCAG 2.1 AA, Section 508, depending on where it lies specifically. But even just some general accessibility guidelines, even when products aren’t “web-specific,” we try to make sure that they at least have some accounting for accessibility as part of that process.
I know at the university, the route that we’ve taken is once we’ve evaluated different vendors and we’ve chosen the top vendor that we’re looking to go with, that’s when we get into the more involved review process. That’s when we ask for things like the Voluntary Product Accessibility Template, or the VPAT. And we start looking at the VPAT and vetting the VPAT to see if the information that they have provided meets the criteria that we have.
If it doesn’t, one of the steps that we take is we will frequently engage with the vendor to see if they have a plan to address those issues. Because I like to say this all the time, if we stayed really firm with accessibility guidelines, it would really limit, in a lot of cases, the amount of products we would actually be able to purchase if we were hard black and white.
So at the university, we will engage with vendors to find out what their plan is for long-term accessibility if they don’t meet full compliance criteria. We’ve even, in some instances, helped them get their accessibility up to a certain place. But I know that’s not always possible, depending on the resources that different organizations have. But again, it’s really good to get digital accessibility checks and validating the digital accessibility as early on in the procurement process as possible.
JENA WALLACE: Definitely. I’m really glad you brought up VPATs, which we’re definitely going to touch on more later in the conversation because there’s a lot to talk about there. But it sounds like this idea of adding accessibility into the process, or sometimes we call it at 3Play “backing accessibility in,” into the RFP is a key part of the process. So how can organizations make sure their desire to find accessible vendors and products is expressed when they’re putting out those RFPs, to make sure that they’re aligned with the type of vendors that they want?
KIM HODGES: Yeah, absolutely. So the key, generally, is making sure that you have very specific language within your solicitation for RFP. That’s the best place to start. There can be a bunch of different ways to go about it. You can get very specific and have WCAG 2.1 AA as an expressed example of the compliance level that you’re looking for. Some organizations will choose to be more general and just say that we require adherence to ADA requirements, or Americans with Disabilities Act requirements. Again, depending on the organization and what’s going to fit better, you can even have Section 504 or 508 requirements in there, depending on what the context of that product is going to be, but making sure that, as part of the solicitation, that it is very clear.
And then also reinforcing that, so if you have vendors that are sending out RFPs, and it’s very obvious that they don’t even come close to meeting that particular requirement, that there are conversations around why that is happening. Because I know in my own experience, we’ve had RFPs go through where we’ve had to restart the RFP because none of the vendors have addressed the accessibility questions that we had as part of the solicitation.
It’s unfortunate we have to do that. No one wants to do that. It’s additional time and work. But really reinforcing that, that’s not a suggestion, it’s a requirement. That’s a must-have, not a nice-to-have.
JENA WALLACE: Yeah, that’s really interesting. So how do you strike the balance between accessibility requirements and the other procurement criteria, such as cost and functionality, while also balancing the idea of trying to make sure you get the right vendor for the job?
KIM HODGES: Absolutely. That’s the trickiest part of this entire thing is finding that balance. I think one of it is being really mindful of what the reasonable standards are. I’ve said this in meetings that we’ve had at the university. I’ve said it in other webinars and presentations that I’ve done is if we did stick to that hard line, organizations would be very limited in terms of what products they would be able to purchase.
And when we’re talking about things like an example being certain software suites that support student medical centers, accessibility generally isn’t something that’s even remotely considered because it’s not web based. But we do still want to make sure that it has some level of accessibility baked into it. So that’s when further conversations with the vendors become really important.
Again, it is a challenge because you still want to be able to meet the needs of whatever it is within your organization that is trying to procure this particular piece but while also making sure that accessibility is factored in. One of the approaches that we take is during the question and answer portion, generally, of RFPs. That’s when we get into a lot more detail about if they don’t have ADA requirements or WCAG requirements addressed, we usually want to know why, if they have an awareness of it. If they don’t have an awareness of it, are they willing to work with us?
Our team has– we actually saved an entire RFP with a vendor that one of our divisions was very keen on going with because they didn’t have anything around accessibility. But we worked directly with them. We helped them develop a development roadmap for how to integrate accessibility. They established their own system checks. They even contracted with an outside vendor to make sure that once they started instituting accessibility changes, that that vendor was coming in to check them and validate them.
That’s a best case scenario. But there’s a lot of creative ways to engage with vendors that maybe have a vague awareness of accessibility. Or they’re willing to work on it. They’re just not quite where you need them to be yet.
And for us, that’s really where it becomes important to gauge the intent from the vendor on if they don’t meet criteria that we have set in place, are they willing to work towards that? And in what kind of a time frame could they accomplish that? And that’s where you have to have some creative judgment around how to move forward and how to proceed with those particular challenges.
JENA WALLACE: Yeah, that’s amazing that you were able to work with that vendor and help them start their accessibility journey, which I feel like you don’t see that as much. So that’s really cool to hear.
So we have an attendee question that falls under this topic. How do you handle pushback when people do not understand the importance of accessibility in the procurement process? In particular, when they feel we are the bottleneck in their process.
KIM HODGES: Oh, man. Yeah. So I’m very much one of those people where I feel bad having to be what I classify as “the bad guy,” when I have to step in and be like, well, this isn’t going to work. That’s where that relationship building really becomes important. And that’s even outside of the procurement process in and of itself. I’ve definitely had challenges throughout, not just my time at the university, but just in my career in general with getting that kind of pushback. And I’ve been lucky enough that I’ve been able to, very frequently, turn that pushback into people that are on my side.
An example being is the way that our process operates now at the university is a byproduct of a run-in I had with a procurement officer where we were, I’m not going to say yelling at each other, but in a very stern professional tone, disagreeing with how accessibility should be factored in. And during that conversation, I really was able to glean from how that individual was speaking about it that they didn’t really understand what it was. They didn’t understand what it was. They didn’t understand why it was important. And they also didn’t understand how the law worked into all of it.
And so after we had that engagement, I had the opportunity to set up a meeting for that individual and I, that procurement officer and I, to have a conversation about it in a more calm environment. And as part of that conversation, I was able to very clearly explain not only why is it important from a user’s perspective, especially when we’re talking about organizations like universities where students are our main priority, but also the legal implications of risk.
And that’s one of the biggest things we pay attention to is risk. So if they view us as a bottleneck as part of it, explaining what the risk is by us just not doing it can sometimes help because that’s how security and a lot of these other checks that they adhere to work as well. Is it a low risk from a security or is it a high risk? What are the implications of those risk levels? And that’s how we’ve structured it at the university as well. Is it low risk or is it moderate risk or is it high risk and why? And what are the implications of those risk levels? So if it’s high risk, what does that mean?
And by setting those things out very clearly, I’m not going to say that’s going to work in every situation, but it has given us a lot of opportunity for people to understand because it follows processes that they’re already familiar with. And it follows language that they’re already familiar with. So again, just some suggestions. Unfortunately, with digital accessibility, even within procurement, there’s not a one-size-fits-all solution to everything. But those are just some ways you can explain why you’re holding up the process and why it’s important.
JENA WALLACE: Yeah. I love that. So that’s a great segue to our next questions. We do have an attendee wondering how large your team is. And secondly, are there any tips for how teams can stay up-to-date with the constantly evolving accessibility standards and guidelines? It seems like WCAG is always formulating some updates or proposing updates or you’re waiting on updates. So how can people keep up to speed with that?
KIM HODGES: Absolutely. So my team is– so for the first two and a half years at the university, the digital accessibility team was one person, me. I, just in April of this year, had the opportunity to hire two additional people. So now we have a team of three people.
So with me saying all of this, we don’t have a large team. So it’s challenging in that respect. But also, because we do have a small team and we have limited resources, it really pushes us to be creative in how we engage, how we interact. And that’s where, again, that relationship building really becomes very, very important because as I’ve established relationships throughout the university, I might only have an official team of three, but now I’ve gotten people on my side. And I’ve gotten people on my team without officially being on my team. And that has helped a lot, especially with moving the needle on compliance, especially within in an organization as large as a state university.
So the second part of that question, can you repeat it? Because I remember part of it but not all of it.
JENA WALLACE: Oh, for sure. Sorry, it was kind of loaded. But just it’s around how teams can stay up-to-date with the constantly evolving web accessibility regulations and guidelines.
KIM HODGES: Absolutely. And that definitely is a challenge. I’m very lucky. I’ve maintained my membership with W3C. So I actually sit on a couple of the different working groups, like Silver, and some of the different ones that are involved with WCAG. But that is an organization that can be really helpful to be involved with directly, not just in a tertiary sense in terms of paying attention to the website changes. I mean, we’re looking at 2.2 has gone through multiple different iterations and public comment.
And so I definitely get the frustration around how do you keep up with all of that. I do find that getting involved with different groups can help, whether it’s W3C directly, or LinkedIn has a lot of different ally groups that pay a lot of attention to this and stay very active with the changes that can happen. And that’s what is great about the digital accessibility community, in general, is everybody wants to help each other.
I mean, it’s even like doing webinars with 3Play and a lot of the other organizations that are very actively involved in accessibility level access, Deque, there’s quite a few that are out there. But getting involved in those different groups, the ally groups. If you can even set up some resource groups within, like employee resource groups within your own organization that’s specific to ally and the different disability and DEI groups, that can be really helpful because then you’ve got multiple people that are engaging with, what are the different challenges?
What are the regulations? How are those changing? How does that apply to the work in the field that we’re in? And that would be my suggestion for trying to keep your team engaged with the ever-changing landscape. But it also helps to create a more diverse network, as well, of professionals and people that are very involved in this.
JENA WALLACE: Yeah, that’s definitely a common theme I’ve heard from other speakers and other webinars that we’ve done, having those ally resource groups and people who are really focused and doing the work in digital accessibility, sharing resources and sharing experience together. Definitely a common theme I hear.
So along the same lines, but related, what role does leadership buy-in and advocacy play in successfully building accessibility into a procurement process? I guess this was sort of answered, but thinking about the leaders and the stakeholders that you have to make a case to. How do you get them to buy in?
KIM HODGES: Oh, yeah. I would say that’s probably the biggest hurdle. And that’s not just on procurement. That’s just in general, is how do you get leadership buy-in? How do you get stakeholder buy-in? There’s a lot of different tips and tricks to doing that. There’s a lot of different approaches. I have a tendency to go very much into the, how do we make this as personal to the people as possible?
I will say that through conversations and discussions– and this can be challenging because we don’t always necessarily get that kind of face time with the stakeholders that are involved, where we can have those kinds of conversations. But that, again, it all ties back to that relationship building is, how can you do that?
Working in a university environment, one of the most elusive meetings that you can try to get is with a dean, trying to get time with a dean or talk to a dean. But what I’ve really found is, instead of approaching accessibility from a standpoint of have to meet this, it’s a requirement, it’s the law, while all those things are very true, it’s very easy for individuals to be, like, yeah, yeah, yeah, and be very dismissive of it.
If you approach accessibility, though, from a standpoint of this is how accessibility can help you. These are the benefits to it. This is what it can do for you in terms of usability, student engagement in a university environment. But also, even if you’re outside of that kind of an environment, there are a lot of good use cases for how digital accessibility is a benefit versus a hindrance or some kind of added work that we have to do.
That’s how I generally like to approach it is digital accessibility more as a service, as opposed to as some kind of a regulation or compliance piece. If we offer it more like a service, people are a lot more likely to engage with it because they feel like they’re getting something out of their investment. And with stakeholders, that can also be very beneficial because they feel like they’re getting this added thing as part of this process that is helping them not only have a better product or a better outcome, but also allows them to meet legal requirements as well. And again, I could talk about just that particular piece for an hour or so.
JENA WALLACE: Oh, for sure. That’s a whole other rabbit hole in itself. So before we move on to VPATs, we do have a couple of attendee questions that are relevant to this topic of conversations. Someone is curious where your team resides. So is it IT or is it something else?
KIM HODGES: So at the university, we are in IT. We’re actually part of the risk management group. I will say– and I said this early on– I’ve worked with over 25 universities in my career. I’ve seen digital accessibility live all sorts of places. I’ve seen it live in marketing. I’ve seen it live in communications. I’ve seen it live in different offices of civil rights.
So sometimes it’s partnered with whatever the Student Disability Resource Center is, which each university has a different name for it. But I’ve seen it under student affairs. One of the reasons we live within the risk management portion of IT is, basically, because when digital accessibility was brought up as something that needed to happen at the university, they were the ones who stepped up and said, OK, we’ll do this. And we’ll find someone that can help us build this department. That’s the only reason that I live there.
I will say, there are some advantages to that. I, actually, was just having a conversation about this the other day is when we’re engaging with people where we’re trying to get them to meet certain standards, it’s very helpful if we’re kind of separate from them, if we’re part of a division that is not directly underneath them. An example being is it’s very hard to implement certain things within areas at the university, like communications, if that person is also my boss that I’m trying to instill this risk management platform with them. But that’s where we live at the university. And I do realize that that’s not necessarily the most common place for digital accessibility to live.
JENA WALLACE: No, it’s definitely an interesting question because I’ve also noticed that accessibility tends to live all sorts of places. So it’s interesting to see where it seems to work better and where it doesn’t. So one more attendee question before we move on to VPATs. What role, if any, does your legal department play in crafting the final procurement documents? For example, is there language in those final agreements that holds the vendor to a time frame, to cure accessibility bugs, et cetera?
KIM HODGES: Yes. So I’m going to give you as short of an answer to that as possible without going into a lengthy– ours is somewhat on a case by case basis. So depending on what it is, yes, there is language. There is always language that reinforces the need for accessibility. An example being at the university, we have an IT policy that is specifically about digital accessibility. All of the contract language says that, by the vendor agreeing, that they are agreeing to adhere to that IT policy. That’s kind of the general, vague way that we hold them responsible.
But when it’s a situation where we have engaged with the vendor, there are expectations that they’re going to meet certain compliance criteria within a certain time, then, yes. Usually what happens is I’m involved in having conversations with our legal team on how to make sure that we’re covering ourselves so they can craft it in terms of what the exact language says from a legal standpoint. But I’m basically telling them how that all needs to be communicated, and then they draft that. And that usually becomes a part of it.
I will say, you do run into issues sometimes where vendors want you to sign their contracts, and they are not willing to adjust their terms of service. That becomes a bit more of a challenge. And that is definitely where it’s very valuable to have a good relationship with your legal team because you can help them navigate those terms of service and whether or not they are taking any responsibility for the digital accessibility aspect of their product or not. And if they’re not, how do we cover ourselves from a legal perspective in those instances? But those do tend to be a little more rare, and they’re usually behemoth companies that you’re engaging with when they’re not willing to do that.
JENA WALLACE: Yeah, that’s interesting. So moving on to VPATs which, again, for those who might not know in attendance today, VPAT stands for Voluntary Product Accessibility Template. So again, just for those who may not be as familiar with the term or familiar with VPATs, in general, what are they, and why are they important in the context of digital accessibility?
KIM HODGES: Yes. OK. So I’m going to try and say all of this with as straight a face as possible because I have certain feelings about VPATs. So VPATs, in and of themselves, are not good or bad. They are a tool. The general purpose behind a VPAT is a way to document the different aspects of accessibility.
And there are three different formats, generally, that you can get a VPAT in. There’s usually a Section 508 specific VPAT. There is a WCAG specific VPAT. And then there’s an international one that includes multiple different requirements, usually like the EM 301 accessibility requirements, as well as Section 508, and WCAG.
It goes through each section, what we generally have a tendency to call the poor, perceivable, operable, understandable, robust. Breaks down all of the different success criteria. And then you have an opportunity to say whether you support it, whether you partially support it, whether you support it with exceptions, whether you don’t support it, and not applicable. And then there’s a Notes section.
Actually, am I able to share my screen? Is that a possibility? I have an example of one pulled up right now that I could show you.
JENA WALLACE: Yeah. I believe you should be able to. We do have tech support on the back-end who might be able to make that possible.
KIM HODGES: Let me see if– I’m going to try and do that because it would be much easier if I just walked you through one. Oh. Yeah, it won’t let me do it. I would have to shut down Zoom and restart it to be able to do it.
But for those of you who haven’t seen a VPAT before, it asks you for what the name of the product is, what the description of the product is, what date does the conformance report apply to. It wants contact information, notes. Another important piece of it is the evaluation method. So I’m going to start there, if that’s all right.
So when you dive into it, one of the important pieces is if you’re getting a VPAT from a vendor, some important things to pay attention to are, one, is make sure that the VPAT is for the actual product that you’re trying to procure. Because in my career, I have in many, many instances gotten VPATs from the vendor that are not for the exact product that we’re– yes, thank you, Casey, for linking to the VPAT. And actually, that’s one of the examples that I have pulled up is that exact one from level access.
So when we’re looking at that, I generally want to make sure that the product name is correct, and that the date is reasonable. So when I say reasonable, I mean that the VPAT isn’t five or six years old. I have gotten VPATs that were from 2016.
There’s a lot of reasons you want to make sure they are as current as possible, especially when we’re talking about software. I generally want the VPAT to be based on whatever the most recent release of that particular piece of software is. Sometimes, that’s not possible, but you want to keep it as close to the current version as possible.
If you have an organization that sends you a VPAT that’s five years old, to me, that says one of two things. Either they haven’t made any changes to their software in five years, which makes me question why I would want to purchase that. But then the second piece is, if they have made changes, that they haven’t been keeping accessibility as part of their development cycle, and as part of the checks that they should be doing. So those are things you want to pay attention to.
And then evaluation method is another one that you really want to pay attention to. You want to make sure that they are documenting what tools they’re using to evaluate, what the process was, what actual standard they’re using. And I think a lot of this isn’t necessarily because vendors are trying to be dishonest or because they’re trying to mislead you. I think it’s because, for a lot of individual organizations, and especially when we’re talking about smaller software companies, this is a relatively new thing for them. It shouldn’t be, but it is. And so they’re just trying to do their best to meet this thing that you asked for.
Like an example being is if I get a VPAT where the only thing that they put on there is that they tested with a Chrome browser extension, generally, that’s not sufficient for me. So I want more than that. That’s not going to be adequate for me to evaluate the VPAT.
And usually, I don’t even get into the VPAT at that point. If I see the evaluation method is something like that where it’s just a Chrome browser extension that they’ve used, like WAVE or something like that, that’s not adequate to really get a sense of what their accessibility is and for me to be able to validate that. So I usually don’t move past that. I go back to them and say, we need a little bit more than that.
But then there’s also things to pay attention to. Even if their evaluation methods make sense, when you get into the VPAT itself, there are things you want to pay attention to that are red flags. One is, if everything that is listed on there they say “supports” everything, that’s a red flag. Because I, still to this day, don’t think I’ve ever met a software in that kind of an environment where they support every single success criteria on there. It’s just not realistic. So that’s one that can be a red flag.
Another one is if they say “not applicable” for the majority of things, especially if you know what this piece of software or whatever this product does. An example being is if they say they don’t support captions, but you know for a fact that video and audio are parts of that platform, and they say that that’s not applicable, you know that’s not true. So that’s another piece to pay attention to.
Another one is if they will say supports or supports with exceptions or some of those different areas, but they don’t fill out any notes. Because there are notes at the end of the VPAT in a grid. And you want to make sure that the notes make sense for the success criteria that it’s listed under. If they don’t have any notes, or the notes are very one line and vague, or you can see where they’ve, basically, been copying and pasting the same thing throughout the VPAT in the Notes section, those are other red flags.
So, again, I could talk about just this particular topic forever. But what I’ll segue into is if you do see red flags, what do you do? Because that’s the next step is, if you notice red flags, what do you do? I usually try to open some kind of a dialogue with the vendor. Try to get a little bit more information.
One of the first things I ever ask is, who did your assessment? Who did that accessibility review for you? Was it someone in-house? Was it the third-party vendor that you had come in, someone like Level Access, or one of the other consulting firms that’ll do that kind of stuff? That’s one of the first questions that I ask. And then we go from there.
So if it was done in-house by one of their development team members or one of their UI/UX team members, then I usually want to know what level of experience that person has with that kind of stuff. And then I will usually, from that point, ask for them to actually send me a report, not a VPAT. If they’re using automated software tools, like axe or WAVE or something like that, generally speaking, they should be creating their own internal reports. So I usually want a copy of that report.
Those are generally the next steps that I take. I will say, in my career at the University of South Carolina, I’ve only ran into one instance where a vendor was not willing to give me any of that, where they weren’t willing to give me an up-to-date VPAT. They weren’t willing to give me any kind of testing reports. They weren’t willing to give me any information about how they were testing. I’ve only ran into that once.
Generally speaking, vendors want your business. So they are going to try to meet whatever requirements and whatever conversation you have. And I will say, I’ve been lucky enough that most vendors are willing to work with you if they don’t meet everything.
But generally speaking, it’s not a good sign if you start noticing that they’re not being very truthful as part of their VPAT. And you usually have to find out why that is. Is it just a general lack of understanding? Or are they trying to actually deceive you in some way? But again, I could talk about that stuff forever, so I’ll leave it at that for the time being.
JENA WALLACE: Yeah. We do actually have a ton of attendee questions that are trickling in that are very relatable. But I think it’s great that you try to first work with the vendor. But I also feel in situations where they’re not being forthcoming with the information, and they’re just pushing back, they probably aren’t going to be the right vendor.
KIM HODGES: I agree.
JENA WALLACE: But I think It’s always good. Sometimes, you only know what you know. So it’s always great when they’re willing to learn. But if they’re not, then I feel like that’s probably a good sign that they’re not the right one for you.
KIM HODGES: Absolutely. Well, and just to piggyback off of that a little bit, too. I always think of, if they’re being dishonest or purposely deceitful in their representation of their compliance with digital accessibility, what other things are they not being forthcoming about? When we talk about security, do they have a SOC 2? Is their HECVAT up-to-date? So you start really digging into them as a whole. And does all of this information line up? Does all of this stuff stack up? And I agree with you in that sentiment.
Generally speaking, my recommendation, if I can tell that they’ve just not taken the VPAT seriously, they’ve been misrepresenting themselves within the VPAT, usually my recommendation without going any further, is that maybe we should pick a different vendor for this particular product. But there are some instances where we have to try to work with them for whatever reason.
JENA WALLACE: Yeah, definitely. OK. I want to try and dive in and get through as many of these questions, because they’re really good questions. So if a vendor submits a VPAT for WCAG 2.0 level AA, rather than the current WCAG 2.1 level AA, do you find that to be a concern? Since 2.1 has been current since 2018, is this a red flag that they’re not making progress with their program?
KIM HODGES: Yes. So again, this is where context can become very important, also knowing what updates happened from 2.0 to 2.1, and whether those updates are actually going to impact. Because I’ve engaged with vendors before, and they’ve expressly said the reason that they didn’t go to 2.1 and they kept with 2.0 was because the 2.1 changes didn’t really impact their product. The thing is, sometimes that’s true, and sometimes it’s not. So that’s where it gets a little bit tricky.
I think, from my perspective, that’s why it’s better to just state that you want them to adhere to whatever the current version of that guideline is. So I go back to vendors all the time and will say the same thing you said in your question, that 2.1 is not new. It’s been around since 2018.
It’s the same with the current VPAT version. Version 2.4 is not super duper new. It didn’t just come out in May of this year. It’s been around for a little while. But yeah, generally speaking for me, that is maybe not a red flag, but an orange flag, in the sense that I need reasons why they’re still only using 2.0. And to your point, that generally means that they’re not keeping up on what the current accessibility landscape is like. And that can be a concern, depending on what that particular product is, and what the a use for that is.
JENA WALLACE: Yeah, definitely something worth digging further into, rather than just leaving there. Our next question, what kind of digital products require a VPAT, and what kind of industries ask for them?
KIM HODGES: Oh, man. That’s a, I’m sure, an unintentionally very large question. So generally speaking– and, again, this is something else where there’s a lot of “it depends” statements here with this. But I do know industries that ask for it are banking industry. Anything that requires any kind of state or federal funding will almost always ask for VPATs. So that can be anything from education to different departments, whether it’s Department of Treasury, Department of Finance, any of that kind of stuff. Generally, anything that has any kind of governmental regulation included within it, which is one of the reasons why something like finance will ask for them.
But VPATs have really caught on. So even organizations that aren’t adhering to state or federal standards within how they get their funding are also starting to ask for these a lot more. And one of the reasons being is because it’s kind of become the accepted template for this. So even if a VPAT doesn’t necessarily apply to the particular industry, people are still asking for it and using it.
So in terms of what does the VPAT apply to, so realistically, the VPAT only applies to things that WCAG would apply to or Section 508 would apply to. So there are instances and pieces of software where a VPAT really doesn’t apply. I have that as part of– I wouldn’t say it happens a lot, but it does happen. And the reason it doesn’t happen a lot is because most stuff now is either cloud-based, or there’s some kind of component that ties into it living in some kind of web-based environment, whether it’s a web platform, or a cloud platform, or something like that.
But there still are instances, like an example being we had something come through that was a piece of internal software that was designed specifically for our student medical center. It had no online feature or anything like that. It was all in-house. In that particular instance, a VPAT isn’t really going to be all that helpful for that. But then we’re also talking about you have to get into how does digital accessibility apply to very niche field products and things like that. So that’s where you get into the weeds a bit, and that’s where we’re having conversations with vendors.
Because I will say, in a lot of those instances, when I talk to a vendor, a vendor is shocked that I’m even asking about digital accessibility and will make statements like we’ve never been asked this before. And to me, that’s sad. But the reality of it is when you’re talking about certain types of medical software or internal hard desktop-specific pieces of software, digital accessibility is still something that can kind of be overlooked. So that’s where having those independent conversations can become very important.
JENA WALLACE: Yeah, definitely. And a question that goes along with this last one, to piggyback, what do you do when the vendor looks to you to educate them on accessibility? This is difficult for small teams to train a vendor on an industry standard. So do you have any strategies for that, any tips?
KIM HODGES: Yeah. And also, coming from we only have three people on my team, so I definitely can relate to that. And you do have to balance resource management as part of that. I’m generally not in a position where I can dedicate my team to working directly with a vendor for any length of time. That’s usually when I will encourage them to look into other vendors that are out there, like Level Access, Deque, TPGi. If they’re looking for specific services, there are organizations like 3Play Media, and other ones that can help them with certain aspects of their business in terms of meeting certain compliance criteria. That’s one of the ways I will go about it.
I also will frequently just send them resources. Things like WebAIM has some great resource material. Deque University has some great resource material. Just the things that we use internally to help educate, sometimes, I will just give them that resource material. But yeah, it is a delicate balance because as much as I want to help any of the independent vendors with their accessibility, I’m limited by the size of my team and the bandwidth that we have for that kind of work.
And in the instances where we have been able to help, it was kind of like a perfect storm of allotments of time that we were able to do that. And I hate to say it this way, but it also depends on what the priority for that particular piece of software is. Like, how important is this, the organization as a whole? If this is an enterprise-wide procurement that’s happening, and this is something that everybody’s going to be using, and it’s going to help everybody’s lives, that might get something that gets bumped to the top of the list where I’m pulling my people off of other stuff to help with this.
So again, it’s that balancing act of, how important is this? What’s the priority? What’s the stakeholder involvement in this? Is this something the president of the university is pushing for? Because if it is, that changes everything. So it’s just different things like that that you have to weigh.
JENA WALLACE: Yeah. So unfortunately, I think we only have time for one more question. So I’ll end with, what strategies do you use to implement programs that are not fully accessible in your program? Do you focus on individual accommodations for people that may need to access it, or do you explore secondary systems? We run into issues where the programs we need may not be accessible but are really needed for different programs. I know that was a multi-part question. I can repeat.
KIM HODGES: No, no, I get it because we run into the same thing. So I have this whole system that I’ve developed, which is called our risk management liability matrix. And generally, what I do is I look at that. What’s the intended audience of this particular product? What’s our liability from a public-facing standpoint? Is this student based? Is it staff based? Is it faculty based? How many people are going to be using it? Which this is all stuff that’s usually involved in the RFP questions. What’s the intended audience? How many users do we anticipate?
So based on that, yes, we will take alternative methods. So if this is a piece of software that’s going to be used by five security staff in a very controlled environment, then even though it might not meet all of our accessibility needs, it’s a situation where if we do have individual accommodations that are needed, we can very easily accommodate those. So that is one method that we use depending on how those questions are answered.
And then there also is using alternate– an example being is our university has multiple different form-specific, like Formstack, Dynamic Forms, Jotforms, and things like that. And all of them have varying degrees of accessibility depending on what you’re doing. So depending on what is being used at the time, we do have a tendency to push people towards what is the more accessible version of that.
And I wish this wasn’t an answer that I could give, but sometimes we don’t know what to do, and we have to come up with creative solutions. And we have to work with team members to talk about this and what is the specific need. If it’s not completely– and I hate using the word “completely accessible” because that’s not really a thing. But if it’s not completely compliant, is it accessible enough in a practical sense? So this doesn’t check all of the WCAG boxes, but can a user, in general, interact with this in a way that they can at least use it for the purpose that it’s intended on their team?
And yeah, there’s a lot of involvement in that. And I do wish we were in a world where there were simple solutions, and I could just say yes or no to specific pieces of software. But like you pointed out, sometimes, that’s not plausible, especially if you’re looking at single-source purchases. That becomes real complex complicated from an accessibility standpoint.
JENA WALLACE: Sure. So sadly, that’s all the time that we have for today. I know we could keep talking about VPATs and procurement all day. But thank you, Kim, for the wonderful discussion, for answering all of these great attendee questions today. And thank you to everyone for joining us today and asking some really wonderful questions. Thanks so much again, everyone. And I hope you have a great rest of your day.