Accessibility and Inclusivity Guidelines

Guidance
Provides information and recommendations to assist agencies in complying with the Accessibility and Inclusivity Standard.
Last updated:

This guidance is part of the Digital Services Policy Framework that underpins the Digital Services Policy.

Purpose

The following guidelines provides information and recommendations to assist agencies in complying with the Accessibility and Inclusivity Standard (the Standard) and adhering to the latest version of WCAG Level AA. This is to ensure that government information and services are easily accessible to everyone, including people with disability. These guidelines, when combined with accessibility best practices, also enhance usability for all users.

Policy context

These guidelines form part of the Digital Services Policy Framework that provides guidance for agencies in the delivery of digital services, including websites and apps, and supports the Digital Services Policy.

You can also refer to the:

How to comply with the requirements of the standard

To begin your journey toward compliance, it is essential to establish a solid foundation. Recommended first steps include:

  • Consult with an expert: Engaging with accessibility experts can provide valuable insights and guidance. 
  • Baseline audits: Conducting baseline audits is a crucial step to understand your website or application's current state. Audits will help identify areas that require improvement and allow fixes to be prioritised. 
  • Appropriately skilled and resourced staff: Ensuring that your team has the right skills and resources is vital for compliance. Consider upskilling your existing staff and providing them with the necessary resources to implement accessibility measures effectively. 
  • Planning effort and time: Understanding the average effort and time required for achieving compliance will assist planning and resource allocation. 

Strategies for agency implementation 

Agencies implementing accessibility requirements must plan carefully and communicate effectively. Here are some prompts and guidance to assist you:

  • Baseline, plan, prioritise and communicate: Establish a baseline through audits and evaluations. Develop a comprehensive plan that outlines the steps needed to achieve compliance. Prioritise the identified issues based on their impact and feasibility, and communicate these to stakeholders, teams, and developers.
  • Change management: Effective change management supports a smooth transition and adoption of accessibility practices. Consider the impact of change on your people and resources, processes, systems, technology, training, and communications. 

Building requirements into existing processes

To integrate accessibility seamlessly into your agency consider: 

  • Contract and project documentation: Make accessibility compliance explicit in contract and project documentation requirements to ensure it is a core consideration throughout the development process.
  • Digital services and technology business cases: Make accessibility a clearly stated and measured benefit in all digital services and technology business cases and project proposals. By emphasising the importance of accessibility, you ensure that it remains a priority throughout the decision-making process.

All digital content must adopt the latest WCAG standard at level AA

The Website Content Accessibility Guidelines (WCAG) are the benchmark for web accessibility and are an approved ISO/IEC International Standard (ISO/IEC 40500:2012).

WCAG has four main principles that state content should be:

  • Perceivable – information and user interface components must be presentable to users in ways they can perceive.
  • Operable – user interface components and navigation must be operable.
  • Understandable – information and the operation of user interface must be understandable.
  • Robust – content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

To reach a preferred AA standard there are 55 criteria which apply (including Level A). 

Further guidance: WCAG standards and guidelines

W3C Web Accessibility Initiative (WAI) - How to Meet WCAG provides guidance and resources, including:

Content must be accessible and provided in the most useful and accessible format for the community

Provide content in a format that a wide range of users can access regardless of their literacy, technology, location or digital abilities.

There are a range of content formats. Knowing these formats allows us to apply usability and accessibility for all of our audiences. It also helps us understand when we should apply various accessibility techniques. Knowing your content formats goes hand in hand with knowing your audience. Then you can work toward providing content that meets your user’s needs.

The Centre for Accessibility has resources to check if your digital content is accessible.

The Digital Services Content Standard also provides further guidance on creating accessible and discoverable content that supports accessible and inclusive design.

Apps 

Accessibility requirements apply to app development and design.

Perceivable elements

  • Provide alternative text descriptions (alt text) for all non-text elements.
  • Ensure colour contrast of at least 4:5:1 to ensure text and images are accessible.
  • Use captions and transcripts for multimedia content.
  • Support resizable text and avoid using text in images. 

