There seems to be a common belief among front-end developers that progressive enhancement is either old fashioned or has simply been replaced by single page applications. This is a problem of perception. We’d like to explain why we use progressive enhancement to build GOV.UK.
What is progressive enhancement?
Progressive enhancement improves resilience
As our previous GOV.UK technical architect said: “progressive enhancement is about resilience as much as it is about inclusiveness.”
Building in resilience is also known as defensive design: a system shouldn’t break wholly if a single part of it fails or isn’t supported.
We have a mandate to provide digital services to everyone in the UK and many beyond. Many users access services in different ways to the configuration tested by developers. If a person visits GOV.UK we want them to be able to complete their service or access the information they need, regardless of whether we’ve tested their configuration or not.
If you arrive on GOV.UK without web fonts support you get a base sans serif instead of our chosen web font New Transport. If GOV.UK is accessed without stylesheets (these describe how documents are presented on screens), the page’s appearance will change, but it’s still usable because we build on semantic HTML. If a user doesn’t experience style in the same way as the majority, for example if they’re using a screenreader or a Braille display, then they’ll be able to access everything they need. Even if a user turns up using Lynx or another non-graphical browser they’ll still get a completely usable experience (as you can see in the image).
- script hasn’t finished loading, or has stalled and failed to load completely
- application route is up, but the route to the Content Delivery Network is broken
- user has chosen to install a plugin that interferes with the Document Object Model (DOM)
- user has been infected with a plugin that interferes with the DOM
Thinking about users leads to progressive enhancement
It’s only natural that as front-end developers we want to flex our technical skills. We can reach new and better solutions to existing problems by pushing the limits of what a browser can do. There’s an issue with lending more of your focus to the possibilities promised by new technology though: your focus moves away from your users.
Meeting our many users’ needs is number one on our list of design principles. We can’t know every different setup a person might use while building our systems, but we can build them in a way that gives all of our users the greatest chance of success. Progressive enhancement lets us do this.
In the rapid technical evolution that’s happening in front-end development at the moment user needs are getting left behind. We feel that front-end developers owe it to themselves and their users to pick technologies that help provide a better service, rather than those that are currently trending. That isn’t always easy, but the long-term benefits are worth it.
You can follow Robin on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
Comment by Bob posted on
You should consider just using plain html, as Tim originally designed. It loads quickly, is supported by all browsers and should meet nearly all he needs of gov.uk.
I see you already stick to blank and white - you'll be really pleased to cut out the last remnants of styling.
Comment by Ryan Carson posted on
Glad to see the support for Lynx in particular!
Comment by Jason posted on
This methodology may be appropriate for a general service that should be accessible by everyone (as is the case for GOV>UK), but this doesn't mean that everybody should do the same.
We, as front-end developers, should always be on a quest to improve user interfaces and make them more exciting and engaging for the majority of our users. Which road we take depends on our user base and what other services they use.
Comment by Tim McCormack posted on
And as a user, I can tell you that "exciting and engaging" is often done at the expense of "wow, I can actually use this website". 🙂
*Every* website should start with a baseline that is accessible as described in this post. Making a website that hosts a 3-D FPS game, where the core content totally relies on JS? Well, the rest of your site doesn't. I still want to get to the contact info, about page, FAQ, login, leaderboard... In general, the parts that really need JS are the exception, and they should be built that way.
(And again, as the blog post notes, it's not just about JS -- low page weight, fallbacks when styles are disabled, etc. are important to large segments of the internet.)
Comment by Rikki posted on
Interestingly, this blog has navigation that is not progressively enhanced. Without JS, there's no way to use the right-hand navigation.
Comment by Robin Whittleton posted on
It’s like giving a demo, something will always go wrong! Thanks for the report, I’ll investigate.
Comment by John posted on
Bravo! Far too many web pages are truly horrible and it's encouraging to see GDS making a real effort to produce pages that are accessible to all. Keep up the good work; I hope to see an increase of progressive enhancement across the web.
Comment by Lee posted on
And also services should possibly be investigating adoption of Content Security Policy declarations. The last time it was mentioned on this blog was in Feb 2015.