Real talk: Secure or accessible?

3 minutes read

What happens when security requirements and accessibility compliance clash?

Security wins.

Okay, I've given away the punchline. Let me walk through some examples then.

Session timeouts

Short timeouts protect against unauthorised access on shared or unattended devices, but they screw over people with mobility or cognitive disabilities who might need longer to complete a task. WCAG doesn't mandate a specific timeout length, but it does say content shouldn't change unexpectedly or require a quick response without warning. A 15-minute logout with no warning is a problem for someone with tremors who types slowly. Or for anyone looking at seriously long forms with instructions and multiple steps that you can't complete in that 15-minute window.

CAPTCHA

Completely Automated Public Turing test to tell Computers and Humans Apart, or CAPTCHA, and similar challenges are considered security gold for blocking automated attacks. But they're a nightmare for users relying on screen readers, people with dyslexia and folks with motor disabilities. Image CAPTCHAs especially fit this bill. So we give them audio alternatives. Even those are often shit.

There's no perfect WCAG-compliant CAPTCHA that's equally secure is what I'm saying.

Password requirements

Complexity requirements sound like they make good security sense. But these complicated rules create loads of accessibility (and usability) issues. The moment you force people to use lowercase, uppercase, numbers, symbols, a minimum length, a maximum length and no dictionary words, you're making it harder for everyone, but especially for people with cognitive disabilities or dyslexia, to create and remember passwords. It also pushes people toward writing them down, which is actually less secure.

And then, once they do remember them somehow, you force them to change it because the security "best practice" is to change it every six months. And they can't use the same one or one they've used in the past. Or one that's too similar to the current one.

No, not everyone uses a password manager.

Copy-paste functionality

While on the issue of password managers, I've seen plenty a website that went out of their way to remove copy-paste functionality. I get it (maybe?) that you disable it to prevent password pasting and credential theft. But that breaks workflow for people who use said password managers. It also affects people with motor disabilities who rely on copy-paste to work efficiently.

Autocomplete

Disabling autocomplete on password fields is another one along the same lines. Yes, it sounds safer, but it conflicts with modern password manager integration and makes things harder for people with motor or cognitive disabilities. Security experts now actually say letting autocomplete work is fine if you're using HTTPS.

Rate limits

Try to login and mistype your password a few times and you'll be locked out. That's rate limiting and it's necessary to prevent brute force attacks. But if you're too aggressive, these lockouts can be brutal for people with motor disabilities who might fat-finger their password multiple times. Or anyone with cognitive disabilities who might genuinely forget their password often.

Given all these examples, you'd think accessibility would win at least in some cases. But security is often touted as paramount.

I guess it's better for people without disabilities to feel secured than for people with disabilities to use a product.

Sent on

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.