Operable features

  • Design intuitive and logical navigation structures that are easy to understand and operate using gestures, touch, and buttons.
  • Provide proper focus indicators for interactive elements to help users navigate through the app using assistive technologies.
  • Ensure that all functionalities, including form fields and controls, can be operated through both touch and keyboard input.
  • Implement appropriate timeouts and adjustable time limits for timed interactions, such as login sessions.

Understandable content

  • Use clear and concise language throughout the app, avoiding jargon and complex wording.
  • Provide meaningful error messages and instructions that assist users in understanding and resolving issues.
  • Include features such as tooltips, hints, and help documentation to aid users in understanding how to use the app effectively.
  • Support localisation and consider the cultural and linguistic diversity of your users. 

Robustness

  • Ensure compatibility with assistive technologies commonly used, like screen readers and switch controls. 
  • Test across various device sizes, orientations, and operating system versions to ensure consistent accessibility and usability.
  • Stay up to date with accessibility-related guidelines and best practices from platform-specific documentation and developer resources.

Additional recommendations

  • Provide an accessibility settings section where users can customise to meet their needs. 
  • Conduct regular accessibility audits and user testing by people with disability to identify areas for improvement.
  • Provide an accessibility statement or policy that notes your commitment to accessibility and provides contact information for users.

Documents

Some types of documents cannot be made fully compliant and are less user-friendly in general. Avoid using PDFs, or Microsoft Word, PowerPoint, or Excel documents online unless there is a specific use for that file. For example, if the file's purpose is to be printed or the spreadsheet is meant to be used. These file types are not mobile-friendly, as they take longer to download than HTML, and are not responsive.

To ensure you’re compliant, always start developing content with a webpage in mind. HTML is the most accessible format and should be used as the default format for all government information. Only use a document as a secondary source of information that’s already on your webpage. Exceptions include documents to be printed or provided for compliance purposes.

Documents must be made accessible when sharing them electronically via your intranet, public-facing websites, email or other online distribution methods.

Starting with an accessible template streamlines the effort to ensure the final document's accessibility.

Microsoft Word

Microsoft Word formats are challenging to meet compliance with the latest version of WCAG level AA. They are also difficult to view these formats on mobile devices. While Microsoft Word formats are generally preferred over PDF formats by users using assistive technologies, HTML is preferred.

To ensure better accessibility, it is recommended to refrain from publishing standalone Word documents on the web. Instead, provide the information in HTML format whenever possible. 

If converting a document to a HTML version is not feasible, consider creating an accessible PDF version and summarise the document in a HTML format. 

Remember to make Word documents accessible even when sharing them internally via email. Use the Accessibility Checker feature within Microsoft Word to identify issues and get tips to resolve.

Rich Text Format (RTF)

You should avoid using RTF as a publishing format. RTF can’t carry the same level of semantic information or accessibility that the .docx format can. 

Google Docs

While the use of Google Docs, Sheets, Slides and Drawings is dependent on individual agency security protocols, they are designed to work well with screen readers and assistive technologies.

Excel

Only publish an Excel document if there is a strong user need. They can be extremely difficult to view on mobile devices. Screen readers navigate tables in a set way depending on language and reader technology. For example, row by row, left to right. Each cell is recognised and read by the screen reader, even if it does not contain information.

Sometimes it may not be appropriate to publish in HTML for example, when documents contain a large amount of data.

