Accessibility Conformance Report for Independent Health and Aged Care Pricing Authority (IHACPA)

Evaluated by
Larry Hudson, Hilary Kaplan and Shannon Loh
Commissioned by
Independent Health and Aged Care Pricing Authority (IHACPA)
Target
WCAG 2.1, Level AA
Date
31 January 2024

Executive summary

This report explains the accessibility issues that are stopping the Independent Health and Aged Care Pricing Authority (IHACPA) website from conforming to WCAG 2.1 at Level AA. While the structure of the website is good, some features and custom functionality have been implemented without web accessibility in mind.

This report was prepared in by Larry Hudson, Hilary Kaplan and Shannon Loh from the Information Access Group. The screen reader user testing was completed by James Battaglia and Assunta Fogliaro.

Results by principle

Principle Results by principle
Perceivable 12 of 20
Operable 12 of 17
Understandable 9 of 10
Robust 1 of 3
Total 34 of 50

About this report

This report explains the accessibility issues that are stopping the Independent Health and Aged Care Pricing Authority (IHACPA) website from conforming to WCAG 2.1 at Level AA. While the structure of the website is good, some features and custom functionality have been implemented without web accessibility in mind.

This report was prepared in by Larry Hudson, Hilary Kaplan and Shannon Loh from the Information Access Group. The screen reader user testing was completed by James Battaglia and Assunta Fogliaro.

This report has been updated to reflect the status of the issues after re-testing on 25 March 2024.

Methodology

Our standard process is to test a website in different browsers and on different devices. This includes Chrome, Firefox and Edge on Windows 11, Safari on macOS, Chrome on Android and Safari on iPhone.

We use a mix of machine level testing of the entire site with testing software called Accessibility Insights.

We then undertake manual checking, including testing keyboard accessibility, as well as testing behaviour with different screen readers including JAWS, NVDA and VoiceOver.

Our screen reader testers James and Assunta supported us with manual checking. For this project, they conducted checks using JAWS and Edge on Windows and VoiceOver and Safari on iPhone.

We also conducted user testing of the website with James and Assunta over Zoom.

We use the WCAG-EM reporting methodology.

The WCAG-EM methodology consists of:

  1. Defining the scope of the report, including setting the baseline level of accessibility.
  2. Exploring the website and taking notes about the main functions of the site.
  3. Selecting a sample of representative webpages.
  4. Conducting checks on the webpages in different web browsers, checking against each success criterion in WCAG 2.1 to Level AA.
  5. Compiling a report that explains those issues, including instructions on how to resolve the issues.

Scope

Pages

Scope:

Not in scope:

Accessibility support

The audited website should work in at least the following browsers and assistive technologies:

Technologies used

The audited web page relies on the following technologies:

Webpages audited

Issues

  1. Icons should have meaningful alternative text (1.1.1)
  2. Infographics should have meaningful alternative text (1.1.1)
  3. Videos should have text transcripts (1.2.1)
  4. Videos have auto-generated captions (1.2.2)
  5. Videos should have audio descriptions (1.2.3)
  6. Lists should be properly tagged (1.3.1)
  7. Headings should be properly tagged and nested (1.3.1)
  8. Form instructions in placeholder text (1.3.1)
  9. Download icons implemented with only CSS need text alternatives (1.3.1)
  10. Navigation elements should have descriptive labels (1.3.1)
  11. Form fields for personal information should have autocomplete attributes (1.3.5)
  12. Colour contrast issues (1.4.3)
  13. Content should reflow when zoomed in to 400% (1.4.10)
  14. Interactive elements are not accessible via keyboard (2.1.1)
  15. Document metadata should be after the main content (2.4.1)
  16. When closing revealed content, focus should return to the component that revealed it (2.4.3)
  17. Revealing content should move focus into the revealed content (2.4.3)
  18. Card links have long and confusing link text (2.4.4)
  19. Links should have descriptive link text (2.4.4)
  20. Tabbable elements should have a visible focus indicator (2.4.7)
  21. Focus indicator on homepage should be consistent (2.4.7)
  22. Changing a form field's setting shouldn't submit the form (3.2.2)
  23. HTML syntax errors (4.1.1)
  24. Link tag used where button tag should be used (4.1.2)
  25. Screen readers do not announce the state of elements (4.1.2)

Icons should have meaningful alternative text

Problem

On top-level landing pages, such as Health care, there are icons that accompany the link card components. These icon images do not have meaningful alternative text - they are repeating the name of the page. For example, the icon for 'Classification' has the alt text 'Classification icon'. This is redundant and makes the link text longer for screen reader users.

