GOV.AU Content Guide Types of content

Present content in the most useful and accessible format for the user.

PDFs

Only publish a PDF if there is a strong user need. PDFs are not accessible to some users on mobile devices.

If you make a PDF, try to also publish in HTML. Publish the non-HTML format as a secondary source of the information.

Sometimes it may not be appropriate to publish in HTML, for example some types of specialist reports. If you don’t publish an HTML version, be sure to publish an HTML summary on a landing page — and provide contact details for users who are unable to access the PDF.

In all cases, you should follow guidance to make accessible PDFs.

For example, you should:

You can also use Adobe Acrobat Pro and other tools to check and improve accessibility of PDF files.

See PDF accessibility.

Documents

Microsoft Word

Microsoft Word formats (.doc and .docx) don’t conform to WCAG 2.0. Additionally they can be difficult to view on mobile devices.

Don’t publish Word documents on the web on their own. Provide the information on an HTML page as well. If this isn’t possible, create an accessible PDF and publish both non-HTML formats from a landing page that summarises the document.

Make Word documents accessible to everyone even if you are emailing them internally. This includes people who rely on assistive technologies such as screen readers.

When creating Word documents you should:

Microsoft has guidance on making Word documents more accessible.

Google Docs

Google Docs is designed to work well with screen readers and assistive technologies.

Google has guidance on making Google Docs more accessible.

Rich Text Format (RTF)

You should avoid RTF as a publishing format. RTF can’t carry the same level of semantic information or accessibility that the .docx format can. Note though that Microsoft Word formats (.doc and .docx) don’t conform to WCAG 2.0 and can be difficult to view on mobile devices.

Excel

Only publish an Excel document if there is a strong user need. They can be extremely difficult to view on mobile devices.

Sometimes it may not be appropriate to publish in HTML, for example when documents contain a large amount of data.

When publishing Excel documents, you should:

Microsoft has guidance on making Excel documents more accessible. Also provide contact details for users who are unable to download the document.

PowerPoint

Only publish a PowerPoint document if there is a strong user need.

Screen reading programs often interpret items on a PowerPoint slide in reverse order, which can confuse users with a vision or reading disability. However, PowerPoint has tools to help screen readers see slides in the way the author intended.

For example, use pre-existing slide templates. Don’t delete or rearrange the default slide elements as this could change the order of items on a screen reader.

For custom slides, you can set the reading order yourself in the Selection Pane.

You should also:

Microsoft has guidance on making PowerPoint presentations more accessible.

EPUB

EPUB publications should include appropriate metadata.

WCAG Level AA conformance is recommended for EPUB publications.

Tables

Tables are recommended, although it’s important to use structural markup to avoid accessibility barriers.

You should use structural markup to differentiate and link header and data cells, rather than relying only on visual cues. This will allow screen readers to interpret the table correctly, and allow assistive technologies to use the information to provide context to users.

Sometimes it may not be appropriate to publish a table in HTML, like a specialist report with a large amount of data. In these cases you should use Excel or publish to data.gov.au.

The World Wide Web Consortium (W3C) also has guidance on how to structure tables.

Back to contents ↑

Fact sheets

Publish fact sheets in HTML. This improves accessibility and allows for printing.

If there is a user need to access the information as a PDF as well as HTML, you must make the PDF accessible.

Back to contents ↑

FAQs

Avoid using FAQs (frequently asked questions).

FAQs date easily and suggest that web content is out of touch with the user’s needs.

Instead of writing FAQs, write answers to important questions in the places where the user will expect to find them.

If FAQs are essential make sure they are useful, well-edited and link directly to the places the user needs to go next.

Group FAQs under topics for quick reference and regularly update them using feedback loops.

Back to contents ↑

Forms

Guidance on forms, fields and labels is available in the DTA Design Guide.

Start with the user’s needs

Think about the user’s needs and what they need to do.

Check the form is usable

Write forms in plain English. Test for usability and accessibility.

If the user needs to print, scan or email the form, provide a contact support phone number.

Give the form a clear title

Call the form something which explains the task.

Include a short description.

Example of

titling a form

Title: School enrolment form

Brief description: Enrol your child in a NSW public school.

List supporting documents needed

If extra documents are required to complete the form, list them with a subheading.

Example of

listing documents for a form

To complete this form you need:

  • driver’s licence
  • passport
  • birth certificate
  • utilities bill.

Explain why you need personal information

If you are collecting personal details, include a sentence to explain why. Link to your privacy statement.

Example of

information about collecting personal details

We will not collect, use or store your personal data for any purpose other than as stated in this form.

See our privacy statement.

Back to contents ↑

Surveys and questionnaires

Make surveys accessible. Keep them short and relevant. Say how long the survey will take to complete.

Follow the DTA Content Guide on making forms.

Make the title of the survey clear

Use the title to remind the user what they are being asked about.

Example of

referencing a PDF

Title: School canteen survey

Brief description: Have your say about our proposed new canteen menu.

Write clear survey questions

Avoid ambiguity in questions.

Provide a short explanation of why you are asking each question.

If you use an open-ended question think how you will report on that data.

Test your survey before you send it

Surveys are quick and convenient. But it’s easy to accidentally collect misleading data.

Before you send a survey:

  1. Find 3 people who match the target audience of your survey.
  2. Ask them to complete the survey. Don’t just email it. Watch them while they do it. Ask questions to see if they understand what’s been asked of them.
  3. Go back and adjust your questions and survey design based on what you’ve observed.
Back to contents ↑

Images

Use images minimally and with purpose.

Make the images accessible.

If you use images to enhance written information use real people and locations.

Decorative images are typically ignored by most users.

Back to contents ↑

Video

Videos can be a useful way to deliver short snippets of information — if there is a user need. For example, videos can make complex written information easier to understand.

Video should be a complementary channel. It should enhance written information.

Make the video accessible

Read guidance on transcripts, closed captions and audio description.

Write a focused script

Think about what the user needs to know and make this your main focus.

Get to the point early on.

Check the voice and tone. Use humour sensitively.

Think visually

Show, don’t tell. Use imagery that describes what you’re trying to say instead of adding a lengthy narrative.

Make videos short

People prefer informational videos to be less than 2 minutes long.

The longer a video gets the more likely the user will stop watching.

Back to contents ↑