« Return to video

The Forest and the Trees: Scaling for Enterprise-Level Digital Accessibility [TRANSCRIPT]

SAMANTHA SAULD: Thanks for joining the webinar entitled The Forest and the Trees– Scaling for Enterprise-Level Digital Accessibility. I’m Samantha Sauld from 3PlayMedia, and I’ll be moderating today. I’m joined today by Kathryn Weber-Hottleman, who serves as the University of Connecticut’s IT Accessibility Coordinator. She monitors university compliance and provides guidance to campus departments in integrating accessible technology into the classroom and workplace environments. And with that, I’ll hand it off to Kathryn, who has a wonderful presentation prepared for you.

KATHRYN WEBER-HOTTLEMAN: All right, everybody. Thank you so much for coming to this presentation. And let’s get started. So we’re going to be talking about the narrow practical how-tos and the broad organizational plan for a digital accessibility program.

So introduction– you’ve already heard a little bit about me. I’m the IT Accessibility Coordinator for the University of Connecticut. We’re going to have a little bit of background on why digital accessibility is so important. We’ll get into how to design an ICT, so an Information and Communication Technology accessibility plan. And we’ll talk there about accessibility testing and stakeholders. And then, finally, there will be some takeaways.

So we’ve seen an increase in technology in daily life, which, of course, means that we need accessibility regulations. We have some civil rights laws, like the Americans with Disabilities Act and Section 504 and 508 of the Rehabilitation Act, that help to govern what digital accessibility looks like. This is particularly important because in January of 2018, we had a refresh to Section 508. And now federal government agencies are held to the Web Content Accessibility Guidelines 2.0. And I believe they’re held to AAA standards.

We have also seen a lot of case precedent in the last few years through Dear Colleague Letters and some cases that have been handed down, like UC Berkeley in 2016, Harvard and MIT and the Miami University of Ohio, all in 2016. And there have been a lot of OCR complaints that have had resolution agreements too in the last few years. That combined with Dear Colleague Letters in 2010 and 2011 have really helped shape the expectations for higher education in terms of digital accessibility.

So the most important thing when we’re talking about accessibility is to have a proactive plan. So this means whether OCR has already come to your door or not, you want to be taking a look at what your current accessibility levels are, how to take care of any issues that you might have found, and looking at how you can position for future accessibility.

And that includes things like wrapping accessibility into the procurement process, getting the word out about ICT accessibility, working with template designers so that out of the box templates are accessible, and working with different departments, designers, and developers on remediation so that accessibility is actually getting wrapped into their redesign process.

So to talk about evaluating current accessibility issues, one of the first things that we want to look at is what your internal guidance looks like. And that typically takes the form of some kind of digital accessibility policy. So policies have a few different characteristics. Of course, we want them to be enforceable and achievable. But we really want them to be well supported with best practices, tutorials, and other similar supports. At UConn, we have something called the Universal Website Accessibility Policy, which we’re currently working on updating so that it’s expanded to cover all ICT, not just websites.

We also have a policy for providing information in alternative formats and a policy against discrimination, harassment, and related interpersonal violence. So these policies coming together kind of help support the idea that we want to make all of our information available to the broadest user base possible. And that, of course, includes users with disabilities. And then to support these policies, we have some best practices, like marketing best practices and social media best practices, which have been adapted from Ward and Ashe in 2017. And I’m happy to share more information about that at the end if you would like.

So we want our policy to be well defined. That’s why we’re in the process of updating it right now. As with other organizations, other higher education institutions, we also hold ourselves to the WCAG 2.0 AA standards. And we just want that to be in our policy so it’s more enforceable. And then it is integrated with some of our other policies, as I mentioned, and other organizational best practices.

And we’ve taken a look at a lot of institutions around the country. A great example of someone who’s doing a really good policy is the University of Missouri. They have an IT accessibility policy and guidelines, which we’re using as kind of our model for our updated policy.

So then after we’ve talked about internal guidance, we want to talk about how we actually assess where we have issues with that, with compliance with the policy and with compliance with WCAG. So the first thing we want to do is assess our digital holdings and see where we need to remediate issues. So there’s a few different areas for testing– newly created websites, obviously, because they’re being put into production and launched daily.

At UConn, we have a Go Live forum with questions that specifically target accessibility and reminds the developers about the Universal Website Accessibility Policy and their responsibilities under that. We also have some template accessibility features that are built into our content management. So we have Aurora, which is UConn’s instance of WordPress. And one of the features is that, for example, it’ll gray out images that don’t have alternative tags, clearly marking it as inaccessible.

