Standards for web products

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:

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.

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

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.

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 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.

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.

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.