How to manage an accessibility failure

This guide covers the process for identifying and correcting an accessibility failure, when a content editor is requesting to publish content that doesn’t meet accessibility standards.

This guide is for Approvers or people managing publishing requests as part of a federated publishing queue.

The Disability Discrimination Act 1992 requires content creators to ensure people with disabilities have the same access to information and services as others in the community. It is a requirement for all government sites to meet WCAG AA guidelines.

All pages submitted for Needs review (by Editors) are reviewed against the accessibility and quality checklist. Approvers can refuse to publish a page until the accessibility failure is corrected.

On this page:

Responding to an accessibility failure in Jira

Review and respond to the content editor’s request in Jira, using the Accessibility failure template. This is found under the Canned Responses Pro section. Click on Select template then select the Accessibility failure template.

Accessibility failure template

Hello [insert name here],

Unfortunately, the page you have submitted for review does not meet accessibility requirements and is unable to be published at this time. [Describe where the standards are not being met]

The Disability Discrimination Act 1992 requires agencies to ensure people with disabilities have the same access to information and services as others in the community. It is a requirement for all government sites to meet WCAG AA guidelines.

To meet the requirements and have your page published, you will need to [add guidance, e.g. “provide the contents of the PDF as a web page.”]

If you are unable to make your page accessible at this time and would still like to proceed with publishing, we require you to respond to this email with the following acknowledgement. A disclaimer notice will be placed on the page with the contact information.

-

I understand that the following page does not meet WCAG AA standards and is in breach of the Disability Discrimination Act 1992. I accept the responsibility for any action that may be initiated by failing to comply. I also agree to provide contact details for anybody seeking an accessible version of our information. These contact details will be published publicly on the web page, along with an accessibility disclaimer.

I commit to providing an accessible version by: [date]

Page title & link:
Reason for exception:

Contact email:
Contact phone number:

Authorised by:
Date:

If you have any questions, please let me know. If you or your team needs any guidance on meeting accessibility requirements, you can book in for a consultation with an SDP content team member: Book a content design or training session (for Editors and Approvers) - You can book online!

Many thanks,

[publishing queue approver name]

Once you’re happy with the response, select Save comment:

Then set the ticket to Waiting for customer or On hold. This ensures the customer is responsible for the SLA and must remediate the accessibility failures before it’s published.

Adding a note to the CMS page and placing it in Draft

Set the CMS page back to Draft with the following revision note (this will let the rest of the team publishing team know that this person has been contacted):

This page does not meet accessibility requirements and cannot be published. Please check the Service Desk customer portal or auto-generated email for further detail.

The editor has the option to either:

  • update the page to meet the standards

  • proceed with publishing, with an accessibility failure disclaimer added to the page.

Adding and publishing an accessibility disclaimer on a page

Once the editor has acknowledged they are in breach of the accessibility requirements and has provided you with contact details, add the accessibility disclaimer to the page with call-out formatting and publish.

Managing the Jira ticket

  1. Change the ticket status to On Hold.

  2. Change the Component to Accessibility issue.

  3. Change the Date required to the date the editor has committed to fix the issue.

  4. The day before the Date required, the Service Desk will notify the Assignee that the date has arrived. Check to see if the issue has been resolved:

    1. if resolved, you can close the ticket

    2. if not resolved, use the comments to request an update.

Escalating non-compliance or other issues

Talk to your manager

Your first point of call should be your digital manager. They will make a decision on behalf of your department that should be recorded in the CMS and Jira ticket.

If an exemption is granted, it should be recorded in the revisions field in the CMS so that other approvers are aware of it.

If the editor has committed to fixing the breach after publishing (due to a tight deadline, etc.), the date the breach will be fixed be should be recorded in the CMS notes and the Jira ticket.

Historical accessibility breaches

If a page with old accessibility breaches comes through, use your discretion (or refer to your manager if unsure) based on the age of the content, audience size, impact of the breach and effort required to fix.

Make a note of your decision in the CMS revision field.

Accessibility exemptions

In some instances, a separate discussion can be had with a department or agency if the content is niche or if a HTML summary covering key messages could suffice for large/complex documents.

Examples of appropriate exemptions

  • Plain English/year 8 readability where content is already approved, particularly for documents, media releases etc

  • Very large reports/documents written for a public sector audience

  • Templates where a user is more likely to use a word document than a html version e.g. procurement, teacher or health practitioner resources.

Examples of breaches that should be fixed

  • 4-page fact sheets not in html

  • Translated content not in html

  • Closed captions and transcripts missing for video/audio

  • Missing alt text for images that aren’t descriptive, including diagrams and infographics

  • Any documents created for a digital and/or inclusive audience e.g. digital strategies, inclusion guides for family violence, LGBTI equality, etc.