Another area for testing is existing websites. They were originally created based on a variety of different standards. There was a lot of freedom to modify templates as the developer saw fit. And there’s a lot of websites. So what we’re trying to do is bring them all under the same standard, which for us is WCAG 2.0 AA. So it’s been an interesting journey looking at just the variety of websites that we have and seeing how we can all get them to this common accessibility standard.

And then a final area for testing is non-website information and communication technology. That’s often through a third party vendor. And we kind of want to look at their contracts and see where we can be building accessibility into those contracts. And we’ll talk about that later in the presentation when we get to the procurement section.

But for right now, our rule of thumb is that campus wide products must have accessibility considered during the RFP process, while programs that are used by maybe one or two individuals should be considering accessibility, just in case some broader user base wants to use whatever product they’re considering.

All right. So then we get into things like prioritization. So we prioritize based on the number of users, audience direction, the transactional nature of the website, and traffic from students with disabilities. So number of users, that’s really high traffic sites, like UConn’s athletic site. Audience direction is high traffic from outside of our UConn community, like our Center for the Performing Arts.

A transactional site is where patrons contract business, like ticketing systems. And then used regularly by students with disabilities, that might be something like RMI Access Portal, which is where students can upload documentation and request their letters for their professors.

Just because we have so many websites, and we’re always getting new ones, the accessibility testing schedule refreshes regularly. So new sites that are meeting multiple criteria might trump older sites that are only meeting one criteria. And we review when we can during the update process. So if a site’s being remediated currently, or if it’s being updated currently, we’ll try to review once it’s in production, but before it’s actually launched. So that can also cause the testing schedule to move around quite a bit.

And then examples of a high priority site– so our athletics site is a very high priority because it has thousands of views. And it’s a transactional site. Another high priority site is our Center for Students with Disabilities site because it’s used by all of our students who have disabilities. An example of a low priority site is a site that’s set up, maybe, for one semester by a graduate student just to show research. It’s unlikely to be highly trafficked. And it won’t be maintained after the semester.

So in our prioritization, that’s considered a Tier 3. It’ll be assessed eventually. But it’s not a pressing need. And in the meantime, we can recommend that the site is set to private after the semester. And we do provide training to all developers and designers of the sites. If a specific site is brought to my attention, whether it’s considered high priority or not, it automatically becomes a higher priority and moves up in the testing schedule.

One of the tricky things is that I’m the only one who’s doing testing right now. And the majority of my testing is manual. So we’re working to scale the assessment process by training others on accessibility audit methodology so that others can do high level reviews. We’re also developing checklists for faculty and staff and checklists for student workers so that others can be taking a first pass at assessing a site’s accessibility. And then I can do a much more in-depth review as time allows.

And also work to discuss global changes with developers and designers so that accessibility changes can be implemented from the top down, affecting all templated sites. And then I discuss site accessibility with developers and designers as the site is actually in production. And as sites are created or as they’re remediated, the content variant is remediated. And they’re made accessible going forward.

So assessment tools– there are a lot of different automated checkers that are out there, some of which include the WAVE plugin by WebAIM. There are also some Chrome plugins that you can use to check accessibility. The important thing to remember about automated checkers is that they unearth general issues on sites. They’ll touch the surface of compliance testing. But they don’t actually get at some of the in-depth coded issues. So they always have to be supplemented by manual testing at this point.

There are a lot of different methods for manual testing. Some of them included the Trusted Tester Program, WebAIM’s accessibility training, and the DRES IT Badging Program. That stands for Disability Resources and Educational Services IT Accessibility Badging Program. And that’s out of the University of Illinois at Urbana-Champaign.

And then some other testing tools include screen readers like NVDA or JAWS. You have to be careful using those for your primary testing tool, though, because some programs like JAWS are structured in a way that they rework their code, the code of the website, into its most accessible format. This means that they can frequently reconfigure digital content that’s not accessible by design and read it as though it was accessible. So because of that, they’re not accurate indicators of a site’s accessibility.

So my general rule of thumb when I’m talking with designers about things– about compliance issues that I found on their sites is that we should be designing sites in such a way that somebody using a public computer and a free screen reader for the first time can easily navigate the site. And that’s just thinking about users who might be in public libraries going on our site or somebody who’s borrowing somebody else’s device to access one of our sites. We really want it to be as user friendly, as good of a user experience as possible, for any user, including users with disabilities.