When publishing Excel documents, you should:

  • Organise your data in a logical and consistent manner: Use rows and columns appropriate to create a clear table structure.
  • Provide descriptive headers: Use header rows and columns to label and describe your content. This helps screen readers and other assistive technologies understand the structure and context of the data.
  • Utilise cell merging and splitting carefully: Avoid excessive merging or splitting of cells, as it can disrupt the table structure and make it difficult for assistive technologies to interpret the data accurately.
  • Add alternative text to images and tables: If you include images or charts in your Excel document, make sure to provide alternative text that describes the content and purpose of the visual elements. Add meaningful hyperlink text and Screen Tips.
  • Use accessible colour schemes: Ensure a colour contrast of 4:5:1 between the text and background colours to improve readability. Avoid relying solely on colour to convey important information.
  • Provide context and explanations: Include clear and concise explanations or descriptions of any abbreviations, acronyms, or specialised terminology used in the document. This helps users understand the content better.
  • Give sheet tabs unique names and remove blank sheets.
  • Use the Accessibility Checker feature within Excel to identify issues and get tips to resolve.

Microsoft has guidance on making Excel documents more accessible. 

PowerPoint

Only publish a PowerPoint document if there is a strong user need. Use the Accessibility Checker feature within PowerPoint to identify issues and get tips to resolve.

Screen reading programs often interpret items on a PowerPoint slide in reverse order, which can be confusing for users with a vision or reading disability. However, PowerPoint has tools to help screen readers see slides in the way the author intended.

For custom slides, you can set the reading order yourself in the Selection Pane.

You should also:

  • Use descriptive alternative text for pictures, charts, and other visual objects.
  • Use accessible templates.
  • Use the program’s Grayscale feature to see how slides might look for someone who is colour blind.
  • Make sure that colour is not the only way you convey information.
  • Make sure that animation is brief and does not distract from the main content.
  • Use enough contrast for text and background colours.

Microsoft has guidance on making PowerPoint presentations more accessible.

PDF

A PDF is a file format for capturing and sending electronic documents, so if the original document does not meet accessibility requirements, it will be difficult to create an accessible PDF version. 

When providing a PDF (for example a requirement to print) ensure the original document is accessible to meet the latest WCAG level AA compliance. Experts can also be employed to ensure PDF accessibility. 

You should still make sure the PDF content is available in another format such as HTML. This is largely because:

  • Not all versions of all screen readers read out PDFs consistently.
  • PDF does not currently have accessibility support on mobile devices.
  • PDFs are also difficult for many users to access on smaller screens as they don’t resize and reformat to fit the screen (reflow). 
  • People can also be aware of how much data they use – especially on mobile devices. Downloading large files (over 1MB) can be difficult especially in regional and remote places.

Because of the above reasons users may simply choose not to open a PDF and this means information is hidden. 

No scanned PDFs are allowed on websites unless an alternative is provided. This is because scanned documents are essentially images and cannot be read by screen readers, which are essential for individuals with visual impairments. Optical Character Recognition in Adobe Pro can be used to convert scanned text to text, however this must be reviewed to ensure accuracy. 

Ensure the document creator has not locked the PDF. When a PDF is locked, it may prevent the screen reader from properly accessing the text, resulting in incomplete or inaccurate reading of the content. 

EPUB (Electronic Publication)

EPUB (Electronic Publication) is a widely used format for digital books and publications. It is designed to be flexible and accessible across different devices and platforms, providing a reflowable and interactive reading experience. EPUB files are commonly used for e-books and can be read on various devices and applications, including e-readers, tablets, smartphones, and desktop software.

To make EPUB content accessible, consider the following guidelines:

  • Use structured and semantic markup: Ensure that the content is properly structured using HTML tags and follows semantic markup practices. Use appropriate heading levels, lists, and other HTML elements to organise the content.
  • Provide alternative text for images: Include descriptive alternative text to convey the meaning and context of images. 
  • Use accessible colours and contrast: Choose colour combinations that have sufficient contrast to enhance readability. Avoid relying solely on colour to convey important information.
  • Include navigational aids: Provide a clear and consistent navigation structure within the EPUB, including a table of contents and links to different sections or chapters.  
  • Ensure text is resizable: Use relative font sizes that allow users to adjust the text size according to their preferences. Avoid using fixed or small font sizes. 
  • Provide audio and video alternatives: If your EPUB includes multimedia elements like audio or video, provide alternative text, captions, or transcripts. 
  • Test accessibility: Use EPUB accessibility validation tools to check for issues and assess accessibility compliance.  
  • Provide a text-only version: If the EPUB contains complex visuals or interactive elements that may not be fully accessible, consider providing a text-only version or an alternative accessible format.

