Accessibility

Issue and Description

Further detail

WCAG 2.1.1 Keyboard
Users should be able to use a keyboard to access all content and functionality of a web page. This means the page can be used by people with no vision as well as people who use alternative keyboards or input devices that act as a keyboard.

At 200% and 400% zoom the hamburger menu cannot be accessed using the keyboard.

WCAG 2.4.7 Focus Visible

A visible focus helps users know which element has keyboard focus and where they are on the page.

When an element gets focus there should be a visible border around it. Highlighting the element that has keyboard focus or is hovered over can provide information like whether the element is interactive or the scope of that element.

Operating systems have a native indication of focus, which is available in many browsers. The default display of the focus indicator is not always highly visible and may even be difficult to see especially on coloured backgrounds.

There is no visible focus on the magnifying glass icon button in the search bar in the page header.

WCAG 1.4.10 Reflow

Reflow or ‘responsive web design’ helps users with low vision who may need to enlarge text on a webpage and read it in a single column without scrolling in more than one direction. It also helps users who are viewing the page on a mobile device.

If a page does not support reflow it can appear smaller and more difficult to use or content may be cut off.

Navigation menus often collapse into fewer items or into a single menu button to take up less space. All content and functionality must still be fully available.

At 400% zoom the explanatory text in the cookie banner is partly cut off.

WCAG 1.4.13 Content on Hover or Focus

Content that appears when an element gets keyboard focus or on mouse pointer hover can confuse users as they may not have intended to trigger an action or may not notice that new content has appeared. This functionality may not show on mobile devices.

If using this functionality to display extra content, the following must be true:

• There should be a way of dismissing the content without changing the hover or focus - unless the content communicates an input error or does not obscure or replace other content
• If content is triggered on pointer hover, the pointer must be able to be moved over the content without disappearing
• The content must remain visible until the hover or focus is removed, the user dismisses it, or the information is no longer valid

There is no mechanism to dismiss the additional content available on hover over the 'Patients & Visitors' and 'Our Services' links in the navigation bar without moving the pointer.

WCAG 2.4.3 Focus Order
Users should be able to navigate a web page in an order that makes sense. Keyboard navigation should reflect a navigation sequence that is consistent with the meaning of content. Logical navigation reduces confusion and shows logical relationships between content and components.

The focus order may differ from the visual reading order as long as a user can still understand the web page without sight.

The focus only moves to the cookie banner after the rest of the page content, meaning keyboard users cannot easily dismiss this. This issue is worsened at higher zoom levels, as the cookie banner covers a larger portion of the screen.

WCAG 1.4.3 Contrast (minimum):
Elements must have sufficient colour contrast.

Poor colour contrast makes it difficult for someone with sight loss to see the content properly. If there is a big difference between the background and foreground colours it should be much easier to see the difference between them.

At 200% & 400% zoom and on a small screen (320x256), the links in the hamburger menu (e.g. 'Home' and 'Coming into Hospital') do not have sufficient colour contrast when receiving hover.

WCAG 4.1.2 Name, Role, Value: Buttons must have discernible text.

Issue found using Deque Axe.

All buttons must have a descriptive accessible name so that screen reader users can understand the destination, purpose, function, or action of the button.

If an image is used as a button, screen readers may not understand the use without a clear and accessible name. The title of an active image may not give enough information. Unnamed active images will have no details of the destination, purpose or action.

This refers to the hidden button in the search bar in the page header.

Element Location: #form50902edae9a747358fdd41b90e973a39 > .search > button <button id="submit">

WCAG 1.4.3 Contrast (minimum): Elements must have sufficient colour contrast.

At 200% & 400% zoom and on a small screen (320x256), the links in the hamburger menu (e.g. 'Home' and 'Coming into Hospital') do not have sufficient colour contrast when receiving hover.

WCAG 1.3.1 Info and Relationships:
<li> elements must be contained in a <ul> or <ol>.

Issue found using Deque Axe.

Screen readers tell users if a list is present and how many items are in the list. This helps users to know what they are reading and what to expect. It is important to use the correct semantic hierarchy for lists.

Ordered, unordered and description lists must contain semantically correct parent and child elements. When lists contain other elements or they are ordered incorrectly, screen readers are not able to read the lists accurately.

This refers to the 'Getting to Us', 'Freedom of Information' and 'Data Protection and Healthcare Records' <li> elements below the 'Related Links' heading.

To solve these problems, you need to fix the following: List items do not have a <ul>, <ol> parent element.

WCAG 1.3.1 Info and Relationships:
<ul> and <ol> must only directly contain <li>, <script> or <template> elements.

Issue found using Deque Axe.

Screen readers tell users if a list is present and how many items are in the list. This helps users to know what they are reading and what to expect. It is important to use the correct semantic hierarchy for lists.

Ordered, unordered and description lists must contain semantically correct parent and child elements. When lists contain other elements or they are ordered incorrectly, screen readers are not able to read the lists accurately.

This refers to the 'Related Links' <ul> element.

Element Location: .related-links > ul <ul>

To solve this problem, you need to fix the following: List element has direct children that are not allowed: a.

WCAG 4.1.2 Name, Role, Value: Buttons must have discernible text

This refers to the hidden button in the search bar in the page header.

Element Location: #form50902edae9a747358fdd41b90e973a39 > .search > button <button id="submit">

WCAG 2.4.2 Page titled

PDF documents should have titles that describe the topic or purpose of the page. Titles help users understand the topic without having to read the entire document.

Without a descriptive title a user may need to spend time searching the document to decide whether the content is relevant.

When a PDF is displayed in a browser the title will usually be displayed in the top title bar or as the tab name.

The page title is missing from the document settings.