Accessible documents

Always aim for HTML

Turas content should be as easy as possible to locate and read. That’s why the default should be to create HTML content before considering any other format.

Publishing content exclusively as a document such as a PDF makes it harder to locate, use and maintain. Unless the document is created with great care, it is likely to be significantly less accessible than an HTML version and may not comply with our accessibility regulations. If you do need to publish a document, it should be in addition to an HTML version. A PDF should never be a standalone product.

HTML is better for search, mobile and can be accessed without the need for the user to buy costly software. Remember not all of your users will be accessing your content from a desktop computer at work. Therefore, they may not have access to Microsoft applications on their device. Reading document content on small screen can also be challenging and creates a poor experience for mobile device users.

Turas aims to create inclusive experiences. If you do still decide to publish content in a non-HTML version, where possible offer this as a PDF because they can be viewed without the user owning specific software.

General guidance

The accessibility of a document depends on how it was created. All documents should be produced with accessibility in mind. Regardless of the authoring software you use, always consider the following guidance when creating your documents:

keep language simple and write in plain English
headings should be created using the built-in heading features of the software to enable screen readers to understand the page structure
create bulleted lists using the list controls of the software
identify the document language because screen readers software is multilingual and will read the document using the appropriate language
write meaningful hyperlinks
include alt text alongside non-decorative images, so people who cannot see them understand what they’re there for
avoid using tables, except when we’re presenting data, don’t use them for layout
when using tables clearly identify column or row headers
make sure the document was an accessible title / name so screen reader users are not just reading out a file name such as "example1.pdf"
ensure text on coloured backgrounds has a contrast ratio of 4.5:1, you can verify the contrast ratio using a colour contrast checker

PDFs

Start with an accessible source document. When exporting a file to the PDF format it must be a “tagged” PDF to preserve the underlying structure and features described in the guidance above.

PDFs should be saved as PDF/A as this format has been specifically developed for document archiving. Be aware that saving as a PDF/A does not automatically make the document accessible. A PDF/A embeds all of the document’s elements rather than allowing links to external information. They are entirely self-contained files.

PDF/A files can’t include the following:

audio or video content
JavaScript or executable files (or links to external executable files)
encryption of any type Embedded files, such as other PDF files
transparent objects (graphics) and layers

These limitations ensure the documents can be reproduced in exactly the same way for years to come.

Documents designed to be edited

Some documents may be templates that are designed to be downloaded and edited by the user. Only provide these document types if they are going to edited by the user. If the purpose of the document is for online reading this should be created as HTML.

How to create accessible documents

Word and PDFs

For creating accessible Word/PDF documents we recommend looking at this tutorial on ability.net.

When creating Word Documents follow the general guidance above and read WebAIM’s article on Microsoft Word accessibility. You should always inspect your document for accessibility issues using the accessibility checker.