- Meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1.
- Publish content in HTML first and provide an alternative format for non-HTML formats.
- Make all types of content accessible, including PDFs, Word documents, images, video and audio.
- Write using plain language. Aim for a reading age below grade 9 unless there is a clear need for technical language.
- Develop a digital services accessibility plan that outlines how services will meet accessibility requirements.
- Test your design, code and content regularly during development.
Make digital services accessible
Ensure the service is accessible and inclusive of all users regardless of their ability and environment.
You need to make sure everyone who needs your service can use it. This includes people with disability and older people, and people who can't use, or struggle with, digital services.
Your service must be accessible to users regardless of their digital confidence and access to a digital environment. This includes users in remote areas and users with different devices.
You also have a legal requirement to ensure your service is usable and accessible to people with disabilities (see the Disability Discrimination Act 1992). Queensland Government agencies are required to meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1, which includes Level A (see mandate in Digital services policy). Conforming to WCAG 2.1 means you also conform with 2.0.
You should have an accessibility plan/s for ensuring new and existing digital services are accessible within time frames outlined in the digital services assessment framework and the transition plan for the digital services policy. This may be agency-wide or for individual digital services and may be separate or incorporated into other planning processes.
In Discovery stage
During the Discovery stage you will have developed a good understanding of how your users may access your service. To make sure everyone will be able to use your service you need to show:
- the type of environments users may access the service in, including with different browsers and desktop and mobile devices, and when connections are slower and there may be limited data (for example, through user stories)
- diversity in research recruitment and targeted users, including people from different cultural backgrounds and people with disability
- consideration of situational and environmental limitations that affect a users ability to access the product
- the plan to meet accessibility requirements in the design of the product (for example, how it will meet Web Content Accessibility Guidelines (WCAG) 2.1.
- what digital assistance might be needed to support users (for example, web chat, telephone assistance, face-to-face, clear instructions, checklists, and so on).
In Alpha stage
During the Alpha stage:
- your prototypes can accommodate users from different backgrounds and users with disability
- any accessibility issues and barriers might need addressing in the Beta stage
- you have access to facilities to perform testing on various devices or platforms (for example, a plan for testing)
- the procurement of any platform or service whether paid or unpaid is in line with the Accessibility compliance in procurement ensuring accessibility for people with a disability guide.
In Beta stage
During the Beta stage you will be developing your service and you must make sure accessibility requirements and needs of all your users are being met.
This may include:
- iteration in the design and content of your service to meet accessibility requirements and improve usability for people with disability
- non-digital access and support for people unable to use, or struggling with, the digital service
- end-to-end user journeys, including assisted digital journeys, and demonstrate that they work and how you tested them
- how you've included cultural and linguistically diverse communities in your design
- a plan to include translation for non-English speaking audiences, as appropriate
- you have testing environments, systems and approaches for non-digital parts of the service, including assisted digital routes (for example, a testing plan)
- how the service will perform under expected loads, including assisted digital routes
- strong understanding of the environments your users may access the service in, for example which browsers, desktop and mobile devices they will use, and which remote locations; you might use user stories and a journey map to show this
- definition of supported browsers and devices, and how they are accommodated
- any barriers to the digital service and its content on mobile devices, and plans to address them
- the design requirements for users using a mobile device and other identified environments (for example, design specifications)
- how you have tested for the users ability to complete all digital transactions on supported devices and platforms
- detail of users interactions with the product during testing
- a demonstration your service in a live-like environment
- the majority of users can access the service in their environment.
As you launch publicly you should be able to show:
- your service is accessible
- evidence that your service meets Level AA of the WCAG 2.1
- evidence of usability testing, including users with low level digital skills, people with disability, and people from different cultural and linguistic backgrounds
- a run through of how you've designed and tested for users of assistive technologies based on user research, usability testing and analytics
- ongoing testing plans for accessibility so that your users can continue to access the service.
WCAG and techniques
- W3C Accessibility Fundamentals Overview
- W3C Web Content Accessibility Guidelines (WCAG) 2.1
- World Wide Web Access: Disability Discrimination Act Advisory Notes version 4.1 (2014)
- W3C PDF Techniques for WCAG 2.0
- Centre For Accessibility What is the WCAG Standard?
- Queensland Government Web writing and style guide (section 15)
- Accessibility and inclusion Style manual, Australian Government
- Consistent User Experience standard Module 6 Non-HTML documents
- Consistent User Experience standard Module 4 Online forms
- Consistent User Experience standard Module 7 Online video
- Australian Government PDF (Portable Document Format)
- Why GOV.UK content should be published in HTML and not PDFUK.GOV
- Accessibility and inclusivity NSW Government
- Online accessibility toolkit South Australia
- Accessibility guidelines for government communications Victorian Government
- O365 Make your content accessible to everyone
- W3C Making Content Usable for People with Cognitive and Learning Disabilities
Easy read documents (examples)
- Easy Read how to create
- Easy read DFV information for women with a disability
- Easy read guide to the Anti-Discrimination Act
- Victorian Government State Disability Plan 20222026
- Australia's Disability Strategy 2021-2031 easy read copies
- W3C Web accessibility perspectives videos: explore the impact and benefits for everyone
- W3C Digital Accessibility Foundations Free Online Course
- Professional Certificate in Web Accessibility, University of South Australia
Statistics and user research
- Web AIM Screen reader user survey #9 results
- Australia's adult literacy crisis, Adult Learning Australia (Opens in new window)
- Programme for the International Assessment of Adult Competencies (Australia), Australian Bureau of Statistics
- Dyslexia in Australia, Australian Dyslexia Association
- Experience the web as personas with access needs UK.GOV