So I’m going to talk a little bit more about the Trusted Tester Method just because this is the method that I happen to use when I’m doing my testing. So it uses a few different tools, all of which are free. So they’re available to everybody. There’s a definite learning curve with these tools. They’re not necessarily easy to use. So I would recommend, if you want to use them, going through a program like the Trusted Tester program. And that’s through the Department of Homeland Security.

Currently, they’re in the process of updating the system and the methodology. So this slide, I’m sure, will shortly be out of date. But for the time being, we use the Web Accessibility Toolbar or the Accessible Name and Description Inspector, which is abbreviated as ANDI.

So WAT, the Web Accessibility Toolbar, is available through Internet Explorer. And that’s the first image that I have on this screen. So you’ll see it says Check, Resize, CSS. So that’s a little sample of what the Web Accessibility Toolbar looks like. And you can see that I have a shot of ANDI as well showing how it goes through different focusable elements on the page.

The Trusted Tester Method also uses some favelets, specifically Jim Thatcher’s favelets. That’s to examine things like ARIA and Frames. And then for examining JavaScript, Java Ferret is recommended. I find Access Bridge Explorer is a little bit easier to use. So that’s what I’ll typically turn to. And then AI Inspect to look at ARIA attributes. AI Inspect is a Windows SDK. So it’s already part of your system. You just have to enable it.

And then to supplement, I’ll use the Contrast Checker and Color Contrast Pal. Contrast Checker, I believe, is through W3C and Color Contrast Pal is also available to show you what color contrast looks like on your site. I also really like Color Contrast Analyzer by The Paciello Group.

So the assessment process– I’m going to talk about how I typically do an assessment, just to give you a sense of what it looks like when I’m going through a website. So I’ll test all the website’s pages, applications, and content. Typically, if it’s a big site, I’ll do a representative sample versus the entire website. If it’s a smaller website, I will test all of the pages. And then I generate a report using the Trusted Tester template, which goes through and shows different baselines.

And it also has space for screenshots. It tends to be a little cumbersome when you’re doing a lot of different pages because you’re generating an Excel workbook per page. So I’ve developed a template that summarizes the content a little bit better. You can see a screenshot of it below at the bottom of the page. It still has space for the standards baselines and the DHS test, so the Department of Homeland Security test.

It also shows details. So it will share the baseline, which is– or the failure condition, which is that, in this example, the contrast ratio is less than 4.5 to 1 for content background and foreground colors. And then it has information about specifically where that issue is found. There’s also space for a screenshot. I host all of my screenshots in Google Drive because it’s a little bit easier for me to share all of the screenshots and the Excel workbook through Google Drive. But you can use any kind of file sharing process to host those screenshots.

And then something I find really important is to include a solution and a rationale. So why is this important in the first place? And what’s a broad suggestion for how it can be dealt with? So in this one, the solution, very broad, just adjust the contrast to be 4.5 to 1. And the purpose is for users with low vision, this makes content perceivable. I find, personally, that it’s not very fair to ask somebody to make changes without explaining why the changes are so important or what changes– where they can start with the changes. So I always try to offer a really broad solution and a purpose for it.

I also will categorize my reports into three different sections based on responsibility. So categorizing the report results help determine what remediation can be effected in-house and what remediation needs to be addressed by web development and design staff. So at UConn, because we have Aurora, our WordPress instance, a lot of issues can only be addressed by our ITS, our Information Technology Services web development and design team.

Templates are often customized. So I break it out into template issues, which typically has to go to the Aurora team, site specific issues, so if it’s a customized template like the colors are changed, then typically, the department or the individual handling the site will be able to manage those changes. And I also break out into content issues. So that’s the responsibility of the content author.

And then sometimes, I’ll do a condensed report, depending on who the report is going to. So if I know that an office, a department, primarily is content authors, then I’ll target some low hanging fruit for them to be able to immediately make some accessibility changes.

And then I always offer to meet with the relevant staff. I’ll send them the report. But I’ll always follow it with an email right away saying, this is what I’ve found about your site. Let’s meet to discuss that. Because I also don’t think that it’s right for us to say changes need to be made and then to not offer some one-on-one support to the relevant staff who are going to have to be making these changes.