Example of landing page link with icon

This is a problem because:

Solution

In this case, because adding a description would make the link text less clear, we would recommend hiding the icon by adding alt="".

Read more

WCAG criterion:
1.1.1: Non-text Content (external link)
Difficulty:
Low
Severity:
Low
Example URLs:

Infographics should have meaningful alternative text

Problem

Alternative text should provide an accurate description of the image so that people who cannot see the image can understand the content in the image.

This problem can cause issues for:

Solution

Because these infographic images are quite complex, we recommend providing a long description of text near the image, with a reference to the location of the long description within the alt attribute of the <img> tag.

To save vertical scrolling space, this could be included within a collapsible dropdown component. This may be possible with the IHACPA's website Drupal CMS.

For example:

<img src="benefits-of-cluster-coding-diagram.png" alt="The Benefits of cluster coding shown in a text diagram. A text version of the image is below.">
<details>
<summary>Text version of the image above</summary>
<!-- HTML of the long text version -->
</details>

Example of long text version for the 'Benefits of cluster coding' image:

Benefits of cluster coding
Clustering increases the understanding of activity data and provides more powerful information for end users by:

  • identifying relationships between codes
    • eg. multiple poisonings and injuries in the context of accompanying external cause codes
  • enhancing safety and quality reporting
    • eg. identifying hospital acquired complications in unique clusters
  • enhancing reporting of chronic conditions
    • eg. reporting all chronic conditions regardless of whether they meet ACS 0002 Additional diagnoses
  • reducing assumptions when interpreting data
  • eliminating the need to review episodes of care to establish relationships between codes
  • supporting future funding models
  • preparing for a potential future implementation of ICD-11, where clustering is a feature

Read more

WCAG criterion:
1.1.1: Non-text Content (external link)
Difficulty:
Low
Severity:
Low
Example URLs:

Videos should have text transcripts

Problem

A text transcript is a written version of the spoken content in the video. It allows individuals who prefer reading to access the video information. Embedded YouTube videos on the website do not have a text transcript.

This problem could cause issues for:

Solution

To solve this issue, write up a transcript of the spoken content in the video. The transcript should also include any relevant audio cues or non-verbal elements that are important.

Once the transcript is written, include it on the webpage, preferably below the video. You can use a drop-down component to hide the transcript, labelled, "Video transcript for [name of video]", so it doesn't take up too much space on the page.

To ensure the drop-down component is accessible use aria-expanded attributes to indicate whether the transcript is visible or hidden, and use aria-controls to associate the drop-down component with the transcript.

Alternatively, use YouTube's captioning feature, which automatically generates subtitles for videos. Review the auto-generated captions and make any necessary corrections before publishing.

Read more

Videos have auto-generated captions

Note: This issue is not a WCAG failure but it is a best practice recommendation.

Problem

Captions are synchronised to the video. They include dialogue, identify who is speaking, and descriptions of non-speech information, such as sound effects. The problem with captions being auto-generated is that they may be inaccurate and include grammatical errors.

This problem could cause issues for:

Captions are not needed if there is an alternative text version of the video also provided on the webpage.

Solution

Review the auto-generated captions and ensure they accurately represent the video content. If there are multiple speakers in the video, indicate who is speaking. If there are meaningful sound effects, include descriptions of them.

Alternatively, provide a text alternative version of the video.

Read more

Videos should have audio descriptions

Problem

An audio description is an extended audio version of the video that includes a narration of the visual aspects of the video, such as the scenes, actions, and on-screen text. The embedded videos on the IHACPA website do not have audio descriptions.

You can view an example of a video with audio description here: Apple - Accessibility - Sady (with Audio Descriptions)

This problem could cause issues for:

Audio descriptions are not needed if there is an alternative text version of the video also provided on the webpage.

Solution

YouTube currently does not have support to add audio descriptions to a video. You can produce a separate video with audio that includes audio descriptions, and provide it as an alternative version of the video on the same webpage.

Alternatively, provide a text alternative version of the video.

Read more

Lists should be properly tagged

Problem

Across the IHACPA website, there are a number of lists that are not contained within semantically correct containers. This means that people who use assistive technology do not know that they are lists, and do not know how many items are in the list.

This issue is found in the following places:

If these lists were <ul> elements with an <li> for each list item, screen reader users would hear when they are entering and leaving the list of links, and would hear how many links there are in the list. This would make it easier for screen reader users to navigate the page. It would also give screen reader users a better understanding of the content on the page.