Forms

Forms should be clear and easy to use. Consider the way the form will be used and the language that you use to explain the steps in completing the form. While forms can come in online, PDF and Microsoft Word formats, the preferred format is online HTML. 

Follow the WCAG techniques for creating accessible forms.

  • Start with the user’s needs: Think about the user’s requirements and what they need to achieve.
  • Write forms in plain language. Test for usability and accessibility.
  • Give the form a clear title: Call the form something that explains the task. Include a short description.
  • List supporting documents needed: If extra documents are required to complete the form, list them with a subheading.
  • Explain why you need personal information: If you are collecting personal details, include a sentence to explain why. Link to your privacy statement.
  • If the user needs to print, scan or email the form, provide a support phone number.
  • Provide adequate labels and instructions for form fields: Let users know what is required to complete the form.
  • Make buttons clear: Clearly label the buttons so that screen readers will announce them correctly. Labels like "Previous", "Next", and "Done" work well with screen readers, as opposed to labels like "<<" and ">>".
  • Make error messages clear: An error message will occur when a user enters an invalid response to a question or skips a required question. When you create the question, you can customise this error message to make it clear to users how they should answer the question. Keep in mind that this error message appears before the question text, so screen readers will read the error message first.<\/strong>
  • Use a logical heading structure.
  • Enable the ability to override session time limits for forms: Allow users to exceed and bypass time constraints set for interacting with forms. 
  • Ensure all functionality of the form is accessible with a keyboard. 
  • Make certain that all form elements have a clear visual focus and focus order.

Helpful links

Surveys and questionnaires

Accessible surveys are designed to be completed by people with a diverse range of abilities. 

  • Accessible surveys enable respondents using assistive technologies like magnifiers, screen readers and voice command and control software to successfully complete the survey.
  • An accessible survey can be completed without a mouse or keyboard. 

Keep surveys short and relevant. State how long the survey will take to complete.

Provide a support phone number.

Notify the user when the survey has been successfully completed, where the data is going and a point of contact for any questions.

  • Assess third party survey tools for compliance: Aim to use an accessible third-party tool.
  • Make the title of the survey clear: Use the title to remind the user what they are being asked about and use plain language.
  • Write clear survey questions: Avoid ambiguity in questions. Provide a short explanation of why you are asking each question. If you use an open-ended question, think how you will report on that data.
  • Don't include content that blinks or flashes: If you do have animated content in your survey, you will need to confirm that it meets the time refresh requirements. This involves ensuring that the animated content does not blink or flash more than 3 times per second. Users should be able to pause, stop or hide animated content entirely.
  • Add alternative text to logos and images: If your survey contains images that communicate meaningful information, you must add alternative text that conveys equivalent information to meet WCAG compliance. If it is decorative only, leave the alternative (alt) text empty e.g. alt=””.
  • Use a standard theme: Ensure that the theme complies with colour contrast requirements. Conduct testing using dark mode to ensure accessibility. 
  • Keep text fields close to row labels: If a row label is positioned far away from the actual input field, it may cause issues for screen magnifiers.
  • Clearly label required questions: If there are required questions in your survey, make sure these are easily identified.
  • Make error messages clear: An error message will occur when a user enters an invalid response to a question or skips a required question. When you create the question, you can customise this error message to make it clear to users how they should answer the question. Keep in mind that this error message appears before the question text, so screen readers will read the error message first.
  • Make buttons clear: Clearly label the buttons so that screen readers will announce them correctly. Labels like "Previous", "Next", and "Done" work well with screen readers, as opposed to labels like "<<" and ">>".
  • Test your survey before you send it: Surveys are quick and convenient, but it’s easy to accidentally collect misleading data.