I also find it’s really important to tailor solutions to the site in question. So that’s why the solutions that I recommend are so broad because every site has a different purpose. Every site has a different goal. And that means that every site is going to have a little bit of a different solution.

All right. So now I want to talk about actually taking care of some of these compliance issues. And that involves a lot of training. And it involves a variety of different stakeholders. So the first thing I want to talk about is the IT Accessibility Coordinator. A lot of different organizations are looking for somebody right now. But because it’s such an emerging field, there isn’t a lot of consistency about what qualifications look like and what kind of background you might want your IT accessibility coordinator to have.

So I’m going to offer some suggestions for qualifications with a big caveat that a lot of this is learned on the job. As we know, it’s a constantly evolving field. So you’re always having to learn something new. I think it’s helpful for your IT accessibility coordinator to be trained through a recognized program like the Trusted Tester program or through one of the other badging programs, just because it helps with consistency of reporting. And it helps to make sure that you’re patching all of the issues that are on a site.

I also think that it’s very important for your IT Accessibility Coordinator to have a thorough understanding of ADA Sections 504 and 508, your state accessibility laws, and standards like WCAG 2.0 and WCAG 2.1 now. It also helps to have experience applying the laws, possibly in a Disability Services Office or a compliance office, like your office of institutional equity, just so that you know how laws are typically applied and what accommodations might look like.

And then I’d say not a requirement, but definitely very helpful, is to be familiar with web development and design. Just because so many of the issues that your coordinator is going to be looking at are in the actual code of a site, I find, personally, that it’s very, very helpful to have some kind of background in web development and design.

Finally, the IT Accessibility Coordinator needs a very strong sense of collaboration, but also a high level of independence. You’re likely to intersect with many departments, but primarily to work on your own. And you need independence to strategically build relationships and form your own team. So for example, I only recently was added to our web development and design team. Up until that, for the past year, I’ve been working completely on my own.

So there are a lot of responsibilities that the IT Accessibility Coordinator is going to have, like drafting and implementing your action plan for your institution’s accessibility and setting your priorities. So what’s going to get done first? What is the most pressing issue? And what issues can be set aside for a little further down the line? It’s really important to be able to have that plan and to have that vision.

Your IT Accessibility Coordinator is also likely going to be the one determining who is going to be responsible for different parts of remediation. So whether that’s saying to the web development and design team that some templates need to be updated or going to individual departments and talking to their content authors about how to update some of their content issues.

You’re also going to need to develop a system for monitoring accessibility. And it has to be sustainable and scalable. If you’re only one person, and you’re doing this like I am, then you really want to work to involve as many other people as you can and to come up with a system that’s simple enough that people can understand it and do it and that also is going to save you for looking more in depth at sites.

You’ll definitely want to develop and maintain a central resource for accessibility information. So for me, that’s the IT accessibility website. And I have training posted there so that others can learn how to take a look at their websites or their content.

And then finally, your IT Accessibility Coordinator is going to be creating a global sense of teamwork, accessibility culture that’s spreading across an entire organization so that it’s not just something that we have to do, but that it’s actually something built into the spirit of the organization. So that’s, to me, that’s working less from a standpoint of compliance, where you have to do something, and more from a place of general accessibility, so spreading information to the largest possible audience.

I also think it’s important when you’re creating an accessibility culture to give people tools that work with their current skill sets. So if you know that content authors are not going to be skilled web developers, it’s important to not give them web development tools to remediate their content. It’s very important to give them tools that match their current capacity.

And I also think it involves a lot of trusting people to make necessary changes, offering revaluations during the remediation process, but not handholding if you know that your web development and design team doesn’t need handholding. I place a high degree of trust in my web development and design team because I know that not only are they brilliant people, but they’re also very clever at coming up with solutions that meet not only the institution’s goals for websites, but also our accessibility responsibilities.

And I think in accessibility culture, there is this strong sense that we’re all on the same team working to promote this same organization. And then positive reinforcement– it doesn’t take a whole lot of time to remediate. And accessibility habits do form quickly. And then you have the opportunity to recognize the work and accessibility considerations that are already built in to the workflow.

And you’ll also get to recognize collaborations publicly. I think it’s very important for this sense of team to recognize when people are doing such a good job at building accessibility into what they’re already doing. So I actually have a section of my website that’s dedicated just to collaborations and to recognizing collaborations around campus that are working to further accessibility.

