Bleeding Hearts for Accessibility

Some asked, “Will the Internet collapse?” Now just over three weeks into the public’s awareness of the Heartbleed Bug, the collapse brought consciousness to millions about the need for increased protection. The panic has subsided, but the undercurrent of worry still persists, especially for our students who rely on technology for their academic success.

From our perspective, a network security’s focus on keeping people out seems at odds with accessibility’s focus on inclusivity. How do we address this conundrum? The most pressing issue is formulaic: an increase in number of users with disabilities and increased need for security, in tandem with rapidly innovating devices, especially mobile.

With mobile technology no longer the exception, but the ubiquitous norm, security has become more complex with its expanding environment. People could peer over your shoulder to read pertinent information, steal your phone, or hack from a distance. Chances are, you’ve seen passcodes on your phone, multi-gestured swiping lock screens, malware blockers, data protection, and I’m sure countless others that come standard in devices, or are advertised. How far ahead are devious parties?

Developers churn out new mobile products faster than the public knows how to operate the previous one. This isn’t necessarily a bad phenomenon: it is progress. Yet, combine this with a desire to lower cost for the millions that use mobile devices (and their employers who encourage BYOD), well, it’s easy to see why lapses happen.

That doesn’t excuse them.

Security software, like antivirus programs, occasionally treat assistive technologies (AT) like intruders, and shut them down. This isn’t a given, but has been known to happen. Occasionally, AT hasn’t been granted the proper permissions to exist on an operating system. One fix, at least in Microsoft’s case, this necessitates that AT cross process boundaries, and that they have access to processes that run at a higher integrity level (IL) than the antivirus software.

Others, with automatic scans, will systematically shut down programs like magnifiers or speech recognition with little warning. We’ve heard stories from some of our colleagues with disabilities that sometimes installing an update can recalibrate the entire system and cause AT to dismantle. Some assistive technologies use an external server for content processing or storage. This can be seen as a security exposure and also aborted.

Let’s move on from software to the online domain. Part of the great mobile experience, and of course still present on desktops is the CAPTCHA. You typically can’t buy concert tickets, enter an online game, or really encounter a user forum without running into those skewed letters and numbers. An often visual test, the CAPTCHA helps separate computer users from human users, but often isn’t penetrable by assistive technology. These non-textual items ideally keep out spammers, but can also keep out valid users due to their inaccessibility. Ineffective audio equivalents exist, and other workarounds are mediocre, but it begs the question: why must accessibility be sacrificed for safety? Is symbiosis that unmanageable?

Not always. One of the recommendations that was widely debated to combat Heartbleed was to change passwords. This is one area that has remained consistent with accessibility. For those who are using screen readers, passwords can be read back audibly. On face level, this seems counterproductive: why have a password announced audibly? Yet, technology has remained innovative: headphones are required if this option is selected. Certainly a progressive response.

Still, the unfortunate reality is that the majority of security processes and procedures has never taken accessibility into account. Think RSA tokens, or other tangible items that only require sight. There have been instances where a user with visual disabilities must have a sighted third party access their content and read it to them, which seems counterproductive to existing security protocols. Or, an employee is given a less secure, but more accessible option. Again, security is compromised. Some encryption keys that our colleagues have encountered have indiscriminately locked out assistive technology altogether.

So, in the aftermath of Heartbleed, it sounds like we’ve all become a little wiser about security. Already, we’ve read reports that the patch exists to fix the OpenSSL bug. Others went a bit more conservative and bought an entirely new method of security.

Take a deep breath. Let’s take pause for a second.

Being humbled by our vulnerabilities can draw attention to ones that have been rampant for years. Fool me once, shame on SSL. Fool me twice, shame on all of us. So, if you’re deliberating new security for your organization, or develop security products, factor in accessibility.

Security shouldn’t shut out everyone.

For more information on assistive technology and security, please find these following resource links:

Security Considerations for Assistive Technologies: http://msdn.microsoft.com/en-us/library/windows/desktop/ee671610%28v=vs.85%29.aspx

Blind Users and Online Security http://triton.towson.edu/~uaia/uaia/wp-content/uploads/2010/02/Accessibility-3_blind-users-and-security.doc

Assistive Technology: Principles and Applications for Communication Disorders and Special Education by Oliver Wendt, Lyle L. Lloyd, Raymond W. Quist