Accessibility issues
Common accessibility issues
- Last reviewed
- 14 September 2026
- Owner
- DesignOps
Many DfE products and websites contain similar accessibility issues. You can prevent many of these issues by following accessible design and development practices.
This guidance covers some of the issues we find most often. Use it to understand the problem, how it can affect users and what you can do to prevent or fix it.
Error messages
Create error messages that clearly explain what has gone wrong and how the user can fix it.
Follow GOV.UK guidance on error messages.
Non-descriptive error messages
Generic or unclear error messages can make it difficult for users to understand what went wrong and what they need to do.
Do
Use a clear message that describes the problem and tells the user how to fix it.
Do not
Use a generic or ambiguous error message that does not explain what went wrong.
Errors from a server or database
Server or database errors can contain technical information and may be difficult for users to understand.
Do Catch technical errors and provide a clear, user-friendly message.
Do not Do not show database-generated or technical error messages to users.
Error messages not linked to the input
Linking an error message to the relevant input helps users find and correct errors. This is particularly important for people using screen readers, as it helps them to understand which input the error message is referring to.
Do Link the error message to the input that contains the error.
Do not Do not use plain text that does not identify the input containing the error.
Mismatched error summaries
Error summaries list all the errors on a page. They’re usually placed at the top of the page and help users quickly identify and correct any errors.
Error summaries are particularly useful for screen reader users, as they provide a clear and concise list of all the errors on a page.
Do Ensure the error is linked to the input in error, and is descriptive.
Do not Do not have different error messages in the summary and against the input.
Headings
Use headings to create a logical structure that helps users understand and navigate your content.
Follow GOV.UK guidance on headings.
Check the structure of your pages with the HeadingsMap tool.
Skipped heading levels
Skipped heading levels can cause confusion, and from a semantic code perspective, is incorrect.
Structure headings in a logical order, for example, use H1 followed by H2, and H3.
Do Use a logical heading structure which clearly shows the hierarchy of the page.
Do not Do not skip heading levels, this makes it difficult for users to and semantically incorrect.
Incorrect heading structure
Use semantic HTML headings in the code to give content a clear structure. This helps screen reader users navigate the page and understand how the content is organised.
Follow GOV.UK guidance for headings, which encourages the use of H1 to H3. If content appears to need a heading beyond H3, consider redesigning it.
Do Use correct HTML markup (H1, H2, H3) for headings.
Do not Do not style paragraphs or other elements to look like headings.
Images, charts and alt text
Make sure people who have vision access needs can understand the information on your images or charts.
Follow GOV.UK guidance on accessible images.
Wrong alt text
Alt text should describe the purpose or information conveyed by an image.
Do Write alt text that accurately describes the image when the image provides useful information.
Do not Do not use filenames or misleading descriptions as alternative text.
Charts and data
Make sure information in charts can be understood without relying on colour alone. This is especially important for users with colour vision deficiency (sometimes called colour blindness).
Use the DfE charts guidance.
Do Use labels and other ways of communicating the information in a chart.
Do not Do not use colour alone to distinguish data or communicate meaning.
Links
Use clear and descriptive link text so users can understand where a link will take them. Some users, especially those using a screen reader, may navigate content by looking for links or viewing links in a list to try to find specific content.
Follow GOV.UK guidance on links.
Repetitive links
In some cases, repetitive links are necessary, for example, in a table where actions may be required.
You can make links more useful by including visually-hidden text for each link, which supports screen-reader users to understand the context of the link.
This is particularly useful when designing for users to check their answers.
Do Use hidden text to add extra information for the edit link.
Do not Do not use generic content without additional context.
Non-descriptive links
Links need to be unique and descriptive sousers know what to expct.
Do Use inline concise link text that describes the destination or action.
Do not Use generic link text or link an unnecessarily long sentence.
Status changes to content
When JavaScript is used to update content on a page, sighted users can see the changes.
For users with vision access needs or who use a screen reader or magnifier, you need to communicate these changes in other ways.
For example, when a page is loading, usually a visual spinning circle can be seen by default, this update will not be provided to screen readers.
How to prevent issues
ARIA live regions are one way changes to content can be provided to screen readers. Ensure the correct live region is provided depending on the type of change.
Incorrect use of ARIA can make an experience worse. If you need advice on implementing ARIA live regions, contact the DesignOps team.
Find more information about ARIA live regions on the Mozilla Developer Network.
Changes to content not provided to screen readers
Do Use ARIA attributes to tell screen readers about content changes.
Do not Do not rely on icons alone to alert users to changes on a page.
Colour
Make sure colour does not prevent people from accessing or understanding your content. This is important for users with vision access needs such as low vision or colour vision deficiency.
DfE digital services should follow GOV.UK guidance for colour.
Campaign sites using a different colour palette can get support from DigiComms (open DfE intranet) (link opens in new tab) and the professional body for government communicators.
Text contrast
Use sufficient contrast between text and its background.
Normal text should have a contrast ratio of at least 4.5:1 and large text should have a ratio of at least 3:1.
Check your colour contrast.
Do Use foreground and background colours that sufficiently contrast.
Do not Do not use light text on pale backgrounds that makes content difficult to read.
Non-text contrast
Important non-text elements, such as controls, should have sufficient contrast against the background.
The minimum contrast ratio for non-text elements is 3:1.
Check your colour contrast.
Do Ensure elements like buttons sufficiently contrast against the page background.
Do not Do not use colours that make it difficult to identify an element against a background.
Focus states
Focus states help users know they're on an interactive element, like a link or a form input. They're important for people who use a keyboard to navigate, and for those with vision access needs such as low vision or colour vision deficiency.
Changing the colour or style of focus states can make them harder to recognise and can cause inconsistency across DfE services.
Use GOV.UK Design System focus states and GOV.UK Frontend.
Changing the colour or style of focus states can make them harder to recognise and can cause inconsistency across DfE services.
Do Use the default GOV.UK Design System styling for focus states.
Do not Do not change the colour or style of focus states.