And then, finally, I like to recognize accessibility pioneers and ask them for feedback because that helps me create a process out of their experiences. So for example, we have one department that is working to caption all their archived content and to live caption lectures that are happening currently. So when they have a process for that, that will be the basis for our process for the university.

So another consideration for your IT Accessibility Coordinator, there’s a lot of different areas where that person can be situated. They could be in the Disability Services Office in Information Technology. They could be in compliance. At UConn, I happen to be housed in information Technology Services. There are a lot of pros to that organization. So I have a universal role. And this is really clearly demonstrated because UConn’s ITS serves the entire institution. It also minimizes preconceived ideas about my role, which might not be the case if I was in the Disability Services Office or the Office of Institutional Equity.

It affords me a lot of resources, both departmentally and in the form of professional development opportunities. And it gives me the chance to focus solely on ICT accessibility without the responsibility of a caseload. There are definitely some challenges, though. I currently work on my own primarily still. Even though I am part of a team, I am the only person who is doing IT accessibility.

There is a steep learning curve, both for me about Information Technology Services, and vice versa. Because this is a new position for the university, a lot of flexibility is required from our leadership and from me as we all understand what our various priorities are. So then one of my jobs is to incorporate the organization’s priorities and to adjust my timing as necessary. So something I envision for happening in my first couple of years might not be as much of a priority to the university. So it’ll get moved a little further down the line. And I might move something else up into its place.

So then there’s the question of stakeholders. To have truly universal ICT accessibility at an organization, you need support from top level leadership. This shows the priorities of the organization as a whole. And it helps infuse accessibility into the organization’s culture.

And there’s really two groups of stakeholders. So one I call the visionaries, who are shaping the organization’s direction. And the other I call the realizers, who are really the hands-on problem solvers. So the visionaries are all of your very senior staff. They’re responsible for a lot of top down decisions. And they govern policies, where your realizers enact remediation changes. They carry out the policies. They’re the people I work with on a day-to-day basis.

But they have to work together in order to achieve an accessibility culture. We need the official sanction for accessibility changes from the visionaries. But we need the concrete solutions from the realizers in order to make accessibility happen. So working together, visionaries and realizers can promote an institutional mindset where accessibility is a standard initial consideration for any information technology and communication technology.

In order for any of that to happen, though, there has to be a lot of training. I have two different trainings on my website. One is for the average content author. It’s non-technical. It focuses on quick and easy fixes. And it can be applied to things like our learning management system or to web content.

And then the IT training is very highly technical. It’s geared very much towards web developers and designers. It focuses on code and template development. So I tend to let people self-select into their trainings. If they have some knowledge of web development, I’ll let them self-select into the IT track. The rest can choose the content author track. And they’re very, very different, one focusing on code, one focusing on content.

Coming up, we have procurement training and events management training, so trying to focus on areas that have specific responsibilities regarding information and communication technology or regarding our public facing domain. So procurement training, in particular, is very in-depth and focuses on questions to ask vendors and contractors and includes a discussion of timing for introducing accessibility into the conversation with vendors.

So now I’m going to talk a little bit about procurement and how accessibility kind of gets rolled into that process. So this is still a very new process for UConn. But right now, we’re working off kind of what I like to call a heat map. So determining the cost and the number of users, whether we have student or public use, if the procured technology is going to be essential for a class or work, and if it’s transactional.

So it’s really similar to how websites are prioritized for testing. That means that enterprise level products are always going to be a top priority. And if it’s necessary for a student or a community member to engage with UConn, it’s going to be a top priority. And then things like ticketing systems are going to be prioritized over non-transactional sites. So you can already kind of hear how it’s very similar to the website testing end of things. This is just talking about when we’re actually purchasing either a service or a product that is ICT.

So there’s a lot of different stakeholders in the procurement process. Procurement, obviously, is going to be part of it. IT is also going to be a major stakeholder, as is your compliance office, your Disability Services Office, and the department that’s actually purchasing the ICT. So typically, all of these groups will have to come together and say, how are we going to serve individuals with disabilities, whether that’s the public, whether that’s our students, or our faculty and staff? And then what need is this piece of technology going to fulfill?

So why do we even involve accessibility in the procurement process? Well, for one, it alleviates the stress of remediating whatever we purchase. It can cost a lot of time and money to have to remediate something, which makes it financially responsible and time sensitive to involve accessibility from the get go. If we find out that a piece of technology is not accessible, and a student needs it for class the next day, it’s going to be very difficult to actually make that happen in a lot of cases.

