Your complete guide to creating accessible documents

No matter how automated a system is, or how skilled a person is at marking up documents correctly, there is always a risk that errors can ruin the efforts and hard work you put into the document. If you are not in control of the entire chain of production, one weak link can damage the entire process.

The vast majority of organizations have their own way of managing document production. Often a document is moved or modified multiple times. Each time this happens, there is a risk that essential information is lost and accessibility is affected.

That is why we have created a checklist to guide you in identifying bottlenecks and planning work processes so you can spend time on more important things.

You should go through this checklist for each system or process you have that is tied to document creation, storage, distribution or archiving.

The list is deliberately in reverse order, because all processes the document goes through can impact the document’s accessibility.

Archiving:

In business systems, the term “archiving” is used to describe a final phase, i.e. the document has been created and sent to the individual, and the case or task is therefore archived or closed.

Pay attention to the final file format – it is important for the accessibility of the document. Check whether there are any potential limitations in the adopted file format with respect to document tagging.

Here’s where it gets a bit technical: The vast majority of documents end up as PDFs. There are often requirements as to the archiving standard in the form of PDF/A. Generally, the PDF/A standard is considered to be met if the document meets all requirements of web accessibility. This is the case, for instance, when the file is marked as PDF/UA.

Note, however, that the opposite is not always true! A PDF/A document does not necessarily satisfy WCAG requirements for web accessibility.

Distribution:

How do you ensure a document is correctly transmitted to a recipient?
You should test the document both before and after and compare the results to ensure that no changes occur in the process.

Public authorities often send documents via digital mailbox and e-mail, or the documents are published directly on the organization’s intranet, internal portal or on public websites.

Website content is usually controlled by a CMS (Content Management System). There documents can typically be stored without any changes to the content or to the metadata embedded in the document when published – metadata that is important for the final accessibility of the document.

E-mail is usually also a reliable channel of communication, but be aware of whether any special application or add-in that could affect the document content and metadata.

A digital mailbox can be difficult to test thoroughly, as some gateways manipulate document formats in the process – for instance by converting an open document format like .docx to .pdf or a similar format. It is here, in particular, that restrictions in the gateway, or the PDF engine it uses, can act as a barrier in the distribution of web-accessible documents.

When distributing documents in PDF format, it is important to identify which system in the chain can potentially convert an open document format such as .docx to .pdf – and what quality standards the PDF engine follows.

For instance, the PDF engine in Microsoft Word has a number of limitations in terms of web accessibility; in particular, older versions like 2016 and earlier can pose challenges. The same applies to document management solutions and distribution gateways, and we recommend discussing this with your system vendor if in doubt.

Storage:

What file format is the document stored and edited in until its distribution and archiving? Check whether the system’s different document formats allow or, conversely, restrict proper markup for web accessibility.

Pay particular attention to whether the process between storage and distribution/archiving changes the document and its markup.

Nearly all organizations use one or more case and document management systems. Some of these systems may have technical limitations in terms of which formats they support.

This can pose a challenge if files/documents are stored in formats like: .tif, .rtf or similar formats, as it means that important information or metadata from the document is lost.

Also remember to check whether the case and document management solution changes the file format when sending!

Many EDRMS and business systems have built-in PDF generation that is activated when a document is sent to a recipient. Unfortunately, some of these built-in PDF engines don’t live up to the quality requirement and unintentionally impair the document’s accessibility.

Document creation:

What format is the document created in? Test to what extent you can correctly tag the document the first time you work in it. Using a template that is already correctly tagged can greatly facilitate this task.

The majority of all documents are created in Microsoft Word and based on some form of template.

Pay attention to whether Word creates the document itself or whether the document is created or copied in another system; this can affect the document by limiting markup for accessibility.

It is a good idea to mark up all templates correctly, so the foundation for all new documents is always in order. This is a necessity when creating fully automated documents that meet the requirements for web accessibility. Moreover, it’s a tremendous time saver for users working with document creation

Omnidocs Create is the preferred template solution of public authorities and councils, and we recommend taking a closer look at the solution if you are not already familiar with it.

Remember to stay up to date on how to correctly mark up documents according to the WCAG standard for web accessibility, and consider whether you might benefit from supplemental tools such as Assist Pro.

General remarks:

Sometimes you come to the conclusion that a particular work process or system limits your efforts to achieve web accessibility in a simple manner. When documents are created by a third party or older IT system, it can be difficult, for instance, to live up to the standards for web accessibility.

In some cases you have to go back and correct and properly mark up documents created earlier. This is often an expensive solution in terms of time and the financial expense of hiring external resources to fix the problem. Your money is better spent doing things right the first time, so you avoid unwanted work later on.

A tool like Assist Pro also makes marking up existing documents correctly much easier.

Still in doubt?

If you still have questions, you are welcome to reach out and contact us here – we’ll do our best to guide and help you gain better insight on document lifecycles and your options for achieving full web accessibility.