Skip to main content
Creating a new NHS England: Health Education England, NHS Digital and NHS England have merged. More about the merger.

Standards for web products

NHS Digital has a wide range of products and services available on the web, and through routes such as apps or embedded technologies. When building, buying, or using any web services, they must comply with some basic standards in order to be acceptable.   

These standards were developed for NHS Digital products, but are based on legal obligations for the public sector, and so apply to the wider NHS and public sector.

Purpose of standards

These standards set a minimum benchmark for all web-based services being used by NHS Digital.

This includes:

  • products developed by NHS Digital teams
  • products developed by contractors on behalf of NHS Digital
  • web services used by NHS Digital such as booking portals, jobs sites, or roadmap tools

Standards here are based on NHS Digital's legal obligations, and must be complied with.

Acceptance criteria for procurements and product sign-off are available here.

Website security

All web services must be secure HTTPS sites. They must use suitable security protocols to do this, and have an in-date security certificate.

Sites should use TLS rather than SSL protocols. Acceptable protocols are TLS 1.2 and higher only.

Do use
  • TLS 1.2
  • TLS 1.3
Do not use
  • Do not use TLS 1.1
  • Do not use TLS 1.0
  • Do not use SSL 3
  • Do not use SSL 2

All ciphers used on the security protocol must be recognised as being strong. Tools such as SSL Labs can help identify where ciphers can be improved

If users are permitted to upload any files to the web service, then server side antivirus software must be in place.  This may also be a sensible precaution when staff upload files capable of delivering malicious payloads, such as SVGs and office documents with macros.

You must also ensure that any website also has all the relevant security headers in place, to help prevent attacks such as cross site scripting.

Security headers

Security headers are important to help prevent certain types of common attack. Free tools can help you find if your site has the required headers.  You will need to decide on the values for each header based on the needs of your site, although some recommendations are included below.

The headers your site should have are:

Header Status Purpose Recommended value
Strict-Transport-Security Required Ensure HTTPS always used Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy Required Prevent cross site scripting attacks  
X-Frame-Options Required Prevent clickjacking attacks X-Frame-Options: SAMEORIGIN
X-XSS-Protection Required Prevents cross site scripting attacks X-XSS-Protection: 1; mode=block
X-Content-Type-Options Required Stops MIME sniffing X-Content-Type-Options: nosniff
Referrer-Policy Required Controls how much information is passed when navigating away Referrer-Policy: no-referrer-when-downgrade
Feature-Policy Desirable Controls which features and APIs can be used  
Expect-CT Future Determines Chrome Certificate Transparency status  


Security testing

All sites must have undergone a suitable security penetration test (pentest) before going live.

Penetration testing must be done by a CREST approved supplier or a CHECK provider in order to be recognised.

Pentests should use white box testing, also known as static application security testing. This is preferred to black box, or dynamic application security testing, as the raw code is reviewed for vulnerabilities.

When working with suppliers and providers, they may be reluctant to allow white box testing, as that would expose their code, but may be willing to share results from their own white box tests. You could also agree a third party penetration testing supplier who you can both trust, with an agreed level of detail in the results provided to you.

Other considerations for your penetration testing include testing the underlying infrastructure your application sits on.  For example, you might need to test a content management system and its technology stack itself, rather than just your instance.

Using valid HTML

We expect that all web pages will be written in valid HTML5.

This means that pages:

  • should not contain code which is no longer used (deprecated) in HTML5
  • should pass validation on the W3C validator

In particular, developers should pay particular attention to these common causes of validation failure:

  • headings to be strictly hierarchical, with H2 only appearing after H1 and so on
  • HTML specification such as language should be present on every page
  • attributes within features like tables should not include deprecated terms
Code no longer used in HTML5

When HTML5 was introducted, a number of tags and attributes were deprecated in the specification, which means they shouldn't be used any more.  In most cases, the same function should be done using the CSS, or not used at all.

Deprecated tags
Tag What the tag used to do
<acronym> Defines an acronym
<applet> Defines an applet
<basefont> Defines an base font for the page.
<big> Defines big text
<center> Defines centered text
<dir> Defines a directory list
<font> Defines text font, size, and color
<frame> Defines a frame
<frameset> Defines a set of frames
<isindex> Defines a single-line input field
<noframes> Defines a noframe section
<s> Defines strikethrough text
<strike> Defines strikethrough text
<tt> Defines teletype text
<u> Defines underlined text

