As colleges and universities move to the cloud, so do accessibility concerns. Here’s what you should know.

accessibility-compliance-cloudIt’s a media headache that happens once a year to a college or university that hasn’t taken the right steps, say experts. The good news is it’s preventable.

Becoming accessibility-compliant may not seem like a top priority, but with the ubiquity of technology—especially cloud technology—accessibility is an issue no institution can afford to ignore, emphasized panelists during the recent Internet2 Global Summit 2015.

“Just look at cases such as the University of Montana or Louisiana Tech: Online instructional materials and web content need to be accessible,” said Jarret Cummings, director of Policy and External Relations at EDUCAUSE. “Even EDUCAUSE isn’t exempt! When we conducted our eText pilot, we ran into issues with accessibility that the NFB [National Federation of the Blind] thankfully pointed out to us.”

EDUCAUSE has since begun working on the TEACH Act in expectation of the HEA reauthorization, and Cummings noted that accessibility in higher ed is a “significant, ongoing issue, especially as services move to the cloud. Prevention and proactive approaches are critical.”

(Next page: 3 ways to get started on accessibility compliance)

“There are free accessibility web-testing tools for those who are just getting started with online tech accessibility,” said Stephanie Robbins, program support specialist for the Assistive Technology Initiative at George Mason University. “They’re not perfect, but they’re a good jumping-off solution.”

Cummings also mentioned that EDUCAUSE has an IT accessibility constituent group, as well as an open listserv on the topic.

However, all panelists agreed that going beyond free tools is essential to becoming accessibility-compliant:

1. Hire someone with a disability to do the testing.

Cloud services and online components focus on the user perspective and personalization, said Christian Vinten-Johansen, manager of the IT Accessibility Team in Penn State’s Information Technology Services. “And there’s no better way to test if a component is accessible than by having someone who’s, say, colorblind or deaf to test out that component.”

Vinten-Johansen also noted that personalization also means going beyond just being able to use the software or program on a basic level.

“Take the example of graphing software for mathematics,” he explained. “Personalization would allow the user, regardless of the disability, to adjust the graph to different patterns or different colors. So, if someone’s colorblind, varying shades of gray could be applied.”

The problem with current accessibility modifications currently, however, is what he calls a lack of persistence.

“You have one software that can be modified to a user’s specifications, but these specifications should be able to be applied to all programs used by this person. Maybe this means that once a person logs into a profile on the institution’s system, these specifications are automatically applied for all programs,” he mused. “One app at a time is not a scalable solution for any department.”

However, Vinten-Johansen noted that it is important to keep these accessibility scaling issues in mind.

2. Work extensively with your vendors.

According to Sean O’Brien, associate program manager supporting infrastructure and platform services for Internet2’s NET+ team, vendor contracts play an important role in meeting accessibility requirements.

Moving from an in-house campus solution to a larger commercial provider can get complicated, he explained. It’s important to know whether or not the vendor has what Internet2 describes as a “community standard,” or a standard that includes language from accessibility laws within the contract.

Kara Zirkle, IT accessibility coordinator at George Mason, says language from WCAG [Web Content Accessibility Guidelines] 2.0, developed specifically for electronic and information technology accessibility, should be included in the contract.

Section 508 language is a bit outdated for the tech we use today, so incorporating WCAG 2.0 language is critical when crafting your VPAT,” she stated.

A VPAT, or Voluntary Product Accessibility Template, details how an institution and its tools or programs comply with Section 508 standards, or any other standards, such as WCAG.

Internet2 requires a VPAT with an institution for a contract with NET+, but Vinten-Johansen says it’s also a good idea to require a VPAT with vendor RFPs.

“You also want to take a trust-with-verify approach with any vendor that says it’s accessibility compliant,” he explained. “Usually cloud-based software has a fast development cycle, so a VPAT can be out of date with the new technology. It’s important to evaluate the software yourself to make sure the tech isn’t going beyond its VPAT.”

Zirkle noted that IT should also read the fine print of any application or program used, which includes software that are widely used, such as Dropbox or Adobe.

“No one wants to read the fine print before downloading, but you have to when it comes to accessibility,” she emphasized. “And that goes for all parts of the software. For example, you may expect students to use just one piece of Adobe, but since it’s on the cloud, students may use different parts of the program and those should also be compliant. We recently discovered this issue with our admin and their use of Adobe’s FormsCentral –this component is not accessibility-complaint, while other parts of Adobe are. We need to think about how to use this software moving forward.”

(Next page: #3: Looking to the future)

3. Know what’s in store for the future.

“We’re about 10 years away from general accessibility for any students with any software,” said Vinten-Johansen, “and that has a lot to do with the current in-development Global Public Inclusive Infrastructure (GPII) by Raising the Floor.”

Mobile app accessibility should also be on higher-ed’s IT radar, though mobile apps “tend to be more accessible than web or desktop versions,” said Robbins.

W3C is working on an extension to WCAG 2.0 that includes mobile apps outside the web,” said Vinten-Johansen. “Institutions will be able to use this extension and apply it to modify web policy toward mobile apps.”

As more institutions move to cloud-based technology versus campus-hosted tech, panelists said accessibility issues are usually handled in a more timely manner, since vendors have a faster development cycle. However, “it’s critical that the vendor allow your institution time to test before the next rollout,” said Zirkle.

“The risk that institutions may have in moving to the cloud comes down to broken code often associated with major upgrades and quick-to-market rollouts,” concluded Vinten-Johansen. “It’s a risk because without a beta version to test drive, you have to rely on people to report problems to you post-deployment. So be sure your department can test before rollout.”

Sign up for our newsletter

Newsletter: Innovations in K12 Education
By submitting your information, you agree to our Terms & Conditions and Privacy Policy.

Oops! We could not locate your form.

Sign up for our newsletter

Newsletter: Innovations in K12 Education
By submitting your information, you agree to our Terms & Conditions and Privacy Policy.