that if we look at it before we even purchase the technology, then we’re saving ourselves a lot of stress and a lot of time. It also is furthering the accessibility culture, so kind of helping to bake in that idea that accessibility isn’t an add-on, and it isn’t an option. This is something that’s just part of our general workflow.

So how can we do that? Others have to be able to evaluate product accessibility on a high level. That means things like training them to read a VPAT and training people on accessibility questions to ask a vendor. It’s not something that can be done all by one person, necessarily, because that can create quite a bottleneck. So it does involve training others to critically think about accessibility and how accessibility needs and the university’s needs are going to meet each other.

And it involves recognizing the needs of users with disabilities so being able to say, what needs can I foresee users having? And how does that match up with the actual functionality of our product? And there are some limitations. It takes a lot of time to thoroughly test a product. So there can be quite the bottleneck. However, if we don’t test a product for accessibility until after purchase, we could find out that it’s inaccessible after we’ve already paid for the product.

So one of the questions is how do we work with vendors of inaccessible products? And what do we do if a product is inaccessible, but it’s still the most accessible option? So I think we talk to the vendors as much as we possibly can, whether that’s through their ticketing system or having one-on-one discussions with them, to say, here’s how we see inaccessibility happening, and here’s how we suggest that you remediate it.

And if a product really is inaccessible, but it’s the best option that we have, the most that we can do, I think, is to prepare an equally effective access plan to say what does happen? How will we work around this should the need arise?

And then positioning for the future– so as an institution, what I’m seeing at UConn is a shift towards an accessibility culture. I’m also seeing the importance of having a central resource for accessibility information. And you can see the URL for our central resource, which is the IT Accessibility Website. But really, the biggest encouragement to me is that given tools, I’m seeing the organization move swiftly to a place where all users can experience UConn.

And that’s really exciting for me to see workflows changing just a little bit to incorporate accessibility, to see one fewer template that doesn’t have a high color contrast. I feel like every day, I’m actually seeing somebody who is learning something about accessibility and making it just part of their general process. And it’s very encouraging to me, I gotta say. So I’d like to open it up now for questions if anybody has them.

SAMANTHA SAULD: Thank you so much, Kathryn. We’re getting ready to begin Q&A. OK, so the first question is, what kind of accessibility questions do your procurement people ask vendors?

KATHRYN WEBER-HOTTLEMAN: That’s a really good question. So right now, they always ask for a VPAT. And then one of the things I’m trying to get them to really ask is when we say supports with exceptions or doesn’t support, what is the vendor working to do about that to make all of their categories be supported, not supports with exceptions or not does not support. So what does the vendor’s timeline look like for remediating that accessibility issue.

SAMANTHA SAULD: Great. Thanks. The next question is, which free screen reader at a public computer do you suggest that the site designers use to test with?

KATHRYN WEBER-HOTTLEMAN: I would say either the operating system screen reader, so if you’re using Windows or Mac, I would suggest that one. I would also suggest NVDA, just because it’s a free screen reader that can easily be downloaded on any public computer.

SAMANTHA SAULD: Great. The next question is, you said that your position is fairly new. What motivated your administration to create the role and commit to accessibility culture?

KATHRYN WEBER-HOTTLEMAN: I think a lot of it was seeing that other institutions are getting hit with these lawsuits and saying, we’re such a large public institution. It really is going to be valuable for us to start considering accessibility now instead of waiting and having to scramble if we did have a complaint filed against us. So I think they’re really trying to be proactive about the whole thing. And it’s been really great to work with an administration that’s so supportive of accessibility, honestly.

SAMANTHA SAULD: Awesome. The next question is, can you clarify what a VPAT is?

KATHRYN WEBER-HOTTLEMAN: Sure. I believe it’s a Voluntary Product Accessibility Template. And that’s the old term for it. I believe it’s now called an ACR. But someone can correct me if I’m wrong about that. Basically, it’s a template that you can give to a company that produces a product or a software, a website, something like that.

And it goes through a series of accessibility criteria, things like keyboard accessibility and color contrast and animations, all things like that. And it says, does it actually meet the WCAG 2.0 standards? And it does go up to AAA. So in some cases, if we’re only holding to AA, it’s fine if it doesn’t support. But in most cases, we want it to fully support whatever the success criterium is.

SAMANTHA SAULD: Thanks. Next question is, do your provisioners insist on the newer VPATs that align with WCAG 2.0?