There are also a number of attributes no longer in use, which are ways of changing how a tag behaves.

Deprecated attributes
Tag name Tags the attribute has been deprecated in
rev link, a
charset link and a
shape a
coords a
longdesc img and iframe
target link
nohref area
profile head
version html
name img
scheme meta
archive object
classid object
codebase object
codetype object
declare object
standby object
valuetype param
type param
axis td and t
abbr td and t
scope td
align caption, iframe, img, input, object, legend, table, hr, div, h1, h2, h3, h4, h5, h6, p, col, colgroup, tbody, td, tfoot, th, thead and tr
alink body
link body
vlink body
text body
background body
bgcolor table, tr, td, th and body
border table and object
cellpadding table
cellspacing table
char col, colgroup, tbody, td, tfoot, th, thead and tr
charoff col, colgroup, tbody, td, tfoot, th, thead and tr
clear br
compact dl, menu, ol and ul
frame table
compact dl, menu, ol and ul
frame table
frameborder iframe
hspace img and object
vspace img and object
marginheight iframe
marginwidth iframe
noshade hr

td and th

rules table
scrolling iframe
size hr
type li, ol and ul
valign col, colgroup, tbody, td, tfoot, th, thead and tr
width hr, table, td, th, col, colgroup and pre


All services must meet the AA standard of the Web Content Accessibility Guidelines version 2.1. These are created and maintained by the W3C consortium web accessibility initiative. Where possible, the AAA standard should be met.

In particular, suppliers should ensure that these common accessibility failures are addressed:

  • skip links to be in place on every page
  • all fields to have explicit labels and relationships
  • all navigation, form, and interactive elements must have ARIA labels where there aren't already semantic HTML labels
  • every page must be fully accessible using a keyboard, not just a mouse   
  • images containing text should be minimised and, where necessary, should be in SVG format
  • all images must have suitable alt-text which fully describes the image - in addition, complex images can use a clearly marked description next to or beneath the image
  • generic links such as 'see more', 'click here', and 'book now' should not be used - descriptive links should be used
  • colour contrast between backgrounds and text must meet the relevant ratio (see 'Use of colour' below)
  • consider how use of Javascript might impact the accessibility (see section below). Flash and other technologies which are not accessible should not be used.

Teams can get further guidance on how to comply with the accessibility standards on our accessibility for digital services pages.

All sites must have a valid accessibility statement which applies to the site specifically. Linking to the NHS Digital website accessibility statement is not acceptable as this relates only to the main website.

GDS have a sample accessibility statement to follow, or you can follow the NHS Digital one. The site must declare elements that are known not to be accessible, and give users information on where they can find an accessible version.

Use of colour

We aim to make sure our site is accessible to as many people as possible.  

For this reason, we use a grey background and dark grey text which is easier to read for people with dyslexia. This is important as around 10% of the population has dyslexia, according to the British Dyslexia Association.

We always maintain a ratio of at least 4.5:1, and aim for 7:1. Online tools can help you check your proposed colour scheme.

Suppliers can find information on the correct colour palette for NHS Digital branded tools in our style guide (usually those for a professional audience). Those developing for members of the public can consult the NHS.UK style guide.

Using plain English

In order to meet the required AA standard, content must also be understandable. This means using simple words wherever possible. We aim for a reading age of 8 to 12 when developing content for NHS Digital, even when the content is aimed at a professional audience.  

Research shows that even those with higher literacy and subject knowledge prefer plain English. This is because it allows those using the content to understand the information as quickly as possible.

Professionals understand the complex language used in their area, but do not want to read it if there is an alternative.

Technical terms can be used, but they should be explained the first time they are used on a page, or as part of a journey.

Online tools can be a quick way to identify the reading age of content on a page.

Javascript and accessibility

Javascript is not natively accessible to all users, such as those with some braille computers. Requiring Javascript for the user to load a page means that some users cannot access it all. That would be a failure of 'perceivable' on the WCAG framework at 'A', and does not meet the legal minimum required standard.

All services must, in order to comply with the accessibility regulations:

  • have pages that load, with information that makes sense, even if Javascript is disabled (even if that information is just to tell the user the alternative route to the same information or task)
  • give users without Javascript the ability to complete the same tasks as those with Javascript, within reason

In almost all cases you should use progressive enhancement. This is in line with Government Digital Service guidance, and helps to ensure that the service is resilient, accessible, and well built. 

