Public websites are how most South Australians deal with government and councils: paying rates, finding services, lodging requests and reading decisions. If those sites are hard to use with a keyboard, a screen reader or a phone, people miss out — and agencies take on legal and reputational risk. This guide explains what WCAG 2.2 Level AA means in practice for SA Government and council websites, what tends to fail audits, how to write accessibility into tenders, and how to keep compliance after go-live. It is practical guidance, not legal advice. Always check the version of WCAG and any agency policy named in your project documents.
Why accessibility is on the procurement checklist
Australia’s Disability Discrimination Act 1992 expects services — including information published online — to be available on equal terms where it is reasonable to do so. The Australian Human Rights Commission recommends organisations aim for WCAG 2.2 Level AA as a minimum benchmark for digital accessibility. Commonwealth digital standards also point agencies to the latest WCAG version; SA agencies and councils commonly state on their own sites that they strive for WCAG 2.2 AA.
For buyers, that usually shows up as:
- A statement of requirement that names WCAG 2.2 AA (or “the latest WCAG AA”)
- Evaluation criteria that ask for an accessibility approach, testing evidence or an accessibility statement
- Acceptance criteria before go-live, not only a promise in a proposal
For Adelaide ICT suppliers, being able to design, build and evidence WCAG 2.2 AA is a concrete differentiator on website renewals and CMS migrations. See our CMS migration checklist for how accessibility fits a content move.
WCAG 2.2 AA in plain English
WCAG (Web Content Accessibility Guidelines) is maintained by the W3C. Version 2.2 was published in October 2023. Conformance has three levels: A, AA and AAA. Most Australian government guidance treats Level AA as the working target: you must meet all Level A and Level AA success criteria that apply to your content.
The guidelines are organised under four principles — content must be perceivable, operable, understandable and robust. In day-to-day website work that means things like:
| Principle | Examples buyers care about |
|---|---|
| Perceivable | Text alternatives for images; captions for video; contrast that meets AA ratios; content that reflows on small screens without loss of meaning |
| Operable | Full keyboard access; visible focus; enough time to complete forms; no content that flashes dangerously; clear skip links and page titles |
| Understandable | Consistent navigation; readable language; helpful error messages; labels that stay associated with fields |
| Robust | Valid, semantic HTML so assistive technologies can parse the page; name, role and value exposed for custom controls |
WCAG 2.2 added success criteria that matter for mobile and motor impairment — for example tighter expectations around target size, dragging alternatives and accessible authentication. If your last audit was against WCAG 2.0 or 2.1 only, plan a gap review against 2.2 before you claim conformance.
What SA agencies and councils usually require
Requirements vary by organisation. Common patterns we see on SA public-sector website projects:
- Named standard: WCAG 2.2 AA (sometimes worded as “current WCAG AA”)
- Mobile and tablet use: sites must work on phones and tablets, not only desktop
- Documents: PDFs and Office files are a frequent weak spot; many agencies still publish PDFs and offer alternative formats on request
- Accessibility statement: a public page explaining known issues and how to ask for information another way
- Disability Access and Inclusion Plans (DAIPs): council and agency plans often include digital actions that website projects should support
Confirm the exact wording in the RFT, panel RFQ or internal business case. Do not assume every SA entity has identical acceptance tests.
Failures that keep showing up in audits
Automated scanners catch some issues; they miss many others. Recurring problems on government and council sites include:
- Low contrast on buttons, footer links and text over hero images
- Missing or poor alternative text, including decorative images announced as useful content
- Keyboard traps in mega-menus, date pickers, maps and cookie banners
- Invisible focus after designers remove outlines without a visible replacement
- Form errors that only change colour, or that are not announced to screen readers
- Custom components (tabs, accordions, carousels) without correct roles, states and keyboard behaviour
- PDF-only content that is not tagged, or that is a scanned image of text
- Reflow and zoom problems when users enlarge text or view content on a narrow phone
Fixing these early in design and component libraries costs less than remediating a launched CMS.
How to write accessibility into a tender
Buyers get better outcomes when accessibility is specific and testable:
- Name WCAG 2.2 Level AA (or the latest WCAG AA) in the statement of requirements
- Ask for a short accessibility approach: how design, build and content roles will meet the criteria
- Require evidence before acceptance: for example a sample page audit, assistive technology testing notes, and a plan for known exceptions
- Include content migration rules so old inaccessible PDFs are not simply copied across
- Budget for author training and an accessibility statement, not only engineering
- Ask how the supplier will handle third-party embeds (maps, videos, chat widgets) that often break conformance
Suppliers should answer with method and evidence, not slogans. “We build to WCAG” without a testing plan is hard to score.
A practical delivery checklist
- Agree the target standard and any approved exceptions in writing at project start
- Design components (header, forms, alerts, cookies) accessibly once; reuse them
- Treat online forms and payment pages as the highest-risk journeys and test them end to end (see our guide to online forms and payments for SA councils and small businesses)
- Use semantic HTML and test with keyboard only before visual polish
- Run automated checks in CI, plus manual checks with a screen reader on key journeys (our software testing and UAT guide shows how to build both into a test plan)
- Test on small phones and foldable widths, not only a desktop browser
- Remediate or replace high-traffic PDFs; offer HTML alternatives where practical
- Publish an accessibility statement and a contact path for issues (phone is fine; avoid publishing personal staff emails on the site)
- Plan content governance so new pages do not undo the uplift
Our website design and application development work treats WCAG 2.2 AA as a delivery standard, not a bolt-on. For broader tender preparation, see winning SA Government ICT work and our capability statement.
After go-live: keep the bar
Accessibility regresses when editors paste from Word, add unlabelled media or install a new plugin. Sensible operating habits include periodic spot audits, a short author checklist, and regression tests on templates after CMS upgrades. If you use AI features on the public site (for example a chatbot), those interfaces need the same keyboard, focus and labelling discipline as the rest of the site.
This article summarises commonly cited Australian and SA practice as at late 2026. Policies and WCAG versions change — verify the current W3C recommendation and your agency’s digital accessibility policy before you lock requirements or claim conformance.
Talk to an Adelaide team
If you are scoping a council or agency website renewal, accessibility uplift or CMS migration, discuss your project with our team or call 0402 401 584. We reply within one business day.