KATHRYN WEBER-HOTTLEMAN: I don’t know that we insist on them. I happen to like the ones that line up with WCAG 2.0 just because that’s the standard that we are going with for our websites and for our other software. So I always think it’s good just to have one set of standards for everybody, including our vendors. So I tend to like that one.

SAMANTHA SAULD: Great. My next question is, what do you consider a good department start point when building an accessibility culture? And how long should one plan to spend building that culture?

KATHRYN WEBER-HOTTLEMAN: I’m going to answer the second part of that question first. I think, depending on your organization, it can take years. I don’t think– I personally don’t foresee the end of aiming for an accessibility culture, just like I don’t see the end of looking at other civil rights issues. So I think it could take a very long time.

And I think if you have a very receptive organization, though, you could start to see changes right away. Like I’m starting to see changes right away, and I’ve only been here for about a year. So it’s been very encouraging to me. But it’s a lot of people to get that mindset into. So that’s why I don’t want people to be discouraged if it seems like it’s taking a long time.

And then a good place to start, I think it really depends on where your IT Accessibility Coordinator is located. I think that’s really going to be your starting department. So I’m seeing a lot of things come out of our web development and design team. But I think a lot of that is because I’m situated here in IT. If I was situated in the Disability Services Office, maybe I would see different effects coming out of that. Or maybe I would have to work a little harder to forge my relationship with IT so that I could see those changes.

But I think ultimately, your starting point is going to be one person, the one person who you can get to understand that accessibility isn’t an option. It’s not a choice. It’s something that we have to do so that we can spread access to as many users as possible. I think when you get one person to start with that, they’ll tell another person. They’ll tell another person after that. And you’ll start to see it spread.

SAMANTHA SAULD: Thanks. Someone wants to know, do you test software before purchase? Or do you rely on the business to work with the vendor to review the tool for accessibility?

KATHRYN WEBER-HOTTLEMAN: That’s a good question. Sometimes, I will test it ahead of time. When I can, I always try to get their VPAT. And I try to do some testing myself ahead of time. Sometimes, I don’t even know about it until after it’s purchased, especially if it’s something that not a large user group is going to be accessing. So if it’s a department purchasing just for their department, and there’s only 10 people in the department, I might not find out about it until well after it’s purchased, in which case, we work with the vendor to make it accessible or to find out what their timeline is for remediating.

SAMANTHA SAULD: Great. Thanks. The next question is, can we see the link to the IT Accessibility?

KATHRYN WEBER-HOTTLEMAN: Sure. Let me just send it back. And I think you should be able to see the link now. I’ll read it out just in case you can’t see it. It’s accessibility.its.uconn.edu.

SAMANTHA SAULD: Thanks. The next question is, we currently are using an ed tech company with some accessibility issues. When we inform them of the accessibility issues, for example, issues with reading the textbooks, using screen readers, they seem to pass the buck back to the book publishing company. Is that the normal response? Any suggestions on how to deal with this?

KATHRYN WEBER-HOTTLEMAN: Oh, that’s a tricky situation. I don’t think I’ve had that yet. Usually, I talk with the vendors and with varying degrees of receptiveness. But they’ll usually incorporate it directly into their workflow. I’d say if it’s getting passed on to the publisher, you may want to contact your publisher just as an interim solution because I’m sure that you need the textbooks right away for students. So I would probably reach out to your publisher, in the meantime, while you’re working with the ed tech company to see where exactly the responsibility lies.

SAMANTHA SAULD: Thanks. Next question is, do you have a comprehensive test on every procured resource? And does this in-depth test fall on your shoulders specifically?

KATHRYN WEBER-HOTTLEMAN: It does fall on my shoulders specifically. And that’s why we do not have one for every product quite yet. I’m hoping to at some point in the next few years. But I also know that there are so many different softwares that we purchase over time. To me, right now, the websites are the more pressing need. So I’m focused on websites right now. And then software will come in the next couple of years.

SAMANTHA SAULD: Great. The last question is, professionally, do you have experience as a web developer?

KATHRYN WEBER-HOTTLEMAN: So I didn’t actually come into this as a web developer, interestingly enough. I came into this from working in a Disability Services Office. Now, I’ve spent a lot of time using resources, like Code Academy, to develop some web development and design skills, just because I find that when I’m talking to my web development and design team, it’s helpful if we all speak the same language. Even though, sometimes, I don’t understand all of it still, at least we’re coming from a somewhat common point of being able to say, this is what CSS looks like.

