Learn an important accessibility lesson from Indiana Jones: when you take something in an interface away, you need to replace it with something that serves the same purpose just as well, or even better.

There’s a scene in Raiders of the Lost Ark where Indiana Jones (played by Harrison Ford) is trying to grab a fertility idol deep in an underground tomb-like structure, filled with treasure. The idol is sitting on a pressure switch that is used to protect it from being stolen. Release the pressure from the switch, and walls close in releasing deadly darts, leaving the would-be-thief full of arrows and the idol safe.

Indiana Jones, about to unleash the arrows

Jones looks at the idol, trying to guess its weight. He looks at a bag of sand in his other hand and takes a bit of sand out so that the bag (hopefully) weighs the same as the idol. With a swift hand, he removes the idol from the pressure switch and replaces it with the bag of sand. And nothing happens. No arrows. Nothing. He’s done it! He’s used the replacement principle! If you take something away, you need to replace it with something that does the same job.

Of course, Indy starts to turn to walk away, and we see that he miscalculated. The bag of sand wasn’t the correct weight. The pressure switch trips and Indy feels the pressure of the closing in walls, and is under attack from the flying arrows. He does make it — but not without all manner of chaos erupting first.

But what’s the lesson?

If you take something away from an interface and replace it with something new, it has to be a direct replacement. Approximation won’t do.

Here’s some examples to help illustrate:

Focus outline

Many web people like to take the focus outline away from a browser. Removing the outline happens in almost every reset stylesheet. This causes huge accessibility problems for sighted keyboard users — tab through the example and see for yourself. You can’t see where the focus is on the screen. Why? Because the focus outline was taken away, and it wasn’t replaced. Like in Raiders of the Lost Ark. And the arrows fly.

If you really must do something other the default focus outline in a site, please be sure you replace it with something as good or better.

Here’s a nav block that removes the default focus outline, but uses mouse :hover to show a nice little transition effect:


And here’s a nav block that has no focus outline, but uses :focus to provide something just as functional and better looking.


Notice the second one? As you tab through the page – you see the SAME visual treatment as we see on the mouse version. No flying arrows 🙂

Custom controls

We are often “required” (and I use that term very loosely) to create custom controls for a site. Form controls are a candidate because they are notoriously tricky to style. So, instead of allowing browser defaults to be browser defaults, we think that web sites need to look the same in every browser. We create custom controls.

Here’s an example from the online billing portion of our mobile phone/cable provider:

Screenshot showing a custom select dropdown box for an account selector and invoice date selector

This custom control is made up of a regular input that includes the readonly attribute, and a linked image beside it that triggers the dropdown. It “works” in the sense that when you click the down arrow, the account selector list becomes visible. You can even trigger it with a keyboard. But the similarities end there. Once it is open, you can’t use the keyboard to choose the account. We expect the down and up arrow keys to work. In a true select, we expect the ability to type in the first letter of the options in the select list. We expect a lot. And we don’t get it here. (We’ll show you how to fix these things in a future article!)

A screen reader user will not be able to change accounts very easily it all — in fact, it’d be almost impossible in its current state.

The walls close in, and the arrows fly.

What should you do?

If you feel you must take the focus outline away, replace with something just as good or better. If you’re implementing a custom control, you have to fully implement all of the functionality that the native control gives. In both cases, some people with disabilities may rely on it.

2 thoughts on “Web accessibility lessons from Indiana Jones”

Read comments

  1. Steph says:

    Good stuff here, but touch devices, which are showing super numbers for use don’t have :hover effects. What are some good solutions for touch?

    1. Hi Steph – great question… We’ll definitely cover that in a future post. There’s a lot to think about with touch enabled devices.

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.