Non-compliance with the accessibility regulations
Some of our pages do not have all their content contained by landmarks, landmarks allow screen reader users to navigate to a section based on its HTML element or ARIA Landmark, without this content outside of sections an be difficult to find or unclear. We are doing the following to fix this issue, ensuring that all page content is contained by landmarks.
Across some of our pages some text elements have insufficient colour contrast. Some of these are links and some are buttons. This can make these elements hard to read for people with low vision who experience low contrast and therefore fails WCAG: 1.4.3. We are doing the following to fix this issue, reviewing alignment to GDS styling and where necessary ensure all text elements have sufficient colour contrast between the text in the foreground and background colour behind it.
Some of our pages do not have landmarks which are unique, the landmark must have a unique aria-label, aria-labelledby, or title to make landmarks distinguishable. This fails WCAG best practice. We are doing the following to fix this issue, reviewing our landmarks to ensure they are unique.
Across our service we have a timed refresh, since users do not expect a page to refresh automatically, such refreshing can be disorienting. Refreshing also moves the programmatic focus back to the top of the page, away from where the user had it. This fails WCAG 2.2.1 Timing Adjustable, 2.2.4 Interruptions, and 3.2.5 Change on Request. This is a security measure to protect the user’s data by ensuring they are still active, and if not, they are logged out of the service.
Some of our pages have active elements and attributes with the same ID, duplicate active ID values break the accessibility of focusable elements including labels for forms, table header cells, etc. Screen readers and client-side scripts will skip duplication other than the first instance. This fails WCAG: 4.1.1. We are doing the following to fix this issue, reviewing the service for active elements with the same ID attribute and ensuring that all IDs are unique.
Some of the links across the service have the same accessible name but do not serve the same purpose. Identical links must describe the same purpose in order to prevent user confusion. The description lets a user distinguish any one link from links in the Web page that lead to other destinations and helps the user determine whether to follow the link. This fails WCAG 2.4.9 Link Purpose (Link Only). We are doing the following to fix this issue, reviewing and updating the description of the links.
Across some of our pages we have aside or complementary elements within other content marked as a landmark. Embedding an <aside> element in another landmark may disable screen reader functionality allowing users to navigate through complementary content. This fails WCAG best practice. We are doing the following to fix this issue, ensuring complimentary landmarks or <aside> are at top level.
Across some of our pages our heading levels do not increase by only one, this will make navigating a web page more confusing for users of assistive technology. This fails WCAG best practice. We are doing the following to fix this issue, reviewing the headings across our pages to ensure they are ordered are ordered hierarchically and only increase by one.
Some of our pages contain lists, and in some instances these contain elements other than <li>, <script>, or <template>. When content elements other than list items are contained within a list, screen readers cannot inform the listener that they are listening to items within the list. This fails WCAG 1.3.1 Info and Relationships. We are doing the following to fix this issue, ensure all ordered and unordered lists (defined by <ul> or <ol> elements) contain only <li>, <script>, or <template> content elements.
Some of our pages contain list elements that are not contained within a parent list element. Without a parent list elements, list items cannot inform the screen reader and therefor listener that they are listening to a list. This fails WCAG 1.3.1 Info and Relationships. We are doing the following to fix this issue, review <li> elements across the service to ensure they are contained in a <ul> or <ol> hierarchy.
Some of our pages have heading elements that are either empty or do not have the correct ARIA labels for screen readers, this could either confuse users or even prevent them from accessing information on the pages structure. This fails WCAG best practice. We are doing the following to fix this issue, reviewing the use of header tags across the service and remove superfluous tags.
Some of the links across the service do not have discernible text. Keyboard users, including visually impaired screen reader users or people who cannot use a mouse, can activate only the links and form elements that can receive programmatic focus. This fails WCAG 2.4.4 Link Purpose (In Context) and 4.1.2 Name, Role, Value. We are doing the following to fix this issue, reviewing links across the service to ensure they have the correct elements, ARIA labels and up to date references.
Some of our form elements do not have a visible label, when form inputs contain no labels other than title and aria-describedby attribute values, screen readers interpret the content as advisory information only. This fails WCAG Best Practice. We are doing the following to fix this issue, reviewing the input fields are the service to ensure they have the correct label tag, <label>, <aria-label>, or <aria-labelledby>.
Some of our form fields have multiple label elements. Assigning multiple labels to the same form field can cause problems for some combinations of screen readers and browsers, and the results are inconsistent. This fails WCAG 3.3.2 Labels and Instructions. We are doing the following to fix this issue, reviewing our form fields and labels, ensuring fields only have a single label.
Some of our pages do not contain a level 1 heading. Screen reader users can use keyboard shortcuts to navigate directly to the first heading, this should allow them to jump directly to the main content of the web page. If there is no level 1 heading then screen reader users must listen to more of the web page to understand its structure, wasting valuable time. This fails WCAG best practice. We are doing the following to fix this issue, reviewing the pages across our service without a level 1 heading and where appropriate/necessary including this.
Across many of our pages we have green buttons that say things such as “Apply Now” or “Continue”. These are often not clearly visually focussed as the colour only changes slightly. These can still be navigated by keyboard but may be difficult to see when they are focussed. This fails WCAG 2.4 Navigable. We are doing the following to fix this issue, we inherit this functionality from the GDS front end toolkit. We will review out alignment to the latest styling guides and if necessary adjust the contrasts.
When entering into an application journey there are step indicators that show the user which step of the journey they are on and how many total steps there are. The “Show all steps” links are not accessible for keyboard users. This fails WCAG 2.1 Keyboard Accessible. We are doing the following to fix this issue, we will update the functionality to ensure it is interactive through tab navigation.
Many of the questions throughout application journeys require users to select options from a list of radio buttons. Some of these groups of radio buttons do not read out the question to screen reader users when the group is first tabbed to. Users can still go back and read the question above the radio buttons. This fails WCAG 1.3 Adaptable and 3.3 Input Assistance. We are doing the following to fix this issue, investigating and reviewing the functionality of including the question in the radio button for screen readers.
On the “Register an email” page, screen reader users may experience blank content between explanation paragraphs. This content is not providing any additional information and users are not missing anything. This just adds some unnecessary steps to the user journey. Please ignore this content. This fails WCAG 4.1 Compatible. We are doing the following to fix this issue, reviewing the HTML across the service and removing superfluous structures or elements.
Across some of the journey pages some “continue” links are styled to look like buttons. This is a semantic difference and should not affect any users in being able to complete their journey. This fails WCAG 4.1 Compatible. We are doing the following to fix this issue, reviewing our alignment to the GDS styling guide to ensure we are accurately reflecting the latest design principles.
Across many pages in all journeys, if a user provides incorrect information and received an error message, the user focus is not immediately moved to the error message nor are audio cues given. This means that keyboard and screen reader users may not necessarily be aware that something is wrong and will have to navigate back up the page content to find errors. This fails WCAG 3.3 Input Assistance. We are doing the following to fix this issue, reviewing the error messages across the fields and continually improving the service through the review of content and guidance based on user feedback.
Across many pages in all journeys we use spin boxes to allow users to input number values. Users can manually enter number as well as use the arrow keys to increase or decrease the number entered. For screen reader users when making changes to an entered number the field will read blank. This can be very confusing. This fails WCAG 4.1 Compatible. We are doing the following to fix this issue, investigating the interaction and identifying solutions.
On some pages there are separators to help structure content. These are decorative elements but still read out for screen reader users. This fails 1.1 Text Alternatives. We are doing the following to fix this issue, reviewing the HTML across the service and removing superfluous structures or elements.
On some of our information pages before uses start application journeys, we include information in several page “tabs”. Some of these tabs can be confusing to get to for Keyboard users but can be accessed with the arrow keys. In addition we have some information in tables on these pages which are not always read out as clearly with headings as could be. These issues fail WCAG 1.3 Adaptable, 2.1 Keyboard Accessible and 3.2 Predictable. We are doing the following to fix this issue, we will review the structure and content of our landing pages as we transition to the Future Boarder and Immigration System application forms.
On some “Choose a service” pages in “Step 5 – Pay” of some journeys, the choices which a user can choose are not read out to screen reader users. This fails WCAG 2.1 Keyboard Accessible. We are doing the following to fix this issue, adding the ARIA label to the radio button to make sure it is read out to all screen readers.
On the “Demonstrating your permission to be in the UK” page in some journeys, users are asked to search for their nearby Post Office. The results for this search are displayed above the search feature which may be confusing for some users. This fails WCAG 1.3 Adaptable. We are doing the following to fix this issue, restructuring the page.
When using “Out of the Country” routes a user will be asked to select a language. Some screen readers may have difficulty reading some characters from other languages and as such not read out these options and make navigating the language selection difficult. This fails WCAG 2.1 Keyboard Accessible and 3.1 Readable. We are doing the following to fix this issue, we are reviewing the provision of translated versions of content across the service.
In some “Out of the Country” routes users will be asked to provide “Details of your world travel history”. On this page none of the questions are read out alongside their answer fields for screen reader users, making answering some of these questions difficult. Users can navigate with the arrow keys to read the questions. This fails WCAG 1.3 Adaptable and 3.3 Input Assistance. We are doing the following to fix this issue, add ARIA labels to this page to ensure the questions are read out by screen readers.
For making payments during various journeys we use a system called Worldpay. This system has the following various issues:
- When tabbing to each of either the "Card number" or "Cardholder's name" fields, a screen reader will read out both labels before re-reading the correct one for the user input field the user is currently focussed on. This fails WCAG 2.4 Navigable. We have raised this to Worldpay for their consideration.
- The Expiry date fields are not well labelled which may be confusing for some users. This fails WCAG 1.3 Adaptable and 3.3 Input Assistance. We have raised this to Worldpay for their consideration.
- There are many visual labels that help users to identify when they have entered information incorrectly. These disappear when a keyboard user moves to them and as such are not accessible for screen reader users who will never be able to reach these prompts. This fails WCAG 2.1 Keyboard Accessible and 3.3 Input Assistance. We have raised this to Worldpay for their consideration.
GOV.UK