Solution

To fix this, wrap the list of links in a <ul> tag, and each link <a> tag in an <li> tag.

<h2 class="section__heading">Documents</h2>
<div class="related-content">
<ul class="no-bullets" role="list">
<li>
<a class="related-content__link quick-link" href="/resources/amhcc-user-manual">
<span class="quick-link__label">AMHCC User Manual</span>
<span class="quick-link__icon icon icon--type-chevron-right"></span>
</a>
</li>
<!-- Rest of items go here-->
</ul>
</div>

To remove the default list styling, you can add the following CSS:

ul.no-bullets {
list-style-type: none;
padding-left: 0;
}

Please note that in Safari, setting list-style-type to none will mean that the list will not be announced as a list. To fix this, you can add a role="list" attribute to the <ul> element.

Read more

Headings should be properly tagged and nested

Problem

When headings are properly coded, screen reader users can easily navigate through all the headings in a page. This is especially useful for long pages, as it allows users to quickly jump to the section they are interested in.

There are some places on the IHACPA website where text that looks like a heading is not coded as a heading.

While the headings work visually, screen reader users will not be able to quickly jump to those headings using the 'headings list' function of their screen reader.

Also, some pages have heading levels that are not consistent with the visual presentation of the page. For instance, a heading that is visually presented as a level 2 heading is coded as a level 3 heading.

Example of places on the website with these issues:

Solution

For each page to have an accurate heading structure, the headings should be coded to match the visual hierarchy of the page. This means the title of the page should be a <h1>, then the main subheadings should be <h2> and so on.

The headings should be nested one level at a time and should not skip a level, so for example <h4> headings should not be directly under a <h2> heading.

When editing a page, make sure that all headings use proper heading styles. For example, look out for bold text that should be a heading.

An example of correct heading structure for the Aged Care page:

Read more

Form instructions in placeholder text

Problem

At the bottom of each page on the IHACPA website, the user can give feedback by filling out a form. The form has a <textarea> for the user to enter their feedback.

The <textarea> has a visible label 'Please tell us how you think we could improve', but this label is implemented as a placeholder. For the element to pass success criterion 1.3.1, the visible label must be programmatically determinable. For it to be programmatically determinable, this label needs to be associated with the element.

While the 'name' and 'email address' fields are associated with their visible <label> elements, their placeholder text includes the instruction that the fields are optional. This means that the instructions are not programmatically determinable.

The IHACPA website also has a search box in the top right corner of the page. The search box has a visible label 'Search...'. This label is implemented as a placeholder. This is the same issue as the feedback form. It appears that the search input has a corresponding <label> element, but the <label> is hidden using the CSS display: none. This hides the label from screen reader users, so the label does not work.

This could potentially cause issues for:

Solution

To solve this issue, the visible label of the <textarea> should be moved to a <label> element that sits above the <textarea> tag. The id attribute of the <textarea> should match the for attribute of the <label>:

<label for="edit-feedback">Please tell us how you think we could improve</label>
<textarea name=feedback" id="edit-feedback"></textarea>

The 'optional' instructions for the 'name' and 'email address' fields should be moved from the placeholder text to the <label> element:

<label for="edit-name">Your name (optional)</label>
<input type="text" name="name" id="edit-name">
...
<label for="edit-email-address">Your email address (optional)</label>
<input type="email" name="email" id="edit-email-address">

For the search box, this issue can be solved by removing the display: none CSS from the <label> element. Instead of using display: none, the <label> can be hidden visually using the following CSS:

.visually-hidden {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}

While this will hide the label visually, the label will still be read out by a screen reader.

Read more

WCAG criterion:
1.3.1: Info and Relationships (external link)
Difficulty:
Easy
Severity:
Medium
Example URLs:
All pages

Download icons implemented with only CSS need text alternatives

Problem

The resource pages of the IHACPA website (example) have a Downloads section in the Sidebar that lists documents and reports as PDFs and Word documents that can be downloaded:

Documents with download icons

These links have a 'download' icon on the right hand side that visually indicates to the user that clicking on the link will download a document. However, screen reader users do not know that icon is there, so they do not get the same indication. This is because the icon is rendered through CSS, and there is no text alternative to communicate the meaning of the icon.

This problem can cause issues for:

Solution

There are several ways to solve this issue:

  1. Use screen reader-only text to add a text alternative to the icon. screen reader-only text can be a <span> element with a CSS class that hides the text visually, but is still read out by a screen reader. For example:
