Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails. Building your service using progressive enhancement will:
- make your service more resilient
- mean your service’s most basic functionality will work and meet the core needs of the user
- improve accessibility by encouraging best practices like writing semantic markup
- help users with device or connectivity limitations to use your service
Start with HTML
Most government services should be functional using only HTML. This includes services such as:
- transactional services, for example forms that let the user provide information to government
- smart answers, such as the Registering a birth abroad service
- content-based websites, for example GOV.UK’s foreign travel advice page
Using interactive elements
You can use interactive elements, but there must be a fallback that allows for the same core functionality. For example, a dynamic autocomplete element could fall back to a
element, or something similar. This still lets the user do what they need to do, even if the interactive element fails.
You must also structure your source order and document outline logically.
This approach will give your service a strong foundation and means your site will work with most devices and browsers, including older ones. This approach also helps make sure your site is accessible, as the user will be able to access everything they need via HTML.
Adding the extras
Once you’ve built a foundation of HTML for your service, you can add things like:
- video and audio
- smoother and faster interactions that do not require the user to refresh the entire page
- ways to validate data that users submit before that data hits the network
- interactive charts
Building more complex services
Building services using progressive enhancement gives you a resilient base from which to build more complex services.
Doing this could cause problems. For example:
- parts of your service will not be accessible to disabled users
- your service may be less reliable
If neither of those are possible you’ll need to show you’ve considered how users of assistive technology can use your service. This may mean non-digital channels, such as telephone calls or in-person visits to offices.
- reliance on third-party code that your developers do not have control over
- difficulties in finding the skills required to maintain the framework, if its popularity drops
Testing your service
You’ll also need to test the performance of your frontend.
There are many situations when extra layers can fail to load or are filtered, for example:
- temporary network errors
- third-party browser extensions like ad blockers
- third-party supplier downtime, such as when using a content delivery network
- DNS lookup failures
- bugs introduced by browser updates
- corporate firewalls blocking, removing or changing content (large institutions like banks or government departments may use these)
- mobile network providers changing content to speed up load times and reduce bandwidth usage
- personal firewalls or antivirus software changing or blocking content
- the use of unsecure connections, where internet providers insert their own code into the page that accidentally conflicts with your own
Some users turn off features in their browsers deliberately. You should respect their decision and make sure those users can still use your service.
Case studies and related guides
Guidance first published