And here’s how we need to change it. Or this is what your HTML looks like. And here’s how we can update it just a little bit. That’s why they still come up with so much more innovative solutions than I do, just because my background is not in web development and design. That’s not to say if you come from a different background that you can’t learn it, though. Honestly, I think it’s been one of the more valuable things that I’ve done is to learn a little bit, just an introduction to web development and design.

SAMANTHA SAULD: Someone just mentioned in the chat, for textbooks, that you can contact your Disability Services Office to find out their current process.

KATHRYN WEBER-HOTTLEMAN: Yeah, a lot of Disability Services Offices already have contact with publishers. So that’s definitely a great place to start.

SAMANTHA SAULD: Great. We do have a few more minutes if anyone else has additional questions. We’ll give a few minutes to send those in. OK, so we have a few more questions coming in. Someone asked, you mentioned a learning curve coming into your position. Do you have any recommendations for getting through this?

KATHRYN WEBER-HOTTLEMAN: I’d say, first and foremost, be patient with yourself. It can be a heavy lift. I don’t think I realized how much there was to learn in this job until I was probably a couple weeks into it and realized, there’s so much to learn about web development. There’s so much to learn about testing. And there’s so much to learn about software.

And I thought, if I expect myself to learn all of this at one time, I’m not going to learn any of it well. And I’m not going to be able to help other people. So that was a big thing for me to recognize was that I really have to be patient with myself. And I have really great leadership. I have to say, I have great leadership that was also very patient and gave me the space that I needed to learn and to kind of find my way around a new organization.

SAMANTHA SAULD: Great. Another question is, do you collaborate with others in similar position as yours?

KATHRYN WEBER-HOTTLEMAN: I do. So there’s a small, growing, but a nice community of other IT Accessibility Coordinators. And it’s really exciting to get to see. Like every time someone publishes a new policy, you send them a note, and you say, congratulations, you got this one through. It’s so exciting. And we get to meet up at conferences.

Like I met up with my counterpart at Cornell at the Accessing Higher Ground conference in November. And it was just so great to say, we are some of the only people who have this job in common and just to see what he’s doing, where his challenges are, and just see his victories, like getting a provisional policy passed, that was so exciting to all of us. So it’s a great community.

SAMANTHA SAULD: Awesome. Next question is, you mentioned the Ward and Ashe best practices. Do you have details on that resource?

KATHRYN WEBER-HOTTLEMAN: You know what, I’ll email them over to you. And if they can be distributed or posted with my slides, that would be fantastic. Right now, it’s done through a Google Dropshare, I believe.

SAMANTHA SAULD: Great. The next question is, do you assist with PDR remediation?

KATHRYN WEBER-HOTTLEMAN: I do is the very short way of answering that. I do. But I try, more than that, to teach other people how to do it, just because there’s thousands, there’s literally thousands of PDFs. And I can’t possibly cover all of them. And some of them, well, in every PDF, it’s so much easier to work on the source document than it is to actually work on the PDF itself.

So I like to teach others how to do document remediation and then PDF remediation, just because they’re more likely to have the source documents than I am. For some cases, like the library, very special cases, mostly what they’re getting is PDFs. So I’ll work with them specifically on in-depth PDF remediation. But for others, I like to point them towards our resources for document accessibility or PowerPoint accessibility.

SAMANTHA SAULD: Thanks. And our final question, do you have to deal with inaccessible online course content?

KATHRYN WEBER-HOTTLEMAN: So I do, just because it can be so much easier for us to build it accessibly in the first place than it is for us to remediate it when a student has a need. And I hate to see when someone has to scramble and gets very frustrated or overwhelmed because they suddenly have a student in their class with a disability. And they have to remake all their course materials. And I always think, oh, if we could teach them a little bit more about document accessibility and PDF accessibility ahead of time, maybe we would– maybe we wouldn’t have the same struggle or the same scramble that we do right now.

So I’m looking at it more as a symptom of a culture moving towards an accessibility mindset and saying if we can get everybody involved in this idea of an accessibility culture, it’s naturally going to extend towards our LMS content. So that’s why I do focus on it a little bit, just because, I think, if we’re going to touch on any accessibility, we might as well touch on all of it. And that includes our courses.

SAMANTHA SAULD: Great. Thank you. Thanks, everyone, for joining. And thank you to Kathryn for a great presentation.