A guide for the Australian government in making its digital services accessible, WCAG 2.2 For Government AU is meant to be put to practical use. The onus is on agencies to comply with their service-design, procurement, policy and legal duties and to make of WCAG 2.2 Level AA a working standard.
One should not mistake WCAG 2.2 for a checklist for web developers. It has implications for third-party platforms, support channels, authentication, payment processes, documents, mobile as well as online forms and portals. Put simply, the aim is that those with a disability do not have to contend with an interface before they can get their business done with the government.
Australian Government Accessibility
In Australia, digital accessibility is about equal access, usability and inclusion. The technical side is covered by WCAG 2.2 and national digital accessibility standards, but it is Australian law and policy that dictate how an agency puts this into effect for public services.
Olivia Redfern would put it in plain English: a service is not fit for purpose if the only way to get something done is with a mouse, unimpaired vision, a fast connection and a quiet room. There are people who will be using screen readers, voice control, magnification, keyboard navigation or captions; the service has to accommodate them.
The Realities of WCAG 2.2
The W3C has set out testable criteria for web content in the Web Content Accessibility Guidelines, all underpinned by four principles of being robust, understandable, operable and perceivable.
Conformance is measured in three levels. Level A deals with the most elementary of barriers. For any public-facing service from government, Level AA is the norm as it is more comprehensive. Then there is Level AAA with its extra criteria which one does not normally need to adhere to in full.
Why it is important is that disability is not an exception in Australia. An estimate from the ABS is that some 20 per cent of Australians have a disability, be it physical, sensory, intellectual, psychosocial or cognitive, or that their needs have been altered by age, illness or other circumstances.
Compliance with WCAG 2.2
Projects in Australia should be concerned with the whole of the user journey, not just a screen or two. A well made home page is no compensation for a form that discards your data, a PDF you cannot have read back to you or an identity check that a keyboard user cannot negotiate.
The best way to go about it is to chart the key tasks, see where a person might be put off and put it to the test with assistive technology and actual users. This is a matter of quality in the service, not something to be tidied up at the eleventh hour.
Level AA in practice
Government services and websites are expected to have good colour contrast, text alternatives for non-text, headings in order, form labels that are accessible and navigation you can rely on. Enlarge the content and it should reflow and still be of use on a small screen.
You must be able to operate every interactive control with a keyboard and have it visibly focused; there is no room for a mouse. Menus, pop-ups, date pickers and the like should not be a trap for the keyboard user.
Forms call for some attention. Have a label programmatically linked to each field, give clear directions and error messages and let the user put things right before he submits. Should a session time out, the service ought to explain and save what work has been done if it can.
WCAG 2.2 is also insistent on such things as target size, focus visibility, dragging and redundant entry. They may seem like minor points until you are on a phone with one hand trying to put in an urgent change or upload evidence.
Laws and Policies in Australia
WCAG 2.2 is part of the broader accessibility picture. Agencies have to take account of the Disability Discrimination Act 1992, the requirements of contracted service providers, departmental policy and the like.
No amount of fine print will render a website compliant. What is required can differ between statutory authorities, state and territory bodies and Australian Government entities, and legal standing is a function of the service and the complaint.
Law, Policy And Procurement
Under the 1992 Act it is unlawful to discriminate on the basis of disability in the supply of goods and services. To put a barrier in the way of a disabled person wanting to use an essential service is an operational and legal risk.
As for the Digital Service Standard of the Australian Government, that is the framework for delivery and policy. Agencies are well advised to refer to official guidance, including the Australian Government Digital Service Standard guidance, to be sure of the latest version and any particular departmental demands.
And when it comes to procurement, the requirements are as important as anything done in house. One does not have to look far for what should be in a contract covering identity services, document platforms, customer portals, websites or software: provisions for ongoing testing, defect handling, evidence and accessibility conformance. “The supplier said it was accessible” is no test method; it is the sort of thing that has a way of looking foolish in time.
An accessibility statement ought to be put out by agencies as well. Done with candour and in plain sight, it will set out the service’s conformance target, how one goes about reporting issues and what response times are to be expected, along with any limitations and alternative means of contact.
WCAG 2.1 And WCAG 2.2 Compared
In putting together WCAG 2.2 there has been no wholesale replacement of the underlying structure, only an extension of it. While work done to WCAG 2.1 AA standards still has its worth, agencies would do well to go over the new criteria and see if their design systems, test scripts and procurement language need amending.
It is not as though every service is called on for a ground up rebuild. What has changed is that some interaction problems of long standing are now dealt with in a more forthright manner. The first order of business for teams is to gauge the impact on those journeys that are high volume and carry high consequence.
Some of the changes in WCAG 2.2 can catch teams off guard
| WCAG 2.2 area | What it means in practice | Common government example |
|---|---|---|
| Focus Not Obscured | In practice this means keyboard focus is not to be obscured by a sticky header or banner. | Take a form field in a protracted application: it should stay in view as the user makes his way through it. |
| Focus Appearance | There must be adequate contrast and visibility to the indicators. | One should be able to tell at a glance which button or menu item is in use. |
| Dragging Movements | An action should not be contingent on dragging. | There will be buttons or some other single-pointer option available for a map control or slider. |
| Target Size | Reliable activation requires controls to be of a certain size and not bunched up. | You will not find small mobile buttons on top of each other like sardines. |
| Accessible Authentication | A sign-in process must make do without memory tests or visual puzzles. | It will accommodate password managers and assistive technology. |
| Redundant Entry | If a postal address has been given, the process should not call for it to be entered once more. | A postal address is not requested again after it has already been supplied. |
Then there is the matter of obsolete success criteria such as “Parsing” which WCAG 2.2 has done away with, given the evolution of conformance practice and technology. That does not mean valid code can be dispensed with; semantic HTML is good for compatibility and maintenance.
A Plan For Adopting WCAG 2.2
Any adoption plan worth having will be driven by the risk profile of the service, not by convenience. Put priority on those with large user bases or where a misstep has financial, legal or health implications, or which are tied to essential benefits and payments.
Keep the pilot small enough to be instructive but not so as to sidestep the hard parts. A brief but typical journey through a service is more revealing than a wide ranging survey of a few thousand pages.
Compliance In Practice
- Record your conformance target, typically WCAG 2.2 Level AA, and note any exceptions with the owner and a review date.
- Do an audit of the whole service, from search and account set-up to forms, uploads, payment and the confirmation email, using both manual and automated review. The latter will pick up some code and contrast deficiencies but they are not equipped to say if instructions are sensible or the journey is in fact usable.
- Put it through its paces with screen readers, zoom, voice input, mobile and keyboard navigation.
- When you come to rectify component or design-system faults, do so centrally; an accessible button is of greater value when all services can have it.
- Retest when there is a change of content, infrastructure or supplier. Conformance is a function of release management, not something you put behind you after an audit.
The mistake most teams make is to consider it a front-end concern. It is a question of governance, policy and data as much as anything. An interface cannot make up for an intractable eligibility rule or an evidence requirement that is not accessible. A well written error message in plain English is as necessary as proper ARIA.
On Documents And Apps
For a PDF to be accessible it will have real text, a heading structure of meaning, tagged reading order, tables that make sense and enough contrast. Do not assume a scanned form is the answer; even with optical character recognition a check is in order.
WCAG pertains to the web so native apps call for platform-specific testing but the principles are the same: gestures must have an accessible equivalent, content an alternative, and controls a name and state.
The same goes for third-party tools. A chat widget or payment tool can put up barriers on an otherwise sound page. Procurement should insist on a conformance report and a workable way of dealing with defects.
Testing And Monitoring Conformance
For a government website to be in compliance with WCAG one has to put in place a tiered testing regime. While an automated scan is quick and will turn up its share of accessibility issues, it is no substitute for the manual and user testing that tells you if a person can see a task through to completion.
It is best to test at every stage: in design, before procurement, as development proceeds, pre-launch and in the wake of any significant changes. To leave it to the final release is like checking your tyres after a run on the Stuart Highway; you can do it but there is no need for the tension.
People And Tools In Conjunction
An effective plan will have you inspecting code and documents, running contrast and responsive checks, testing in the browser and with assistive technology, and using the keyboard alone. Do not confine yourself to single pages, make the journey realistic. Factor in what happens when a session is interrupted or expires, when an upload does not go to plan or there are validation errors.
There is particular value in putting the service in front of users with a disability. An experienced developer will know where the controls are and how the interface is meant to work and so may overlook a barrier. Properly briefed and compensated testers should be given the opportunity to put a name to the impact of those barriers.
One way to spot the things a monthly automated scan is blind to is to keep an eye on complaints, support calls, failed submissions and abandonment. Log them by severity, owner and date, and note the effect on the user and the journey.
Dealing With Accessibility Barriers
You will find legacy systems, content that is not consistent, supplier dependencies and complicated approvals in many a government service. None of that makes accessibility a matter of choice, though it does call for good governance and some realism in the sequencing.
The prudent thing is to lower the risk and better the service in public. If there are still important barriers in place, do not put forward the claim of perfect compliance; be forthright about what the limitations are and put an alternative contact method in their stead.
A Question Of Expectation And Reality
You might expect a clear result from an automated scan to mean the service is accessible. In reality the scanner will let poor instructions, a confusing order of things, keyboard traps and inaccessible PDFs pass by.
Or that ARIA is the answer to fix the interface. It can enhance custom controls but if done wrong it will only make matters worse. Put in native HTML first and resort to ARIA when the semantics and behaviour warrant it.
Some would say accessibility is for those with a permanent disability. The truth is it is of use to anyone with a broken screen, limited bandwidth or low digital confidence, as well as temporary injuries and the like.
And while a phone-only option may seem to be an adequate alternative process, in practice it puts the onus on someone who is already being put out. The digital route ought to be made accessible.
WCAG 2.2 Adoption FAQ
We have put together these answers for the questions that tend to impede accessibility projects in the Australian government. As obligations under policy and the law can vary from one agency or jurisdiction to another, teams would do well to check for themselves.
What Is WCAG 2.2?
The W3C’s recommendations for web content to be more accessible to people with disability. They are testable and pertain to the four principles of robust, operable, understandable and perceivable content, code and interaction.
Is it Mandatory For Australian Government Websites?
Do not look for a universal rule of identical WCAG wording for every site. But agencies have to take account of departmental policy, the Disability Discrimination Act 1992 and any service-specific duties. Level AA of WCAG 2.2 is the sensible goal for new or overhauled public services.
What Level Does The Government Require?
Level AA is the de facto conformance standard for most digital services. Make sure you have the current requirement for your entity on record and document any exceptions; it is not an excuse to disregard other user needs.
How Has WCAG 2.2 Changed From 2.1?
Criteria have been introduced for target size, focus visibility, dragging alternatives, redundant entry and authentication, to name a few. The old Parsing criterion has been done away with. This means component libraries, test cases, audits and contracts with suppliers need updating.
Compliance For Government Services
Map the user journeys in full, employ semantic HTML, get the documents remediated and have people with disability involved. Test for screen readers and the keyboard. Once released, monitor the service. Have an accessibility statement on hand that lays out your approach and gives a means to report any problems.
Does this apply to mobile apps and PDFs?
WCAG is a web standard for the most part, but a native app will require its own platform checks. If a form or evidence document is not accessible then neither is the service, even if the page itself is. PDFs and other downloads must be made so.
Habitual Accessibility
Adoption of WCAG 2.2 in Australia is served best by making it routine in quality assurance, content publishing, procurement and design. The programmes that count are ones that measure whether a user can do what he or she needs to do without help, and that listen to people with disability to put right any recurring patterns.
The bottom line for Australian government digital accessibility is to have an understanding of the legal side, to test the entire journey and to continue to improve post-launch, all with an eye to WCAG 2.2 Level AA. National standards are only of consequence when they become an accessible service for someone in need.
SEO Title
WCAG 2.2 Australian Government
Meta Description
Practical steps for adopting WCAG 2.2 in Australian government services, covering Level AA, legal duties, testing of PDFs and apps.