Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Using progressive enhancement
Progressive enhancement is a way of building websites and applications.
It’s based on the idea that you should start by making your page work with just HTML, and consider everything else an extra.
This is because the only part of a page that you can rely on to work is the HTML. If the HTML fails there’s no web page, so you should consider the rest optional.
Using progressive enhancement when you build your service will automatically make your service more accessible. It will also help you meet government accessibility requirements.
Start with HTML
Don’t use any interactive elements except those you can implement with HTML5, forms and server-side processing.
And make sure your source order and document outline are logical.
This approach sets a baseline and means your site will work with practically every device and browser, including older ones. It also helps make sure your site is accessible.
You should aim to meet the parsing standards of the Web Content Accessibility Guidelines (WCAG) 2.0.
Adding the extras
To build webpages using progressive enhancement, you should consider everything except HTML an optional extra.
Add these extras only after your webpage works using only HTML:
- video and audio
- smoother and faster interactions that don’t require the user to refresh the entire page
- ways to validate data that users submit before it hits the network
- interactive charts
Avoiding accessibility barriers when adding extras
If you add an image, you must include appropriate alternative text. This is both for people with visual impairment and for when the image fails to load.
Don’t rely on styling in the CSS layer only to share information. For example:
- ‘text in bold’ isn’t enough because a blind user can’t tell the difference between bold and normal text, or a stylesheet may not load properly - so for emphasis, make sure you’re using the correct HTML tags
- ‘red items are required’ isn’t enough when you don’t have colours applied, can’t see the colours or can’t distinguish them due to colour blindness
Videos need to have subtitles, and video and audio need to have a transcript, to make them accessible for hearing impaired people.
Interactive elements need to work not only with a mouse, but also a keyboard or touch-only device like a smartphone or tablet.
Checking code is accessible
Each time you build a new feature, you’ll need to test for accessibility to make sure your website or application can be used by everyone who needs it. This includes testing with assistive technologies.
There are many situations when extra layers can fail to load or are filtered. This can happen due to:
- temporary network errors
- third party browser extensions like ad blockers
- DNS lookup failures
- overload or downtime affecting the server where the resource is found, meaning it fails to respond in time or at all
- corporate firewalls blocking, removing or altering content (large institutions like banks or government departments may use these)
- mobile network providers resampling images and altering content to speed up load times and reduce bandwidth usage
- personal firewalls or antivirus software altering or blocking content
- internet providers inserting their own code into the page that accidentally conflicts with your own
Of course, some users turn off features in their browsers deliberately - you should respect their decision and make sure they can still use your service.
Case studies and related guides
You may also find these helpful:
- Published by:
- Technology community (frontend development)
- Last update:
Guidance first published