Accessible documents start with an accessible template.

Accessibility in a document is not a setting you switch on. It is structure. In practice it means real heading styles rather than text made to look big, a logical reading order, meaningful alternative text on images, tables with proper header rows, and structure that survives your team editing it.

Structure is what a screen reader uses to navigate. Real heading styles let someone move through a document by its headings, the way a sighted reader skims it. Text that has only been made to look like a heading is not one. A screen reader reads it as ordinary text, not as a heading.

Staying accessible once people start editing is where most documents fall down. They were made accessible once, by hand, and it came apart the first time somebody added new content. 

We build templates in your brand palette, and not every palette holds up. WCAG sets a minimum contrast between text and the colour behind it. It is a measurement, not an opinion: any two colours either meet the minimum or they do not. Plenty of well-loved brand colours do not, against white or against each other, at body text size. Ours included: there are combinations in our own palette we avoid because they fall short.

If we are designing your templates, we check your palette and set the template up to use the combinations that work, rather than build something that looks right but fails. If the design comes to us from your designer, the colour decisions stay with them. 

Accessibility is usually treated as something you fix at the end, one document at a time. That is slow, expensive, and it has to be repeated for every document you produce. Building it into the template instead means every document your team creates already has it.

A template is not only read, it is used, and the person using it may have a disability too. The same structure that helps someone read a document helps someone build one.

The Disability Discrimination Act 1992 requires that providers of goods and services do not discriminate against people with disability. The Australian Human Rights Commission's guidance sets out how that applies to digital information, and states that organisations should conform with WCAG 2.2 at a minimum Level AA.

Importantly for documents, the Commission is explicit that WCAG is not only a website standard. It also applies to non-web documents.

There is a procurement angle too. The Australian Standard for ICT accessibility, AS EN 301 549:2024, covers non-web documents specifically, and the Commonwealth Procurement Rules contain mandatory requirements for applying Australian Standards. Every state and territory government has made its own accessibility commitments as well. So it applies to you whether you work in government or supply it. 

We build to WCAG 2.2 because that is the version the guidance points to. AS EN 301 549 still references WCAG 2.1, but the Commission's direction is to use 2.2 where appropriate. Building to the older version would only mean doing it again later.

A well-built Word or PowerPoint template is what gives you a decent PDF, because an exported PDF inherits the structure of the file it came from. Export from a properly built template and the headings, reading order and alt text come with it. Export from one that only looks right and there is no structure for the PDF to inherit.

The Human Rights Commission's guidance notes that PDFs cannot be made fully accessible, particularly on mobile devices. If a document has to reach everyone, the accessible Word document matters more than the PDF you make from it. For example, one client asked us for templates that would let them publish the accessible Word document on their website alongside the PDF.

When a template is already broken, we rebuild it rather than patch it. Patching carries the original problems forward into everything made from it afterwards. Starting again sounds like the longer route. It rarely is, and it is the only way to know the structure is right.