Some features cannot be easily created without using Javascript, such as interactive charts, maps, or tools. If this is the case you should consider:

  • if your choice of feature has genuine user needs that require Javascript, or if a progressive enhancement build could achieve the same objective (even if it is harder to build)
  • if you can present a non-Javascript version for users without it, using server-side rendering. For example, an interactive graph could be displayed as a static SVG if the user doesn't have Javascript enabled.
  • what alternative route you can give non-Javascript users, such as links to the data files used to render a chart or map

Well-designed Javascript can help with accessibility and usability of your site, with enhancements including highlighting, making certain elements 'sticky' or other user interface improvements.

If you do use Javascript to improve the user experience for users without accessibility needs, users must be able to perform exactly the same tasks with Javascript turned off. If this is not the case, then you must complete and document a disproportionate burden assessment, explaining why you are not or can not make it fully accessible.

Accessible images

Images are very helpful for giving users information, but this information must always be available to users who cannot see or understand the image.

Pages should:

  • never place important text within an image
  • always have a way for users who cannot see the image to understand what it shows
  • use alt-text appropriately

Where particular emphasis is required on information, such as an infographic, this should be created in HTML and styled in the CSS so that all users can read and understand it.

If using a photograph, this should be in JPG format, and have descriptive alt-text which gives detail about what the image contains. Good alt-text would be "A doctor shares a tablet computer with a patient, and is pointing at the screen", where bad alt-text would be things like "doctor and patient" or "picture1.jpg".

When graphs and charts are required, consideration should be given to using an accessible tool for visualisation, which can be navigated using things like screen readers. If this is not possible, then they should be in scalable vector graphic (SVG) format, with all text rendered as text. A properly constructed SVG will have relationships between objects which allow users to navigate and read them

The same applies to architectural, flow, and process diagrams, where using a properly constructed SVG can allow all users some level of understanding.

When the image format is not fully accessible, and as good practice when it is, pages should also include a full description of when it being shown. This can be a collapsed element within the page for most users (and ARIA labelled for accessibility users) to avoid cluttering the screen.  

You should also consider providing source data in an accessible spreadsheet.

Using data appropriately

As well as being fully tested for security, all services used by NHS Digital must meet the requirements of the General Data Protection Regulation (GDPR) and the Privacy and Electronic Communications Regulations (PECR).  

This means that particular care must be taken to only use personal data where we:

  • have a reason (known as a lawful basis)
  • have a data privacy impact assessment in place
  • have processes and procedures to handle that data correctly

Personal data includes things like IP addresses, and the regulations also cover what we can do with 'cookies' on a computer.

All services must ensure:

  • a data privacy impact assessment is completed before going live
  • personal data, including IP addresses and other unique identifiers, is only collected where absolutely necessary, or where consent is given
  • cookies comply with NHS Digital's policies, including allowing users to opt-out of non-essential cookies

Common failures against this standard include the use of persistent cookies or cookies which are not strictly essential, like analytics cookies, within websites.


Cookies are small bits of data placed on your computer or device by a website.

You can only place these cookies if:

  • the website will not work without it, and they are not used for other purposes, or
  • you get permission from the user

This permission must be gained before the cookies are placed. Placing cookies and just telling the user about them afterwards is unlawful. 

NHS Digital uses a tool called Cookiebot to manage cookies across its sites.

Because Cookiebot uses Javascript, we do not place any non-essential cookies when Javascript is disabled, as users do not get the chance to opt-out.

It is not acceptable for third-party applications used by NHS Digital to place or use cookies which could be used in conjunction with any other data. If we use a booking tool, for example, information should not be stored in or used from cookies which would allow the company running that booking tool to link the NHS Digital transaction with any other visit the user makes to other sites they operate. This applies even if the supplier does not do this linking. They must ensure that it is not possible to link the events.

Responsive design

All pages must be fully usable on both desktop and mobile devices, with content working well in any format. As part of accessibility, pages should also work well if the user does not use a screen, for example if they use a screen reader or braille reader.

Pages should respond to changes made by the user, such as resizing their browser window, or changing the orientation of their device.

Where relevant, features such as columns should realign, and on the narrowest screens, may form a single line rather than side by side.


As these standards are all required by law, where products are delivered to NHS Digital, they will be checked as acceptance criteria.

Last edited: 24 November 2022 1:31 pm