Skip to main content

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.

Standards for web products

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

  • Tick Image

    TLS 1.2

  • Tick Image

    TLS 1.3

Do not use

  • Cross Image

    Do not use TLS 1.1

  • Cross Image

    Do not use TLS 1.0

  • Cross Image

    Do not use SSL 3

  • Cross Image

    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
nowrap

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

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 accessiblity 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)
  • avoid using Javascript, Flash and other technologies which are not accessible

Teams can get further guidance on how to comply with the AA standard on the NHS digital service manual accessibility pages.

All sites must have a valid accessiblity 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 accessiblity 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 non-accessible technology

You should make sure your pages work in HTML, then add CSS, and only when these work correctly should you consider using Javascript or other technologies to add user experience improvements.

Sites should follow Government Digital Service guidance on progressive enhancement, as this helps to ensure that the service is resilient, accessible, and well built. 

If you do use Javascript to improve the user experience for users without accessiblity needs, users must be able to perform exactly the same tasks with Javascript turned off.

Examples include:

  • elements like 'sticky' navigation which follows the user down the page, provided they are correctly marked up as navigation for non-sighted users
  • progress bars and indicators to show a process is working, so long as non-Javascript users also get a relevant message (like 'Submitting')
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 accessiblity, 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.

Last edited: 16 September 2019 2:31 pm