Accessibility
What matters most
We designed the southeastwater.com.au website with accessibility in mind from day one. Web accessibility is making a website usable to as many people as possible, including people with disabilities such as visual impairment or difficulties using a mouse.
We’re working towards conformance to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.
What are the Web Content Accessibility Guidelines? (WCAG)
The World Wide Web Consortium (W3C) publishes the Web Content Accessibility Guidelines (WCAG), and outlines what it is in their abstract.
"Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities."
Testing conformance of our website
We engaged a specialised and independent auditor, Intopia, to test the conformance of southeastwater.com.au with Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1 Level A and AA.
Two rounds of testing have been completed across a representative sample of different pages and states, content types such as text, images, tables and multimedia, and types of web technologies. It also includes pages or views that are necessary to complete a task, such completing a form.
Methodology
The testing methodology is based on the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 published by the W3C Web Accessibility Initiative.
Technologies relied on for conformance
WCAG 2.1 requires that utilised technologies are supported by users' assistive technologies (e.g. screen readers, screen magnifiers, speech recognition software) as well as the accessibility features in browsers.
The following technologies are relied upon and must be turned on and/or supported for this website to conform with WCAG 2.1 Level AA:
- HTML
- CSS
- JavaScript
- DOM
- WAI-ARIA
Software tested
The following assistive technologies were used during testing:
- JAWS 2018 with Chrome86 on PC running Windows 10
- VoiceOver with Safari on iOS 14.0.1
The assistive technologies are installed and used with default settings.
What we did well
The accessibility audit findings outlined these areas where the southeastwater.com.au website performed well.
The sequence of content
"Screenreader users navigate content on a page linearly, making the order of content important. The order of content is consistent and makes it easy for content to be understood."
Consistent navigation and identification
"Navigational mechanisms that are repeated across a set of web pages occur in the same relative order and interactive components repeated across the site are also identified consistently. This helps all users but in particular blind, low vision and cognitively impaired users to become comfortable that they will able to predict where they can find elements on each page."
Multiple ways to find content
"A variety of ways are provided for users to find content such as linking to all pages on the site from the home page and a search function. This increases the chances of users with access needs finding what they are looking for."
What we can improve
We continuously improve our services in a range of ways, and improving our website is no different. We have already addressed a number of issues from the findings of the accessibility audit.
Of the remaining issues there are no critical severity rated issues, six high severity issues, and the remaining are medium severity. Below are the remaining areas of non-conformance.
| Issue | Why it matters |
|---|---|
| Chat button overlaps other content at 400% zoom | This impacts on users with poor vision, the elderly or people with dyslexia that may need to zoom the page in order to use the site. They may have difficulty viewing the content when it is overlapped by the Chat function. |
| Credit card input fields on our payment form are not marked as required in the code | If the required fields aren't indicated or marked up correctly, users will not be aware which fields are mandatory until the form fails submission validation. |
| Error messages on credit card input fields on our payment form are not announced by screen readers | For screen reader users who are vision impaired, they will not receive any information that an error has been created, and what needs to be done to resolve the error. |
| The visible label is different from the label in code for the credit card input fields on our payment form | Speech recognition software users may not be able to reference the element directly because its visible label doesn’t match its programmatic (in-code) label. Text-to-speech users may get confused by hearing element labels that don’t match what they can see on screen. |
| External link icon displayed when a new tab is opened is unlabelled | Screen reader users who rely on text alternatives to understand the purpose of an image will not be provided this information. |
| Google reCaptcha iFrame doesn't have a title | A screen reader user has no way of quickly identifying the iFrame when focus moves to it. |
| Homepage carousel banners should be announced when buttons are activated | When a screen reader user activates the slide directly from the Previous or Next buttons, the keyboard focus should move to the start of that slides content so that the next thing they hear is the content. |
| Homepage carousel banners should be marked up in a list. | Assistive technology relies on semantically meaningful HTML to provide the appropriate support to users. |
| Some icons don't have alternative text labels | Screen reader users who rely on text alternatives to understand the purpose of an image will not be provided this information. |
| Main navigation menu blue underline focus indicator visually blends in with the blue page banner. | It is important to provide a clear visual indicator for navigation focus, which does not rely upon colour alone. |
| Some images which are decorative have alternative text labels, which for their placement is redundant for screen readers | Screen reader users visit an extra element only to hear useless or redundant content. |
| Some pages contain parsing errors which include duplicate ID's | User agents, including assistive technologies, require code to be semantically correct so they can accurately interpret and parse content. For example, a screen reader may say the wrong label if a form uses the sameID to identify multiple fields, causing the user to make mistakes. |
| Some pages don't use landmarks correctly | When the wrong landmark is chosen to represent a piece of content, then a screen reader user may mistakenly believe it does not meet their needs and pass over it. It can be difficult for screen reader users to identify which landmark they are on if landmarks are not labelled appropriately. |
| Some text is marked up as heading in code | Users of assistive technology can skim through headings to get a sense of the content and structure of a page. When text that isn’t acting as a heading is marked up as a heading, it disrupts an assistive technology user’s ability to understand the structure and content. It may also affect their ability to navigate via headings. |
| The active page in Breadcrumbs is not announced by iOS VoiceOver | A screen reader user will not know which page is the current page. |
| The heading hierarchy of some pages isn't well-formed | Screen reader users rely on headings to form a mental model of the content structure. When the heading hierarchy is not well-formed, the page is harder to visualise and understand. |
| The upgrades and projects summary table is marked in the code as a list instead of a table | Sighted users can visually scan a table and quickly make visual associations between data in the table and their appropriate row and/or column headers. Someone that cannot see the table cannot make these visual associations. A screen reader relies on tables being marked up correctly to be able to provide useful information to the user about their location within the table. |
| When the mobile menu and the search bar is open a screen reader virtual cursor is able to access elements from the page in the background. | Assistive technology and keyboard users are likely to become disoriented and confused if they can move out of the modal context and into the parent page while the modal remains open. |
PDF documents
We have a number of Portable Document Format (PDF) documents hosted on our website, and these have not been audited for accessibility conformance. PDF's are widely used and accepted ways of providing documents online. They can be viewed in most web browsers. We recommend using Adobe Acrobat Reader, which is free to download and includes features that help people with disabilities - read more about Adobe Acrobat Reader's accessibility features here.
We're aiming to minimise the use of PDF's by providing content in rich web page format where possible. We believe this is a better experience for most people, is more searchable, and is more accessible from a wide range of devices.
We're open to feedback
We update content on this website regularly to ensure it's useful, accurate, and relevant. We make all efforts to ensure this content is easy to understand and accessible.
If you have accessibility issues or have noticed something on our website that isn't as usable as it could be, we'd love to hear about it.
You can get in touch with us by phone on 13 16 94, or submit your feedback online.