Read time: 4 minutes 20 seconds

The Web Content Accessibility Guidelines (WCAG) are recognised internationally as a set of recommendations for improving web accessibility.

WCAG 2.0 and  WCAG 2.1 explain how to make our online services accessible for people with disability and older people. The guidelines are written by accessibility specialists, volunteers and people with disability at the World Wide Web Consortium (W3C).

WCAG also helps us think about the different ways people use the web by:

  • changing the way a website looks in their browser
  • using a keyboard instead of a mouse
  • using a screen reader to navigate and present the website content as speech or on an electronic Braille display
  • using a screen magnifier to increase the size of everything on-screen
  • using speech recognition to use the web with voice commands and dictation

Meeting government accessibility requirements

To meet the South Australian Government Online Accessibility Policy, all new or significantly updated applications must:

  • meet level AA of WCAG 2.0 and  WCAG 2.1 as a minimum
  • work on the most commonly used assistive technologies - including screen magnifiers, screen readers and speech recognition tools
  • include people with disability in user research (Digital Service Standard Criterion 10: Test the service)

WCAG design principles

WCAG design principles are supported by 12 guidelines, grouped into four principles:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

Each of these is broken down into specific requirements (or ‘success criteria’) that your online service needs to meet.

During development, you need to complete regular accessibility testing to check your design, code and content meet WCAG level AA.

To do this, you can use a combination of automated tools and manual tests (including those listed in the accessibility checklist created by 18F) to identify potential problems in meeting all A and AA success criteria.

The ideal way to provide evidence that your service meets level AA is to get an accessibility audit.

Applying WCAG guidelines

WCAG 2.1 was designed to better meet the needs of three major groups:

  • mobile users
  • users with low vision
  • users with cognitive or learning disability

Conformance to WCAG 2.1 level AA is encouraged at this time. To meet level AA you must be able to answer 'YES' or 'Not Applicable' to all of the following questions.

Answering 'NO' means that you might not be meeting WCAG 2.1 Level AA and your content will have barriers that will prevent some users, especially users with disability and older people from accessing it.

  • Perceivable

    • Do all images have an appropriate text equivalent? Is essential visual information also available as text?
    • Do all audio files have a transcript? Is essential audio information available as text?
    • Do all videos have captions that are synchronised with the audio?
    • Does video that includes important visual information have an audio description?
    • Is all content structure that is communicated visually available to assistive technologies?
    • If styling is removed is the content in a logical order?
    • Have you avoided using visual characteristics to communicate information?
    • Have you avoided using colour as the only way to convey some information?
    • Can users stop audio that auto plays?
    • Does all text have sufficient contrast against the background colour?
    • Is the content fully usable when text is enlarged up to 200%?
    • Have you avoided using images of text?
    • Can users flip the content horizontally and vertically?
    • Have you added HTML autocomplete tokens to any forms collecting information about the user?
    • Does the page content resize to a single column with no horizontal and vertical scrolling?
    • Do all important graphical objects, interface components, and states have a colour contrast of 3:1?
    • Can line height, spacing between paragraphs and letter and word spacing be changed without breaking anything?
    • Where extra content is shown or hidden on focus, can it be dismissed, interacted with (and not disappear when the user moves to it) and will stay visible until dismissed by the user?

    GOV.UK: what to do and common mistakes (Perceivable)

  • Operable

    • Can all menus, links, buttons, and other controls be operated by keyboard?
    • Do pages that have time limits include mechanisms for adjusting those limits?
    • Can any content that moves or auto updates be stopped?
    • Have you avoided using content that flashes or flickers?
    • Can blocks of links and other interactive elements be bypassed by keyboard users?
    • Does each page have a unique title that indicates its purpose and context?
    • When using a keyboard to move through a page does the order make sense?
    • Is the purpose of every link clear from its link text?
    • Does the website have two or more ways of finding content, such as a navigation menu, search feature, or site map?
    • Are headings and labels clear and descriptive?
    • When using a keyboard to move through a page can you tell where you are?
    • Do you have shortcuts triggered by only one letter or character? If so can they be turned off or remapped by the user?
    • Does some of your site functionality need several fingers or complex gestures to operate it?
    • Does some of your site functionality work using a single point (fingertip) and is it triggered the moment it is touched?
    • On forms and other components is the accessible name or label the same as any on-screen text?
    • Does your site respond to motion or movement to operate parts?

    GOV.UK: what to do and common mistakes (Operable)

  • Understandable

    • Have you used plain English?
    • Has the language of the web page or document (or individual parts of a multilingual document) been defined?
    • Have you avoided links, controls, or form fields that automatically trigger a change in context?
    • Does the website include consistent navigation?
    • Are features with the same functionality labelled consistently?
    • Do forms provide helpful, understandable error and verification messages?

    GOV.UK: what to do and common mistakes (Understandable)

  • Robust

    • Is the web page coded using valid HTML?
    • Do all interactive components have an accessible name and role, and when required state? Has the correct ARIA markup been used and does it validate?
    • Are status messages and updates given appropriate roles that can be understood by AT, without receiving focus?

    GOV.UK: what to do and common mistakes (Robust)

Supporting resources

Next page


Last update: 30 April 2019, first published

Content on this page published with acknowledgement.