Note: This issue is not a WCAG failure but it is a best practice recommendation.
Navigation elements should have descriptive labels so that screen reader users know what they are.
Because there are quite a few navigation elements on pages of the IHACPA website, it is important that the screen reader is able to establish the purpose of the element.
Include a label for the navigation elements so that the screen reader can establish the purpose of the Navigation element.
Please note that the word 'navigation' will be announced after the label, so it is not necessary to include the word 'navigation' in the label.
We would recommend using the following labels:
- Top navigation (Media and events, Contact us): 'Top'
- Header navigation: 'Main'
- Footer navigation: 'Footer'
- Other IHACPA websites navigation: 'Other IHACPA websites'
- Bottom navigation: 'Bottom'
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
The navigation elements now have descriptive labels that are read out by screen-readers.
Problem
Text fields that serve certain purposes must have the correct HTML5 autocomplete attribute. This is to help users who use assistive technology to fill out forms more quickly.
The 'name' and 'email address' fields on the feedback form are missing the autocomplete attribute. This means that users who use assistive technology to fill out forms may not be able to do so as quickly as they would like.
This problem could cause issues for:
- People who use screen readers – screen reader users may not be able to fill out the form as quickly as they would like
- People who are time-poor
- People who have a cognitive disability.
Solution
To solve this issue, the 'name' and 'email address' fields should have the autocomplete attribute set to the correct value for the field. The correct value can be found in the W3C list of input purposes.
The 'name' field should have the autocomplete attribute set to 'name':
<input data-drupal-selector="edit-name" [...] autocomplete="name">
```html
The 'email address' field should have the autocomplete attribute set to 'email':
```html
<input data-drupal-selector="edit-email-address" [...] autocomplete="email">
When this change is made, users who use the 'autofill' feature of their web browser will be able to fill out this form more efficiently.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
Colour contrast issues
Problem
For a webpage to pass the WCAG success criterion 1.4.3, the text colour and background colour should have a contrast ratio of at least 4.5:1. This will make sure that text is legible for people with low vision and people with colourblindness.
This problem can cause issues for people with low vision and people with colourblindness, who may have difficulty reading the text.
Places on the website with this issue:
- On the home page in the 'Discover' section, the text colour of the category headings (light blue #88A7CC) is not sufficiently different from the background colour (almost white #FAFBFB). This means that the text does not meet the minimum contrast ratio of 4.5:1.
- On the Subscribe page, the form field placeholder text is light grey #B5B9C7 against white #FFFFFF. This has a contrast ratio of 2:1. This means that the text does not meet the minimum contrast ratio of 4.5:1.
Solution
Change the text colour of the category headings to a darker colour that meets the minimum contrast ratio of 4.5:1.
For the 'Discover' category headings, the text colour can be darkened to #4974AB. Against the #FAFBFB background, this has a contrast ratio of 4.63:1.
For the 'Subscribe' field placeholders, the text colour can be darkened to #6E7391. Against the #FFFFFF background, this has a contrast ratio of 4.64:1.
You can use a colour contrast checker tool to check the contrast ratio of the text and background colours. For example, WebAIM's colour contrast checker.
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved.
The text colour of the category headings in the 'Discover' section has been darkened to #4974AB. The text colour of the form field placeholders on the Subscribe page has been darkened to #6E7391. Both of these colours meet the minimum contrast ratio of 4.5:1.
However, when a user hovers over a link in the 'Discover' section, the category heading changes to pink #bf798f on a light yellow background #fff7ed. This has a contrast ratio of 3.1:1. This does not meet the minimum contrast ratio of 4.5:1.
Status after second re-testing
As of 18 June 2024, this issue remains partially resolved.
In the 'Discover' section on the home page, when the viewport width is less than 1024px, and the user hovers overs the card, the description text turns to white on the light yellow background. This has a contrast ratio of 1.1:1, which does not meet the minimum contrast ratio of 4.5:1.
- Note: this issue was not picked up in the previous re-test.
The other colour contrast issues picked up from previous testing have been resolved.
Content should reflow when zoomed in to 400%
Problem
For a webpage to pass the WCAG success criterion 1.4.10, a user should be able to zoom in to 400% and the content should reflow. The user should not need to scroll in two directions (eg. horizontally and vertically) to see all the content on the page.
On the IHACPA website, there are a couple of places where the content does not properly reflow when the user zooms in to 400%. The issue can be found in the following places:
- Inside the 'Is this page useful?' section, the 'No' button goes off the right hand side of the screen
- When the user is searching, the number of search results overlaps the 'Sort by' label.
This problem can cause issues for:
- People who have low vision and use a screen magnifier to zoom in on content. They may not be able to see all the content on the page.
Solution
To solve this issue, you can adjust your display resolution to 1280 x 1024 and zoom in to 400%. Then, you can check that the content reflows properly. If the content does not reflow, you may need to make changes to the CSS styling of the page.
Allow elements to wrap to the next line when the browser window is resized, and make sure each element is visible when the browser window width is at 320px minimum.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
Interactive elements are not accessible via keyboard
Problem
Across the IHACPA website, there are a few places where interactive elements are not accessible using the keyboard. This means that users who rely on a keyboard to navigate the website cannot access these elements. This issue can be found in the following places:
- Collapsible sections – while mouse users can click on the '+' toggle to expand the section, keyboard users cannot tab to the toggle and activate it. This is because the toggle is a
<div> element with a 'click' event listener. Also, when the section is expanded or collapsed, there is no indication to the user that this has happened. For screen reader users, they hear a heading for the section, but there is no content below the heading, and they cannot hear that it is a collapsible section.
- Navigation menu button – on mobile view, the menu button becomes a 'hamburger' icon. This icon is not accessible using the keyboard. This is because it is a
<div> element with a 'click' event listener.
- Footer – the 'back to top' arrow button is not accessible using the keyboard. This is because it is a
<div> element with a 'click' event listener.
- Header – when the user has typed in the search box, there is an 'X' button to clear the search input, but it is not accessible using the keyboard. This is because the 'X' button is a
<span> element with a 'click' event listener.
- Sidebar navigation – pages that have subpages have a 'down arrow' button that reveals the subpages. The 'down arrow' buttons are not accessible with the keyboard because they are
<span> elements with 'click' event listeners.
- 'Is this page useful?' section – the 'Yes', 'No' and 'Give feedback' buttons are not accessible using the keyboard. This is because they are
<div> elements with 'click' event listeners. Also, when the feedback form is visible, the 'Cancel' button is not accessible using the keyboard for the same reason.
- Filters on 'Search' and 'Resources' pages – the filter dropdowns are not accessible using the keyboard. This is because they are
<legend> elements with click event listeners. This means that keyboard users cannot tab to the dropdowns, and they cannot hear whether the dropdown is open or closed.
- When a filter dropdown is open, the checkboxes are not tabbable because they are
<input type="checkbox"> elements with 'display: none' which hides them from screen readers.
- When a filter is activated, and there is a blue 'pill' for each filter, mouse users can click on the 'pill' to remove the filter. Keyboard users cannot tab to the 'pills' because they are
<div> elements with 'click' event listeners.
Solution
To solve these issues, we would recommend using <button> elements for interactive elements that are currently <div> or <span> elements with 'click' event listeners.
When you use a <button> element for an interactive element, it is automatically accessible with the keyboard. This is because the <button> element can be focused with the keyboard by default, meaning it shows up in the 'focus order'. When users focus on a button and hit the 'Enter' key, the button is activated and the button's 'click' event listener fires.
Web developers are sometimes hesitant to use <button> elements because they are not as easy to style as <div> or <span> elements. However, there are ways to style <button> elements to look like <div> or <span> elements. Here is CSS code you can use to 'reset' the default styling of a <button> element:
button,
.button {
-webkit-appearance: none;
border-radius: 0;
text-align: inherit;
background: none;
box-shadow: none;
padding: 0;
cursor: pointer;
border: none;
color: inherit;
font: inherit;
display: inline-block;
margin: 0;
}
Please note that if you use CSS to reset the default styling of a <button> element, you will need to apply some styles to make it accessible. You will need to add a focus indicator and use styling to differentiate it from body text:
button {
border: 2px solid black;
padding: 0.5rem 1rem;
}
button:focus {
outline: 2px solid blue;
}
If it's not possible to use a <button> instead of a <div> or <span> element, you can add a tabindex attribute to the element. This will make the element focusable with the keyboard. The element should also have a role attribute to indicate what type of element it is. For example, if the element is a toggle, you can use role="button". You will also need to make sure that the JavaScript code that is currently listening for a 'click' event is also listening for a 'keyup' event on the 'Enter' key and the 'Space' key. This is because when a user focuses on an element and hits the 'Enter' key, the 'keyup' event fires, not the 'click' event.
The 'keyup' event should be used instead of 'keydown' because the 'keydown' event fires when the user presses the key down, but the 'keyup' event fires when the user releases the key. This means that if the user holds down the key, the 'keydown' event will fire multiple times, but the 'keyup' event will only fire once. Using the 'keyup' event also means that the user can cancel the action by hitting 'Tab' to move the focus away from the element before releasing the key.
Using aria-expanded:
<div>
<h3>
<button aria-expanded="false">Question</button>
</h3>
<div>
<p>Answer</p>
</div>
</div>
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved.
Below is a summary of the changes that have been made, and the issues that need to be resolved:
- Collapsible sections – can now be opened with the keyboard as a
<button> element has been added. However it is not possible to close the collapsible section with the keyboard as the collapsible section will close and then open again. This is because there is a click and a keyup event listener. When the user focuses on a <button> element and hits the enter key, both the click and the keyup events fire, so it is the same as clicking the toggle twice. To resolve this, the keyup event listener should be removed.
- Navigation menu button – is now a
<button> but has no visible focus indicator. See this related issue for more information: Tabbable elements should have a visible focus indicator
- Back to top button – is now a
<button> but doesn't move focus to the top of the page, so the functionality does not work for keyboard users. To resolve this, when the window scrolls to the top of the page, the focus should move to the first focusable element on the page.
- X to clear search – is now a
<button> but has no visible focus indicator. See this related issue for more information: Tabbable elements should have a visible focus indicator
- Sidenav dropdown – is now a
<span> with role="button" and tabindex="0" but when you hit enter, it activates the parent <a> element. To resolve this, the dropdown <span> should be moved outside the parent <a> element.
- 'Is this page helpful?' section – is now a
<button> and the issue has been resolved.
- Filters on search page – the
<input> elements still have display: none so they are not tabbable.
- Legend elements on search page – now have
aria-expanded and tabindex="0". The activated filter pills on search page work well.
Note: in the 'Solution' above, we mentioned adding a keyup event instead of keydown. Please note that the keyup event listener is only required when the element is not a <button> element. If the element is a <button> element, the click event will automatically fire when a user focuses on the button and hits the 'Enter' key. The keyup event listener only needs to be added for other elements (eg. <div>, <span>) where this is not built-in.
Status after second re-testing
As of 18 June 2024, this issue remains partially resolved.
Below is a summary of issues that need to be resolved:
- Back to the top button – this moves focus to the top of the main section when clicked, however, there's not visible indicator to where the focus has moved.
Below is a summary of the issues that have been resolved:
- Collapsible sections – the issue with the collapsible sections has been resolved. The sections can now be opened and closed with the keyboard.
- Navigation menu button – this now has a focus indicator, and the issue has been resolved.
- X to clear search – this now has a focus indicator, and the issue has been resolved.
- Sidenav dropdown – the issue with the sidenav dropdown has been resolved. The dropdown is now accessible with the keyboard.
Document metadata should be after the main content
Note: This issue is not a WCAG failure but it is a best practice recommendation.
Problem
On the publication pages, there is metadata about the publication on the right hand side:
The metadata occurs within the <main> element but before the main page content. This means that when screen reader users jump to the main landmark for the page, they still need to navigate through the metadata (Resource type, Industry, and Topics) before they can get to the main content. This makes the page more difficult to navigate.
Visually, the metadata is displayed on the right hand side of the page and will be read first by the screen reader. This is not the logical order for users to read the page.
Solution
The metadata should be moved below the main content. This will make it easier for screen reader users to navigate the page.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
The metadata information has been moved to appear after the main content of the page.
When closing revealed content, focus should return to the component that revealed it
Problem
Across the IHACPA website, there are some components that reveal hidden content when activated. When this content is closed, the focus is not returned to the component that revealed it. This can cause issues for users who rely on a keyboard to navigate the website, as it is difficult for them to navigate through revealed content then continue on from that point.
This issue shows up in these places:
- Header – when the user clicks on a top-level item in the main navigation menu, a sub-menu is revealed. When the user clicks away from the sub-menu, the focus is not returned to the top-level item that revealed it.
Please note there are other components that reveal content, but they are not currently accessible via the keyboard. This means keyboard users cannot open or close them. When these components are made accessible, this issue will need to be resolved too.
Solution
To resolve this issue, the focus should be returned to the component that revealed the hidden content when it is closed.
<button id="menu-toggle" aria-expanded="false" aria-controls="main-menu">Show menu</button>
<div id="main-menu" class="hidden">
<nav>...</nav>
</div>
<script>
const menuToggle = document.getElementById("menu-toggle");
const mainMenu = document.getElementById("main-menu");
menuToggle.addEventListener("click", () => {
const expanded = menuToggle.getAttribute("aria-expanded") === "true" || false;
menuToggle.setAttribute("aria-expanded", !expanded);
mainMenu.classList.toggle("hidden");
});
mainMenu.addEventListener("keyup", (event) => {
if (event.key === "Escape") {
menuToggle.focus();
}
});
document.addEventListener("click", (event) => {
const clickingInsideMenu = event.target.closest("#main-menu");
if (!clickingInsideMenu) {
menuToggle.focus();
}
});
</script>
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved.
When the user closes the main navigation menu, the focus is returned to the top-level item that revealed it. This allows keyboard users to continue navigating from that point. However, this only works for keyboard users with a screen-reader.
However, when keyboard users try to close the navigation menu, the menu closes and then opens again. This is because there is a click and a keyup event listener attached to the <button> element. When the user focuses on a <button> element and hits the enter key, both the click and the keyup events fire, so it is the same as clicking the toggle twice. To resolve this, the keyup event listener should be removed. The collapsible sections have the same issue.
Status after second re-testing
As of 18 June 2024, this issue remains partially resolved.
When non-screen-reader keyboard users try to open the drop-down on the main navigation menu, such as the 'Health care' drop-down, the menu opens and closes again. This is because there is a click and keyup event listener attached to the navigation item that is being fired twice.
Revealing content should move focus into the revealed content
Problem
There are a few components across the IHACPA website that reveal hidden content when activated. When this content is revealed, the focus is not moved into the revealed content. This can cause issues for users who rely on a keyboard to navigate the website, as it is difficult for them to navigate through revealed content then continue on from that point.
Please note there are other components that reveal content, but they are not currently accessible via the keyboard. This means keyboard users cannot open or close them. When these components are made accessible, this issue will need to be resolved too.
Solution
When a component reveals hidden content, the focus should be moved into the revealed content.
This can be achieved using JavaScript code that is executed inside the 'click' event listener of the component that reveals the hidden content. The container of the revealed content should have tabindex="-1" and the focus should move to that container when the component is activated. For example:
<button id="menu-toggle" aria-expanded="false" aria-controls="main-menu">Show menu</button>
<div id="main-menu" tabindex="-1">
<nav>...</nav>
</div>
<script>
const menuToggle = document.getElementById('menu-toggle');
const mainMenu = document.getElementById('main-menu');
menuToggle.addEventListener('click', () => {
const isExpanded = menuToggle.getAttribute('aria-expanded') === 'true';
menuToggle.setAttribute('aria-expanded', !isExpanded);
mainMenu.classList.toggle('hidden');
if (!isExpanded) {
mainMenu.focus();
}
});
</script>
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
When the user expands a component to reveal hidden content, for instance the main navigation menu and accordion components, the focus is moved into the revealed content. This allows keyboard users to navigate through the revealed content and continue on from that point.
Card links have long and confusing link text
Note: This issue is not a WCAG failure but it is a best practice recommendation.
Problem
On the Resources page, there are card link components with an image, resource type, featured tag, title, description, and date:
All of these elements are wrapped in a singular <a> element, to make the entire card clickable.
However, this is not ideal for screen reader users because it results in the entire contents of the card being read out when navigated to, and makes it hard to navigate quickly through links. For a user to hear the link text, they need to navigate through the entire card contents, which can be quite long.
Solution
Put the card title text in the <a> tag, and use CSS to make the entire card clickable. For example:
<div class="node">
<div class="node__image"></div>
<div class="node__content"></div>
<h2>
<a href="path/to/link"></a>
</h2>
<p class="node__summary"></p>
<p class="node__meta"></p>
</div>
.node {
position: relative;
}
.node a::before {
content: "";
position: absolute;
inset: 0;
z-index: 1;
}
.node a {
cursor: pointer;
}
.node a:hover::before,
.node a:focus::before {
}
By making this change, screen reader users will be able to efficiently navigate through the links on the page, without listening to the entire contents of each card.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
The card links have been updated so that the <a> tag only wraps the card title, but CSS has been added to make the entire card clickable. This means screen reader users can quickly navigate through the links on the page without listening to the entire contents of each card.
Links should have descriptive link text
Problem
The purpose of a link should be clear from the link text alone. When links have descriptive titles, screen reader users can quickly tab through the links on the page and have a good idea of where they go. Screen reader users can also use the 'links list' function of their screen reader to view a list of links on the page. Some links on the IHACPA website could have more descriptive titles.
This problem can cause issues for:
- People who use screen readers or keyboard navigation – they may use assistive technology to skip links that they are not interested in, but if the purpose of the link is not clear, they need to take extra steps to find the context
- People with cognitive disabilities – they may not be able to understand the purpose of the link if it is not clear, or requires more navigation to find the context.
This issue is found on the following pages:
- On the Home page, 'See all' is a link to see all consultation resources, but the link text does not indicate that it goes to a page with consultation resources.
- On the Costing overview page, where there is a link that says 'Read the full report'. The purpose of this link is to download a PDF file, but the link text does not indicate that it is a PDF file.
- On the NWAU calculators page, there are links, such as 'SAS-based calculators for 2023–24 here', which go to a cloud drive folder, where the user can download a ZIP folder. However, the link text does not indicate that it goes to a cloud drive folder, or that it is a ZIP folder.
Solution
Provide more context in the link text to describe the purpose of the link. For example:
- 'See all consultation resources' instead of 'See all'
- 'Download the full report (PDF)' instead of 'Read the full report'
- 'See our files and download the SAS-based calculators for 2023–24 here (ZIP)' instead of 'SAS-based calculators for 2023–24 here'
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
Screen-reader only text has been added to the links to provide more context for links. For exmaple, 'consultations' has been added as screen-reader only text to the 'See all' link on the home page, so the screen-reader user will hear 'See all consultations'.
Links to download files have been updated to include the file type in the link text. For example, 'Read the full report' has been updated to 'Read the full report (PDF)'. This will help users know that the link goes to a PDF file.
Focus indicator on homepage should be consistent
Problem
For keyboard users to be able to navigate the website effectively, interactive elements need a consistent, visible focus indicator.
On the home page, there are links next to the headings that lead to more content, such as 'See All', 'All resources', and 'Education tools'. While navigating with the keyboard, the visible focus style matches the hover style, where the text changes colour and becomes underlined. However, other links on the page maintain a consistent black outline style. This inconsistency in focus styles might cause users to overlook the focus when tabbing through these links, as they are accustomed to visually following the black outline, where disappears when reaching these links.
This problem can cause issues for:
- People who use a keyboard – a visible focus is necessary for the user to know what elements they are focusing on
- People with cognitive disabilities.
Solution
Apply a consistent focus style for all links on the page that is clear and noticeable.
:focus {
outline: 2px solid #000;
}
Please note that the outline colour needs to have enough contrast against the background colour for it to be accessible. If there are different background colours on the website, you may need to use different outline colours for different elements. You can see the solution to the Tabbable elements should have a visible focus indicator issue for more information.
Read more
Status after re-testing
As of 25 March 2024, this issue has not been resolved.
The focus indicators of the 'See All', 'All resources', and 'Education tools' links have not been updated to match the outline style of the other links on the page. This makes the focus inconsistent and difficult to notice for keyboard users.
We have also noticed a new issue with the focus indicators of the publication title links. When the user tabs to them, only the right border is visible.
This is because the node__heading class on the h2 element has the CSS overflow: hidden, which is obscuring the :focus outline. To solve this issue, remove the overflow: hidden declaration from the node__heading class.
Status after second re-testing
As of 18 June 2024, this issue has been resolved.
Tabbable elements should have a visible focus indicator
Problem
Across the IHACPA website, there are interactive elements that can receive the keyboard focus. For these elements to be accessible, they must provide a visible focus indicator. Otherwise, keyboard users cannot see where the focus is, and they cannot see where they are in the page. This can make the website difficult to navigate for keyboard users.
This issue can be found in the following places:
- Search bar – when the user focuses on the search icon, there is no visible indicator that the icon has the focus.
- Sidebar navigation – when the user focuses on the top link in the Sidebar, the focus in not clear. The background and the focus border is the same colour and there is no offset.
- Metadata information – there's not enough contrast between the focus indicator outline and the background link.
- Search filters – search button, sort by dropdown, clear all filters button don't have visible focus.
- Subscribe page – the checkboxes don't have a visible focus indicator. The drop-down menu for the 'Title' input does not have a visible focus indicator.
Another issue is present in the main navigation menu. When the user tabs past a top-level menu item, the keyboard focus moves into the top-level menu item's submenu, but the submenu is not visible. This causes issues for:
- Sighted keyboard users, who will not be able to see where the current focus is
- Screen reader users, who will need to tab through all of the submenu items even if they did not want to navigate to the submenu. This makes the main navigation menu difficult to use for screen reader users.
Solution
This issue can be resolved by adding a visible indicator to the interactive elements that can receive the keyboard focus. This can be achieved by adding a CSS outline to the element when it has the focus. For example:
:focus {
outline: 2px solid blue;
}
Please note that the outline colour needs to have enough contrast against the background colour for it to be accessible. If there are different background colours on the website, you may need to use different outline colours for different elements. For example, you may need to use a darker outline colour for elements that have a light background colour, and a lighter outline colour for elements that have a dark background colour.
If the areas with background colours have a CSS class on them, you can scope the outline colour to elements with focus inside those areas. For example:
.bg-dark :focus {
outline: 2px solid white;
}
.bg-light :focus {
outline: 2px solid black;
}
If there's not enough contrast between the element and the outline, we would recommend adding an outline offset. This can be achieved by using the CSS outline-offset property.
For the issue where the keyboard focus enters the submenu when the user tabs past a top-level menu item, the submenu should be hidden until the user tabs into the top-level menu item. This can be achieved by using the CSS display: none until the user activates the top-level menu item. That way, the user can tab through the top-level items and only activate the submenu if they want to navigate to the submenu.
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved.
The issue has been resolved for the following components:
- Metadata information – the focus indicator has been updated to be clearly visible with a blue outline and a 5px offset.
- Main navigation menu – The user can tab through the main navigation menu items and only focus on the submenu items if they expand the submenu. This way, the user is not navigating through submenu items that are not visible.
- Search – The 'Sort by' dropdown in search pages now has a visible focus indicator.
- Subscribe page – The checkboxes on the Subscribe page now have a visible focus indicator.
However, this issue is still present in the following components:
Where there is a Search bar, the search icon does not have a visible focus indicator. This is because the icon is a mask-image and hides the outline when it is applied. To solve this issue, have the icon as a separate element inside the <button> element, so when the user focuses on the <button> element, they can see the focus indicator.
For example:
<button>
<span class="icon"></span>
<span class="visually-hidden">Submit search query</span>
</button>
A visible indicator has been added to the sidebar navigation links as a blue outline with a 5px offset. However, when tabbing through the links, the outline does not appear consistently in front of the element that is focussed. For example, on the Mental Health Care page:
- Health care – the bottom border of the outline goes behind the sidebar navigation.
- Classification overview – the top border of the outline goes behind the sidebar navigation.
- Similar issues are found throughout the sidebar navigation.
To solve this issue, you can add z-index: 999 to the :focus declaration and position: relative so the z-index is applied. This will ensure that the outline appears in front of the element that is focused. For example:
:focus {
outline: 2px solid #104f99;
outline-offset: 5px;
position: relative;
z-index: 999;
}
The clear filters button does not have a visible focus indicator. This is because it is an <input> element that is styled with a class="button" The .button selector has the CSS outline: none, which is overriding the focus indicator. To solve this issue, you can remove the outline: none declaration from the .button selector.
The main navigation menu items have a visible focus indicator as you tab through them. However, the focus indicator has the same styling as the expanded state of the menu items. This means when the submenu is expanded, there is no longer a visible focus indicator for the main navigation menu items. To solve this issue, you can add a different focus indicator for the main navigation menu items when the submenu is expanded.
The same issue is found for the filter dropdowns on the Search page.
Status after second re-testing
As of 18 June 2024, this issue has been resolved.
Below is a summary of the changes made to resolve this issue:
- Search bar – The search icon now has a visible focus indicator.
- Sidebar navigation – The sidebar navigation links now have a visible focus indicator that appears consistently.
- Clear filters button – The clear filters button now has a visible focus indicator.
- Main navigation menu – The main navigation menu items now have a visible focus indicator when the submenu is expanded.
Problem
When a user changes the setting of a form field, for example clicking on a radio button, the form should not submit automatically. This is because the user may not have finished filling out the form, and may not want to submit it yet.
This is an issue in the 'Is this page useful?' component at the bottom of each page. The component has two radio buttons, 'Yes' and 'No'. Clicking on either of these radio buttons automatically submits the form.
This also occurs in the search filters when the user is on a search results page. The 'Content type' and 'Industry' dropdowns have checkboxes inside them. Toggling these checkboxes automatically submits the form. The 'sort by' dropdown also automatically submits the form when the user changes the value of the dropdown.
This problem could cause issues for:
- People who use screen readers – because the form automatically submits and a new page loads, the screen reader user may be confused and may lose their place on the page.
Solution
To solve this issue, the form should not submit automatically when the user changes the setting of a form field. Instead, the user should be able to submit the form by clicking on a 'Submit' button.
In the 'Is this page useful?' component, the radio buttons could be replaced with buttons for 'Yes' and 'No'. When the user clicks on either of these buttons, the form would submit. This would make the behaviour clearer to people who use assistive technology.
In the search filters, the problem could be solved by adding an 'Apply filters' button to the bottom of the form. This would allow users to choose the filters and then choose when they want to apply them.
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved.
The issue has been resolved for the following components:
- The 'Is this page useful?' component has been updated so that the 'Yes' and 'No' radio buttons are buttons that submit the form when the user clicks on them.
- An 'Apply filters' button has been added to the end of the Search filters form, so the form no longer submits automatically when the user selects an option from the 'Content type' and 'Industry' dropdowns.
However, we have noticed an issue with the 'Sort by' dropdown which sits above the list of search results. While the 'Sort by' dropdown is visually separated from the search form, in the HTML markup it is within the form, between the 'Industry' dropdown and the 'Apply filters' button. This could be confusing for sighted users who use the keyboard, as the focus order does not match the visual order. If possible, we would recommend moving the 'Sort by' dropdown out of the form and placing it after the number of search results.
Status after second re-testing
As of 18 June 2024, this issue has been resolved.
HTML syntax errors
Problem
The HTML Standard defines the rules for HTML markup. Conforming to this standard ensures that user agents, including assistive technologies, can correctly interpret the content of a page without crashing.
Some "parsing errors" found are:
<p> tags should not be inside <span> tags.
<section> tags do not contain a heading.
- The "Call to action link" components are placed inside a
<section> tag. This tag should contain a heading, which is missing.
<div> tags should not be inside a <label> tag.
- In the "Is this page useful?" component", the "Yes" and "No" buttons are
<label> tags, which contain <div> tags.
- On the Search page, the "Search filters" component has
<label> tags, which contain <div> tags.
<a> tags with a href attribute cannot contain '[' or ']' characters in their value.
Solution
- Change the
<span> tags to <div> tags.
- Add a heading to the
<section> tag, or replace the <section> tag with a <div> tag.
- Replace the
<div> tags with <span> tags.
- Format the
href URL so that '[' and ']' characters are not used.
You can use the W3C HTML Validator to check for parsing errors on your webpages while you're developing them.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
<p> tags are no longer found in <span> tags<div> tags are no longer found in <label> tagshref attributes in <a> tags no longer contain '[' or ']' characters
Note: This issue is not a WCAG failure but it is a best practice recommendation.
Problem
On the Subscribe page, there is a "Select All" link that is used to select all the checkboxes in the section.
Link elements (<a>) should only be used to:
- navigate the user to a new page or
- to jump to another section on the current page.
This is a problem because it can cause confusion for people who use assistive technology. They may expect the link to take them to a new page, but instead, it will select all the checkboxes in the section.
Solution
To resolve this issue, replace the 'Select all' links with <button> elements.
Read more
Status after re-testing
As of 25 March 2024, this issue has been resolved.
The 'Select All' links have been replaced with <button> elements.
Screen readers do not announce the state of elements
Problem
On the Frequently Asked Questions page, there is an accordion component, where mouse users can toggle open a question to reveal the answer. However, screen reader users cannot hear whether the question is open or closed.
The header navigation also toggles open a sub-menu when the user clicks on a top-level item. However, screen reader users cannot hear whether the sub-menu is open or closed.
The breadcrumb component on the top of some pages visually show the user where they are on the website. For screen reader users, it is announced "breadcrumbs" and then a list of page links. However, this may be confusing for some users as they may not know what "breadcrumbs" means, and don't understand what the page links are for.
The sidebar navigation visually highlights which page the user is currently on. However, for screen reader users, the information about the current page is not announced.
Also in the sidebar navigation, pages that have subpages are expandable. Screen reader users cannot hear whether the link is expanded or collapsed.
Solution
For elements that are expandable, use the aria-expanded attribute to indicate whether the it is open or closed. When it is closed, the aria-expanded attribute should be set to false. When the it is open, the aria-expanded attribute should be set to true.
<div>
<h3>
<button aria-expanded="false">Question</button>
</h3>
<div>
<p>Answer</p>
</div>
</div>
For the breadcrumbs, it is recommended to provide a more descriptive screen reader only text, such as "Breadcrumbs: current location on the website".
For the sidebar navigation, use the aria-current attribute to indicate the current page. The aria-current attribute should be set to page for the current page.
<nav>
<ul>
<li><a href="...">Page 1</a></li>
<li><a href="...">Page 2</a></li>
<li><a href="..." aria-current="page">Page 3</a></li>
<li><a href="...">Page 4</a></li>
<li><a href="...">Page 5</a></li>
</ul>
</nav>
Read more
Status after re-testing
As of 25 March 2024, this issue has been partially resolved. The aria-expanded attribute has been added to the expandable elements and toggles to true or false when the element is expanded or collapsed.
However, aria-expanded has also been added to the 'Resources' link in the main navigation. The 'Resources' section does not have a submenu, so it should not have the aria-expanded attribute. aria-expanded should only be added to the items with submenus.
Status after second re-testing
As of 18 June 2024, this issue remains partially resolved.
The aria-expanded attribute has been removed from 'Resources' and 'NDIS pricing' menu items in the main navigation, as they do not expand or collapse. However, the screen-reader is still reading out "Open / close sub-menu for ...". This is because the <span class="visually-hidden">Open / close sub-menu for</span> text is still present in the HTML.
To resolve this issue, remove the <span class="visually-hidden">Open / close sub-menu for</span> text from the HTML.
PDF accessibility issues
- Document does not have tags
- Alternative text for images
- Colour contrast
- Heading structure
- Reading order panel
- Table regularity issues
- Tables for non-tabular content
- Form fields need to be tagged properly
Problem
For a PDF to work well with assistive technology, it needs to have tags. Tags are the information in the PDF that tells assistive technology how to read the document. If a PDF does not have tags, screen readers will not be able to read the document correctly.
The 'Implementation of Cluster Coding Fact Sheet' does not have tags. This may be because the document was not exported correctly from the source document, or because the source document did not have tags.
Solution
To resolve this issue, the document needs to be tagged. This can be done by exporting the document from the source document with tags, or by adding tags to the PDF in Adobe Acrobat.
In Microsoft Word, you can export a document with tags by choosing 'Save as' and choosing 'PDF' as the file type. Then choose 'Options' and make sure the 'Document structure tags for accessibility' option is checked.
In Adobe InDesign, you can export a document with tags by choosing 'Export' and choosing 'Adobe PDF (Interactive)' as the file type. Then choose 'Export' and make sure the 'Include accessibility tags' option is checked.
Read more
Alternative text for images
Problem
Alternative text (alt text) is a description of an image that is read by screen readers. It is important for images to have alternative text so people who are blind or have low vision can understand the content of the image. When alt text is missing or incorrect, screen reader users will not be able to understand the content of the image, and will miss out on that information.
If the information in the image is also conveyed in the surrounding text, then the alternative text does not need to convey that information. The alternative text shouldn't be redundant.
In a few PDFs we reviewed, images were missing alternative text, or the alternative text was incorrect.
This issue shows up in the following places:
- Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0 - pages 1, 8, 16, 57 include images that are missing alternative text.
- IHACPA Annual Report 2022-23 - pages v, 8, 103-104, 132 include incomplete alt text that does not convey the full meaning.
- Refundable Accommodation Deposit (RAD) Approval Application Form - pages 1,2,3 include images that are missing alternative text.
Solution
To fix this issue, add alternative text to images that convey information that is not in the surrounding text.
To do this in Word, right click on the image and click 'Edit Alt Text', then enter the alt text.
To do this in InDesign, right click on the image and click 'Object Export Options', then go to the 'Alt Text' tab and set the 'Alt Text Source' to 'Custom', then enter your alt text.
To do this in Acrobat, go to the 'Order' panel, open the menu and choose 'Show Reading Order panel', then you can right click on an image and click 'Edit Alternate Text' (check wording? wording correct HK)
Read more
Colour contrast
Problem
It's important for text to have enough contrast against the background colour so it can be read by people with low vision and people with colour blindness.
For a colour combination to be accessible, it needs to have a contrast ratio of at least 4.5:1 for regular sized text, or 3:1 for large text (14pt bold or larger, or 18pt normal or larger).
This issue shows up in the following places:
- Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0 - blue hyperlinks have a contrast ratio of 4:1.
- IHACPA Annual Report 2022-23 - green hyperlinks have a contrast ratio of 4:1.
- Pricing Framework for Australian Public Hospital Services 2024-25 - turquise hyperlinks have a contrast ratio of 2.1:1.
- Refundable Accommodation Deposit (RAD) Approval Application Form - green hyperlinks on page 2 have a contrast ratio of 4:1, green headings on page 3 have a contrast ratio of 3.6:1.
Solution
To fix this issue, change the colour of the text or the background so the contrast ratio is at least 4.5:1 for regular sized text, or 3:1 for large text.
You can use a tool like WebAIM's colour contrast checker to check the contrast ratio of a colour combination.
Read more
Heading structure
Problem
It's important for documents to have a clear heading structure that mirrors the visual hierarchy of the page. This helps screen reader users navigate the document, and helps all users understand the structure of the document.
During our review we have found a few problems related to heading structure:
- We recommend using H1 for the document title, and then making the main subheadings H2.
- Some headings are not tagged as headings.
- Some text that are tagged as headings should not be headings.
- Some headings are not nested correctly. Headings should be nested one level at a time, and should not skip a level.
This problem shows up in the following places:
- Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0:
- There are multiple H1s throughout the document. Ideally the document title should be a H1, and the main headings should be H2s.
- On page 2, the document title is a H4, but as it is repeating the document title, it should be a regular paragraph P tag.
- IHACPA Annual Report 2022-23:
- There are multiple H1s throughout the document. Ideally the document title should be a H1, and the main headings should be H2s.
- The section cover pages (eg. page 1) are not tagged as headings. They should be H2s, as they begin a new section.
- Implementation of Cluster Coding Fact Sheet
- This document does not have any tags, so the heading structure has not been set up.
- Pricing Framework for Australian Public Hospital Services 2024-25
- Should only have 1 H1. In this document there are multiple H1s
- On page 2, the document title is a H4, but as it is repeating the document title, it should be a regular paragraph P tag.
- On page 9, the heading is set as a H5, but it should be a H3. It should not skip a level.
- Refundable Accommodation Deposit (RAD) Approval Application Form
- The heading structure is inconsistent - many items that should be headings are not tagged as headings.
- The green questions should be H3 tags. This would allow screen reader users to jump through the questions of the document more quickly.
- On the front cover, the document title should be a H1 but it is not tagged as a heading.
Solution
To resolve this issue, make sure that documents have a clear heading structure that is nested correctly. The heading structure should match the visual hierarchy of the page.
In Word, use the Styles panel to apply heading styles to headings. Do not only use bold, underline or large font to make text look like a heading.
In InDesign, you can set the 'object export options' of each paragraph style so they export the correct heading tag. For example, the 'Heading 1' paragraph style should export as an H1 tag.
In Acrobat, you can manually tag headings using the 'Order' panel. You can select the heading text and choose 'Heading 1' in the 'Reading order' panel.
Read more
Reading order panel
Problem
In a PDF, there are two ways to order content for assistive technology - using the Tags panel, and using the Reading Order panel. These orders should be consistent and should match the logical reading order of the document (top to bottom, left to right).
The difference between the Tags order and the Content order is:
- The Tags panel is the order that the content should be read by a screen reader.
- The Content order is the visual stacking order of the content on the page. This is the order that is presented to screen readers by some PDF viewers, such as the built-in PDF viewer in Google Chrome and Microsoft Edge.
In a few of the PDFs we have reviewed, the order of content in the Reading Order panel does not match the logical reading order. We have found this issue in the following places:
- Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0 - pages, 2, 8, 16, 24, 57 include figures that are at the end of the page's reading order, rather than in their logical position. This means some screen reader users will hear the figure at the end of the page.
- IHACPA Annual Report 2022-23 - some pages have content out of order.
- Implementation of Cluster Coding Fact Sheet - the content is not tagged, so the reading order has not been set up.
- Pricing Framework for Australian Public Hospital Services 2024-25 - pages 2, 12, 13 to 37, 34 include content that is out of order.
- Refundable Accommodation Deposit (RAD) Approval Application Form - pages 1, 3 to 13 include content that is out of order.
Solution
To resolve this issue, the order of content in the Reading Order panel needs to be adjusted so that it matches the logical reading order.
This can be manually adjusted in Adobe Acrobat after exporting the PDF. You can open the 'Order' panel and drag and drop the items to reorder them:
This can also be fixed by adjusting the order of content in the source document before exporting to PDF. In InDesign, this can be done by adjusting the stacking order of content in the Layers panel. The content at the top of the Layers panel will be at the end of the reading order, so the content needs to be ordered backwards. You can do this by going through the content in sequential order, and bringing each element to the front.
Read more
Table regularity issues
Problem
For a table to work well with assistive technology, each row should have the same number of columns. If a table includes merged cells, those cells need to include the correct 'column span' and 'row span'. If rows include inconsistent numbers of columns, screen readers may not be able to read the table correctly. These issues are referred to as 'table regularity' issues.
This issue shows up on pages 39, 52 and 54 of the 'Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0' PDF.
Solution
To resolve this issue, we would recommend avoiding using merged cells in tables. Keeping the table structure simple will make the table easier to read for screen reader users, and easier for everyone to understand.
If you need to use merged cells, you can set the 'column span' and 'row span' of each cell using the 'Table Editor' in Acrobat. You can access the Table Editor by right-clicking on a <Table> tag in the Tags panel and choosing 'Table Editor'. Then you can right click on a cell and choose 'Cell Properties' to set the 'column span' and 'row span':
Please note that the table editor in Acrobat can be difficult to use, and it is not always possible to set the correct 'column span' and 'row span' for each cell.
Read more
Tables for non-tabular content
Problem
When creating documents, tables are often used to lay out content on the page. This is due to limitations with the software used to create the document, such as Microsoft Word or Adobe InDesign. However, using tables to lay out content can make the document difficult to read for screen reader users, because the screen reader will read the content in the order that it appears in the table, rather than in the logical reading order of the document.
This problem shows up in the following places:
- IHACPA Annual Report 2022-23 - pages ix and x include content that is laid out in a table, but the content is not tabular data. The content includes a heading and regular content below the heading.
Solution
To resolve this issue, we would recommend avoiding using tables to lay out content on the page. Instead, use the software's built-in layout tools to lay out the content. For example, in Microsoft Word you can use the 'Columns' tool to lay out content in columns. In Adobe InDesign, you can use the 'Text Frame Options' to lay out content in columns.
This issue can be resolved directly in Adobe Acrobat by dragging the content out of the <Table> tag in the Tags panel. This will remove the table structure, and the content will be read in the correct order. However, we would recommend fixing this issue in the source document if possible.
Read more
Problem
For a PDF with interactive form fields to work well with a screen reader, the form fields need to be tagged properly. If the form fields are not tagged properly, screen reader users will not be able to use the form.
Solution
To tag form fields:
- Add your form fields to the page using Adobe Acrobat's Prepare Form tool.
- For each form field, right click on the form field and choose 'Properties'. Set a 'Name' and 'Tooltip' for the form field. The 'Name' should be a short description of the form field, and the 'Tooltip' should be a longer description of the form field. The 'Tooltip' is what appears when a user hovers over the form field, and it is read by screen readers.
- To add the form fields to the list of tags, go to the Content panel and click on the menu and choose 'Find...', then search for 'Unmarked Annotations'. it will highlight the unmarked annotations on the page. For each form field, click 'Tag' and type in 'Form' as the tag type.
- Open the Tags panel and move the
<Form> tags to the correct place in the logical reading order of the document.
Read more