Images

  • Always use alternative text with an image unless it is decorative only. Purely decorative images can be applied with a null alt (alt=””) or tagged as decorative only.
  • Use images minimally and with purpose.
  • If you use images to enhance written information, use real people and locations, where possible.
  • Most users typically ignore decorative images.
  • Do not use images with text in unless it's a logo.

Graphics and data (infographics)

Graphics should be clear and easy to understand. Check that the correct colour contrast ratio has been used and remember to provide alternative text. If a graph is in the image, descriptive alternative text needs to explain what the image demonstrates.

When writing alternative text for online content, you need to keep your description brief – preferably under 100 characters. However, if you have a complex diagram or graph that has multiple concepts, you should describe these fully. Alternative text can be provided in the code as screen reader only content. Preferably a graph would use a plug in such as Highcharts which reads out the content of the graph as part of the product design.

If 100 characters is not enough to describe the content effectively, a text description of the content can be provided in a link. When writing alternative text in a program like Microsoft Word or Adobe InDesign, you can provide longer descriptions.

Tables

  • Tables should only be used for displaying numbers and figures.
  • Accessible tables need HTML mark-up that indicates header cells and data cells and defines their relationship. Assistive technologies use this information to provide context to users.
  • Tables must have captions.
  • Complex tables should be broken into more than one table. Header rows and columns should have the following HTML mark up, by using scope="col" and scope="row".
  • All tables should have:
    • A summary provided in the HTML code, describing the table.
    • A caption (this can also be provided for screen reader users only).
    • Headings applied (H1/H2/H3), and not bold (<strong>Tables should be checked across devices to ensure they are displaying correctly. They should also be tested with a screen reader to ensure they are announcing correctly.

Tables should be checked across devices to ensure they are displaying correctly. They should also be tested with a screen reader to ensure they are announcing correctly.

Helpful links

Video

  • Caption video and where appropriate provide audio descriptions and Auslan visual communication.
  • Write transcripts in plain English.
  • Captions are the text version of speech and other audible content that appears on videos, and are used to communicate with people who are deaf or hearing impaired.
  • Audio description is an audible narration of visual representations such as television programs, films and live performances. During gaps of dialogue it describes visual elements such as scenes, settings, actions and costumes to the viewer.  

For longer content (for example instructional or educational "how to" content) it is recommended that:

  • content is broken down into shorter segments to make content easier to digest; or
  • viewers can easily navigate through content for better usability (for example using clearly defined bookmarks so that a person can choose what to view).

Research

Research reports and papers, evaluation studies and literature reviews may be long and unwieldy for non-specialised readers. When publishing this kind of material on your intranet or public-facing websites, it is important to provide a plain language summary. 

Readers can then decide if they would like to read the document. The document itself should be published in an accessible format, with an alternative to PDF provided.

Social media

While the accessibility of third-party social media platforms cannot be controlled, agencies should ensure that the use of social media considers the needs of our audience. For example, ensuring that all videos published are captioned with textual representation of the audio content within the video.

Social media applications should be configured to enable and use any accessibility features for example, X (formerly known as Twitter) has an alternative text option for images.

Make sure that all documents shared publicly are accessible – that means that if someone shares a file, or a link to a file, we know that the widest range of people will be able to use it.

When people follow links to your websites, you can make sure that the web pages are accessible and that alternative formats are available.

Web pages 

Present web page content that is clear and easy to understand using text that is broken up into digestible chunks with good, descriptive headings. Providing plain language summaries about complex information is a helpful way to connect with your website users and let them decide if they would like to read more.

Use responsive design methods to design content that adapts to a range of devices and screen sizes, and to test on the full range of browsers and platforms that your audience may be using.

  • Headings that ‘tell a story’. 
  • Headings are marked up correctly and logically (H1>H2>H3).
  • Tables and lists are marked up correctly.
  • No instance of moving, blinking or scrolling that starts automatically. 
  • Focus order has been reviewed. 
  • Focus style is visible.
  • Descriptive and unique page titles.
  • Skip to content links are available.
  • Skip mega menu links are available. 
  • Give users enough time to read and use content. For example: No content that flashes more than 3 times a second. 
  • All functionality is accessible with a keyboard.
  • Web pages have a meaningful sequence when navigating through them.
  • Colour contrast has been assessed.
  • Colour was not used as the only means if displaying information. 
  • Images have appropriate alternative text.
  • Link purpose.
  • Multiple ways are provided to navigate the website.
  • Buttons and other controls (such as form fields) are labelled correctly.
  • Language is assigned to the website.
  • Content is written in plain English with a reading age less than grade 8.
  • Is compatible with current and future user tools, such as a screen reader.

Archived web pages

Ensure archived web pages are clearly marked as archived and include accessible instructions on how a user can request an accessible version of its content.

Website owners are strongly encouraged to audit their site’s content to identify those web pages that contain redundant, out-of-date, or trivial content. In most cases, such pages should be either updated or removed from the website. However, in some instances there may be value in retaining them on the website, but not in maintaining or updating them, in which case they should be marked as archived web pages.

Timing out

There should be adequate time for people to complete a task online. 

  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times.

Helpful links

Frequently asked questions and fact sheets

Frequently asked questions (FAQs) should be avoided for the following reasons:

  • Date easily.
  • FAQs are removed from context and can lead to extensive answers and confusion.
  • Topic is hidden inside a question that may or may not be relevant to the reader.
  • Makes page scanning slower.

Instead of writing FAQs, write answers to important questions in the correct context where the user will expect to find them. Using active voice, highlight them as key messages rather than questions.

Group questions under topics for quick reference and regularly update them using feedback from other sources to ensure they are relevant and reflect the latest key messages for an end user.

Requirement 7.3: A digital service must provide a comparable experience for all without undermining the quality of the content

Circumstances, choices and environments can have an impact on how people interact with information and technologies. 

Regardless of how a person chooses to access or interact with government information and services, the service they receive should be comparable in value, quality, and efficiency. 

Be consistent 

Use consistent web and platform design patterns to help build familiarity and understanding.

Use plain language consistently across platforms including content that is relied on by screen reader users such as text alternatives, headings, labels for buttons. 

Use consistent page architecture across templates to help people scan and navigate key content.

Provide alternative formats

Alternative types of content should be provided wherever possible or, as a last resort, upon request. 

Clearly communicate agency contact details for users who are unable to download content or documents.

It’s important to remember that not everyone uses digital content in the same way. We all have preferences for the way we browse online, save our files, write our emails or view social media. Allowing flexibility and control for the user is at the heart of providing alternative formats.

It is important to consider alternative formats because:

  • Not everyone is using the latest version of the software that you might be using in your work, or they may not own proprietary software like Microsoft Office.
  • Some people use assistive technology, such as screen readers, mobile apps and magnifying software to help them access digital content. There are vast differences in the way these kinds of tools operate and you can’t be sure that every product you produce will be used the same way with each tool. For this reason, alternative formats are essential. 
  • Some people with sensory disability require alternative formats that meet their needs. For example, some people require Braille versions of text, audio files that read content aloud, or text descriptions of audio content.
  • Some people with a range of disabilities, learning needs and cognitive conditions such as dyslexia require content in a simple, clear format like plain language or easy read. Alternative fonts and large text sizes can be incredibly helpful in some situations.

You may also consider the use of text-to-speech software such as ReadSpeaker or texthelp. You can read more about how to create content that works well with screen readers on the UK Government Digital Service blog.

Providing an accessible alternative format supports an agency's broader business continuity and disaster recovery strategy, where a service can still be available in an offline format when an online service is disrupted for any reason. 

PDF 

Only publish accessible PDFs, and provide an accompanying alternative format, such as HTML or an accessible Word document.

No scanned PDFs should be published unless an alternative is provided. Scanned PDFs should be OCR scanned. 

Refer to making sure PDFs are accessible for more information about the requirements for an accessible PDF in section 7.2.

Languages other than English 

Alternative formats can also include content in languages other than English.

If you are producing multi-language translations, remember that writing your content in plain language saves time and money when translating. If your multi-language translations are provided in PDFs, they need to be fully accessible. Your translation supplier should ensure that WCAG compliant PDFs are provided. Refer to the WA Government Language Services Policy.

Requirement 7.4: Digital services must allow for assistive technologies and methods

Assistive technologies allow the user the opportunity to change the content and use it in a way that meets their needs. This might include offering the ability to provide a printable version of a web page and the use of tools such as apps that read content aloud.

Examples of common assistive technologies are screen readers, screen magnifiers, voice recognition and keyboard navigation. People use different combinations of assistive technology and adaptive strategies to use government services.

WCAG covers the mandatory requirements to meet A and AA compliance to ensure compatibility with assistive technologies.

The Centre for Accessibility Australia also provides guidance on how people with a disability engage with content.

Assisted digital support

As a minimum, ensure non-digital users can access the help they need to use the service.

Consider individuals who may not have online access or face barriers preventing them from interacting digitally and may require alternative offline options. Assisted digital support can be delivered in many ways, including:

  • Online, with access to appropriate support.
  • Over the telephone, with someone guiding the user through the service or inputting information into a system on their behalf.
  • In person, at a service centre.
  • Via video conferencing (from a shopfront or from the user’s location).
  • Through an authorised representative of the person assisting or acting on their behalf.

Helpful links

Requirement 7.5: Agencies must regularly test and review digital services

Test digital products at regular intervals, both before they go live and afterwards, to make sure that:

  • They work well with the relevant browsers, platforms and devices.
  • Users can perform the relevant tasks and actions can be completed.
  • The relevant criteria in the Standard have been met.

Accessibility testing should be part of this process, including:

  • Testing with accessibility software.
  • Testing with assistive technology.
  • Testing with a broad range of users, including people with diverse abilities.
  • Testing teams should be independent of the delivery team if possible.

Validate by testing with users

Understanding how people use your digital products and testing with users is an essential part of making sure that digital products meet the needs of the intended audience.

Usability testing helps establish how well a digital service works by watching how users actually use it. You should research and define user needs as well as test at key points during the design and development process and before releasing a service to identify problems and fix them.

Some simple points to validate with end users include:

  • Can people easily complete key tasks?
  • How quickly can people complete those tasks?
  • Can people complete the task on their first try?
  • What distractions or barriers do people face? Can you remove those?
  • After using the service once, can a person remember enough to use it effectively the next time?
  • How much do people like using your service?

Use responsive design methods to design content that adapts to a range of devices and screen sizes, and to test on the full range of browsers and platforms that your audience may be using.

The UK Government Digital Service Standard has a guide to setting up, running and reporting on user testing sessions.

Verify with a specialist audit

An accessibility expert can test digital products.

The Digital Transformation Agency provides advice on:

  • Stocktaking the service for purpose, structure, formatting and technology.
  • Assessing your internal capability.
  • Agreeing on the scope and the audit methodology.
  • Preparing your report.

For more information visit the Make it accessible webpage. 

Report, fix and review

Reporting, fixing, and reviewing are ways of ensuring that best-practice web accessibility is achieved both when launching a new product and when maintaining existing products.

Maintain high levels of digital accessibility by:

  • Scheduling ongoing testing regularly and consistently.
  • Fixing inaccessible content as quickly as possible.
  • Planning for and conducting future reviews.

Ensure end users can report accessibility issues and that they are addressed in a timely manner.

Accessibility statements

The Digital Services Policy Framework states that it is mandatory to provide an accessibility statement on all websites.

Example of an accessibility statement: the WA.gov.au website accessibility statement.

Helpful links

References and sources

This guide was developed in consultation with a cross agency working group. We have also been closely guided by and used content from the:

Other guides consulted:

Other helpful guides:

Documents

Have a question or want to report a problem?

Fill in the form to get assistance or tell us about a problem with this information or service.

Send feedback