<a class="node-downloads__item node-downloads__item--type-download quick-link"
href="/sites/default/files/2024-01/IHACPA-pricing-framework-australian-public-hospital-services-2024-25_1.pdf"
target="_blank">

<span class="quick-link__label"> Pricing Framework for Australian Public Hospital Services 2024-25</span>
<span class="node-downloads__item-information">
<span class="node-downloads__item-file-type">pdf</span>
<span class="node-downloads__item-file-size">868.61 KB</span>
</span> <span class="quick-link__icon icon icon--type-link-download"></span>
<span class="sr-only">Download PDF</span>
</a>
  1. Use an <img> tag to render the image. Set the alternative text to the alt attribute in the image tag. For example:
<img src="/themes/custom/ihacpa/assets/images/icons.min.svg?token=_jWel7P9#link-download-view" alt="Download PDF">
  1. If using an <svg> tag in the HTML:
    • add the alt text inside a <title> tag inside the <svg> tag
    • add an id attribute to the <title> tag
    • add an aria-labelledby attribute to the <svg> tag and set it to the title's id.
    • add role="img" to the <svg> tag
<svg role="img" aria-labelledby="icon-title">
<title id="icon-title">Download PDF</title>
<!-- SVG path information -->
</svg>
  1. Add visible text to the link that describes the action of clicking the link, such as 'Download PDF'.

Read more

WCAG criterion:
1.3.1: Info and Relationships (external link)
Difficulty:
Low
Severity:
Low
Example URLs:

Note: This issue is not a WCAG failure but it is a best practice recommendation.

Problem

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.

Solution

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

Difficulty:
Low
Severity:
Low
Example URLs:
All pages

Form fields for personal information should have autocomplete attributes

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:

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

WCAG criterion:
1.3.5: Identify Input Purpose (external link)
Difficulty:
Low
Severity:
Medium
Example URLs:
All pages

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:

Health care item in Discover section

Subscribe placeholders

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

WCAG criterion:
1.4.3: Contrast (Minimum) (external link)
Difficulty:
Low
Severity:
Medium
Example URLs:

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:

Is this page useful? section - 'No' is off screen

Search results overlap with 'Sort by' label

This problem can cause issues for:

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

WCAG criterion:
1.4.10: Reflow (external link)
Difficulty:
Medium
Severity:
Low
Example URLs:
All pages

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:

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

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:

Metadata on the right hand side of the page

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

WCAG criterion:
2.4.1: Bypass Blocks (external link)
Difficulty:
Low
Severity:
Medium
Example URLs:

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:

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

WCAG criterion:
2.4.3: Focus Order (external link)
Difficulty:
Medium
Severity:
Medium
Example URLs:

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

WCAG criterion:
2.4.3: Focus Order (external link)
Difficulty:
Medium
Severity:
Medium
Example URLs:

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:

Card link example

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"><!-- image content --></div>
<div class="node__content"><!-- type and featured --></div>

<h2>
<a href="path/to/link"><!-- card title --></a>
</h2>

<p class="node__summary"><!-- summary text --></p>
<p class="node__meta"><!-- date --></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
{
/* hover and focus styles */
}

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

WCAG criterion:
2.4.4: Link Purpose (In Context) (external link)
Difficulty:
Medium
Severity:
Medium
Example URLs:

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:

This issue is found on the following pages:

Solution

Provide more context in the link text to describe the purpose of the link. For example:

Read more

WCAG criterion:
2.4.4: Link Purpose (In Context) (external link)
Difficulty:
Low
Severity:
Medium
Example URLs:

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:

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:

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:

/* This will apply to all elements with focus */
: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:

/* This will apply to all elements with focus inside elements with the 'bg-dark' class */
.bg-dark :focus {
outline: 2px solid white;
}

/* This will apply to all elements with focus inside elements with the 'bg-light' class */
.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

WCAG criterion:
2.4.7: Focus Visible (external link)
Difficulty:
Low
Severity:
High
Example URLs:

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:

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

WCAG criterion:
2.4.7: Focus Visible (external link)
Difficulty:
Low
Severity:
Medium
Example URLs:

Changing a form field's setting shouldn't submit the form

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:

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

WCAG criterion:
3.2.2: On Input (external link)
Difficulty:
Medium
Severity:
Medium
Example URLs:
All pages

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:

  1. <p> tags should not be inside <span> tags.
  2. <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.
  3. <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.
  4. <a> tags with a href attribute cannot contain '[' or ']' characters in their value.

