Australia's Digital Service Standard gets an update
Transcript
7 years is a longtime in government circles. The standards for government digital services to be built responsibly including accessibly has had its first significant update to version 2. That’s right I’m talking about the Australian Government’s digital service standard.
Services covered by the Digital Service Standard (DSS)
With version 2, some former requirements remain, criteria reduced, and accessibility applied more comprehensively. What remains unchanged is it’s still mandatory for government websites and mobile applications, is applicable to both information and transactional services and applies to new and existing public facing digital services.
Implementation timeframes
Implementation timeframes are generous and occur in two phases. New services must meet the new version from 1st July 2024. Whereas existing public facing services have until 1st July 2024 to meet the new version.
As before state, territory and local government don’t need to apply the DSS. If you’re a designer working in state government, you’re not required to follow it. But state and territory governments generally follow what the federal government does so expect to see this adopted over the coming months in some form.
A new requirement
Whilst those requirements are familiar, applying the DSS to staff facing digital services becomes a new requirement. Traditionally users in government departments had a mixed experience with poor inaccessible products. What this means is that a greater emphasis on making the internal digital tools accessible becomes a new requirement.
WCAG versioning no longer followed
Version 2 of the DSS no longer requires following a specific version of WCAG. This is good, as it future proofs the standard and makes it applicable to the latest version of WCAG. So WCAG 2.2 is supported as are future iterations all the way to the yet unpublished WCAG version 3. No longer will the DSS lag behind WCAG versioning and become out of date.
Minimum WCAG conformance level removed
Whilst version one of the DSS required conforming to level AA of WCAG. The conformance level for version 2 is now removed which can be viewed two ways. It either encourages agencies to aim for increasing levels of conformance at triple A and support more diverse users with disabilities or do the bare minimum and aim for single A conformance. I like to remain optimistic and think it’s the former and not the latter.
The new DSS criteria
- Have clear intent
- Know your user
- Leave no one behind
- Connect services
- Build trust in design
- Don’t reinvent the wheel
- Do no harm
- Innovate with purpose
- Monitor your service
- Keep it relevant
Accessibility scattered throughout the DSS criteria
Up to this point, DSS version 2 requirements have been familiar. What’s changed is accessibility is no longer confined to a single criterion but scattered throughout. With 7 of the criteria most relevant for supporting accessibility and inclusive practices.
Criteria 2 know your user
You’re encouraged to gather different perspective and undertake ethical and inclusive user research using co-design wherever possible. User research has been a big focus of the previous DSS version, and this remains. Understand who you’re designing the service for.
Criteria 3 leave no one behind
Understand the diversity of your users, think back to criterion 2 who are you designing for? You need to build a service which complies with the disability discrimination act (DDA), the latest version of WCAG and the Australian Government Style Guide.
You may have designed and built a service with WCAG which is technically accessible, but this doesn’t mean practically usable for a screen reader user. That’s why it’s also important to comprehensively test the service across different devices, different assistive technologies, platforms and integrate their feedback.
Be respectful of user’s bandwidth and data constraints when developing digital services. Australia is an incredibly big country. A React, Angular or Blazor application with significant downloadable dependencies or API calls may not perform well on low powered devices with limited bandwidth in remote locations.
Connectively and low powered device responsiveness are also accessibility concerns.
Criteria 4 connect services
Design for easy connection between government services. If a user is requested to login across many connected services consolidate those logins as much as possible. People can experience reduced cognitive load if they’re required to repeat the same actions multiple times.
Criteria 5 build trust in design
Eliminate ambiguity in your service and provide appropriate validation feedback, progress tracking and provide information a user needs up front. Ensure error messages are understandable and appropriate.
These are all good accessibility principles to follow for inclusive design.
Criteria 6 don't reinvent the wheel
Are there existing platforms and patterns built to accessibility guidelines which can be reused. The former DTA design system was a good example of a common UI asset with accessibility applied that had potential for reuse across many government services.
Criteria 8 innovate with purpose
Choose new technologies appropriately. Will the adoption of anything new adversely affect the accessibility of your service.
Commercial off the shelf products may not have been procured in accessible ways and your service will absorb accessibility debt if adopted.
Criteria 10 keep it relevant
Continuously optimise the service and increase its compatibility. Accessibility is never done. Schedule regular assessments and make sure new features don’t impact existing accessibility.
It only takes 1 poorly implemented chatbot to undermine the accessibility of your service.
Summary
And so, version 2 of the DSS continues the trend of using user research to truly get a picture of your users. It encourages diverse user research with varied audiences and to build responsibility following WCAG, testing assumptions and evaluation with assistive technology users.
Promisingly it includes both public facing and staff facing digital services. Which is a big improvement.
Public service staff with a disability have traditionally had a poor experience where their needs with internal systems weren’t adequately addressed.
Overall, this DSS version is a long overdue update. It adapts to the current version of WCAG and leaves room for agencies to aim for high levels of conformance.
Though for those agencies with limited resources this may mean WCAG single A and the potential for a two-tier web experience across government to develop.
Time will tell how accurate this statement is.