Use the arrow keys to navigate between menu items.

How to boil a frog

3 minutes read

Let me start off by saying I haven't tested this out and I wouldn't do it anyway. This is just a story that has a moral attached to it - an apalogue if you will, but I thought this was a very complicated word.

Apparently, there are two ways to boil a frog alive.

If you first boil the water and then dump the frog in the boiling pot, it will jump out. This makes sense. The frog senses the immediate danger of all that boiling water and its survival instincts kick in.

But if you put the frog in the pot first and then gradually boil the water, the frog won't jump out and will cook to death. This, at first, didn't make sense to me. Surely the frog will reach a point when the water is just too hot to handle and will still jump out. No matter, it doesn't change my point.

What do boiling frogs have to do with web accessibility?

The way most people approach accessibility is to look at and test all pages and components of key user flows on the website, using a combination of different devices, operating systems, browsers, assistive technologies and plugins. They then generate a big document with lots of details that's supposed to be used by the product team to start fixing the issues.

This is what we call an audit. It creates essentially a big laundry list of everything that's wrong with a website from an accessibility standpoint.

It is often the first point of contact that a product team has with web accessibility. They're being told that everything they've done so far is wrong in some way. They're told that what they should do now is stop everything else and work through the issues identified in the audit. And they're told that unless they change their ways, everything they will make will also be tainted by the same issues.

Naturally, they resist. They get defensive as their survival instincts kick in. "What do you mean it's all wrong?!" And, like the frog dumped in hot boiling water, they want out. "We don't have disabled users so these are not valid issues we want to address."

There is something to this frog story then. What if instead of dumping the laundry list of issues on product teams all at once, we, as professionals, would quickly show value not by criticising existing work, but by enhancing the current processes and all future work. And then slowly turn up the heat.

What if we controlled that fire knob and we could crank it up as slow or as fast as each product team could take it? Not all frogs are the same (there are apparently around 7.400 species of frogs - hey, look at that, we learned something today). And not all product teams are the same. So it makes sense to have full control over that knob.

I'm just saying...Do the audit if you want, just don't show it to anyone you think might jump when they see it.

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.