Solution

  1. Change the <span> tags to <div> tags.
  2. Add a heading to the <section> tag, or replace the <section> tag with a <div> tag.
  3. Replace the <div> tags with <span> tags.
  4. 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

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.

Select All link

Link elements (<a>) should only be used to:

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

WCAG criterion:
4.1.2: Name, Role, Value (external link)
Difficulty:
Severity:
Medium
Example URLs:

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

WCAG criterion:
4.1.2: Name, Role, Value (external link)
Difficulty:
Medium
Severity:
Medium
Example URLs:

PDF accessibility issues

We have reviewed the following PDF documents for accessibility issues:

  1. Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0
  2. IHACPA Annual Report 2022-23
  3. Implementation of Cluster Coding Fact Sheet
  4. Pricing Framework for Australian Public Hospital Services 2024-25
  5. Refundable Accommodation Deposit (RAD) Approval Application Form

In general, the PDF document format is difficult to read for people who use assistive technology.

If you want to make the information easier to access for people who use assistive technology, publish it as a webpage. Even if it is a simplified text version of the document, it will much easier to use than a PDF. We have more information about the benefits of HTML on our website.

We recommend adapting your processes to publish digital-first content. Digital-first content makes the most of the possibilities of the web, and is easier to access for everyone. A good example of a digital-first publication is the Family Violence Reform Rolling Action Plan 2020-2023 published by the Victorian Government.

Below we have described the issues we found in the PDFs we reviewed, and how to fix them. We reviewed the PDFs using Adobe Acrobat Pro DC on Windows 11.

  1. Document does not have tags
  2. Alternative text for images
  3. Colour contrast
  4. Heading structure
  5. Reading order panel
  6. Table regularity issues
  7. Tables for non-tabular content
  8. Form fields need to be tagged properly

Document does not have tags

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.

Microsoft Word PDF export options

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.

Adobe InDesign PDF export options

Read more

Difficulty:
Medium
Severity:
High
Affected PDFs:
  • Implementation of Cluster Coding Fact Sheet

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:

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.

Editing alt text in Microsoft Word

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.

Editing alt text in Adobe InDesign

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)

Editing alt text in Adobe Acrobat

Read more

Difficulty:
Medium
Severity:
Medium
Affected PDFs:
  • Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0
  • IHACPA Annual Report 2022-23
  • Refundable Accommodation Deposit (RAD) Approval Application Form

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:

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

Difficulty:
Low
Severity:
Medium
Affected PDFs:
  • Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0
  • IHACPA Annual Report 2022-23
  • Pricing Framework for Australian Public Hospital Services 2024-25
  • Refundable Accommodation Deposit (RAD) Approval Application Form

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:

This problem shows up in the following places:

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.

List of heading styles in Word styles panel

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.

Setting export options for paragraph style in InDesign

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.

Setting heading level in Acrobat

Read more

Difficulty:
Medium
Severity:
Medium
Affected PDFs:
  • Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0
  • IHACPA Annual Report 2022-23
  • Implementation of Cluster Coding Fact Sheet
  • Pricing Framework for Australian Public Hospital Services 2024-25
  • Refundable Accommodation Deposit (RAD) Approval Application Form

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:

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:

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:

Order panel in Adobe Acrobat

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

Difficulty:
Medium
Severity:
Medium
Affected PDFs:
  • Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0
  • IHACPA Annual Report 2022-23
  • Implementation of Cluster Coding Fact Sheet
  • Pricing Framework for Australian Public Hospital Services 2024-25
  • Refundable Accommodation Deposit (RAD) Approval Application Form

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':

PDF table with table editor highlighting cells

Acrobat table editor editing cell properties

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

Difficulty:
Medium
Severity:
Low
Affected PDFs:
  • Development of ICD-10-AM/ACHI/ACS Thirteenth Edition and AR-DRG Version 12.0

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:

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

Difficulty:
Medium
Severity:
Medium
Affected PDFs:
  • IHACPA Annual Report 2022-23

Form fields need to be tagged properly

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:

  1. Add your form fields to the page using Adobe Acrobat's Prepare Form tool.
  2. 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.
  3. 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.
  4. Open the Tags panel and move the <Form> tags to the correct place in the logical reading order of the document.

Read more

Difficulty:
High
Severity:
Medium
Affected PDFs:
  • Refundable Accommodation Deposit (RAD) Approval Application Form