We have detected that you are using Internet Explorer to visit this website. Internet Explorer is now being phased out by Microsoft. As a result, NHS Digital no longer supports any version of Internet Explorer for our web-based products, as it involves considerable extra effort and expense, which cannot be justified from public funds. Some features on this site will not work. You should use a modern browser such as Edge, Chrome, Firefox, or Safari. If you have difficulty installing or accessing a different browser, contact your IT support team.
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.
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.
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 |
nowrap |
|
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 |
Accessibility
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 accessiblity 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 accessiblity 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
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.
Compliance
As these standards are all required by law, where products are delivered to NHS Digital, they will be checked as acceptance criteria.