Real talk: The shortcuts worth keeping

2 minutes read

Last week, I saw someone copy a piece of code for a modal from StackOverflow.

They didn't read it. They didn't test it. They didn't ask who can use and who cannot. They didn't bother to even remove the comments that came with it. They just slapped it in their own component, refreshed their browser, clicked once and committed their work.

You know what they didn't bother to check? The accessible modal example that the component library they were using already had documented.

StackOverflow was just the first result in their web search. It was fast and it was convenient. It was easy.

It was a shortcut.

We're brilliant at taking shortcuts. We'll copy code we don't understand from strangers on the internet. We'll install packages with nine dependencies because it saves us 20 minutes.

But we won't bother with the accessible patterns that are well documented, tested and sitting right there for us. That's too much effort.

We're damn selective about our shortcuts. We trust random code from 2015 but won't spend 30 seconds making sure that code works with a keyboard.

We've got time to debate whether to use const or let. We've got time to bikeshed variable names. But using semantic HTML? Making sure it works with more than your mouse? That's not in scope.

And it's not even hard. The accessible version is often the simpler version. Semantic HTML does half the work.

Yesterday, I asked a question. Which of your shortcuts are worth keeping and which ones are you taking at someone else's expense?

Here's my answer.

The shortcuts worth keeping are those that save you time without costing someone else theirs. By all means. Copy that utility function. Use that CSS framework. Install that linter.

But if your shortcut is making life more difficult for someone else, you're not taking a shortcut. You're just being shit at your job.

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.