A short guide to progressive enhancement
Every audit we run turns up some version of this. Everything we would tell a client about progressive enhancement in the time it takes to drink a coffee.
The question is rarely whether something can be built, but what it costs to keep running afterwards. Budget a little time for it every quarter and it never becomes a project of its own.
The reason this keeps coming up
Start with markup that works, then layer behaviour on top. It is worth being explicit about, because assumptions differ quietly. If it only works because one person remembers to do something, it does not work yet.
How we handle it
Scripts fail more often than people expect. The teams that handle this well are rarely the ones with the biggest budgets. If it only works because one person remembers to do something, it does not work yet.
Common failure modes
A page that degrades gracefully never fully breaks. None of that requires a large budget, only a decision and someone to own it. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
In practice
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about progressive enhancement before you move on:
- Someone can say what the current setup is without going to look
- Start with markup that works, then layer behaviour on top — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.