New Title II regulations will require all public websites (including public libraries) to be fully ADA accessible by April 2026 or 2027, depending on population service size. For more information on this rule, see Title II ADA Regulations for Websites and Mobile Apps.

Websites need to be accessible in design and in content. Accessible documents are necessary any time new content in the form of PDFs, Word, Excel, PowerPoint information is added directly to or linked from a website.

This tutorial will focus on creating accessible word processing (Word) and PDF documents, specifically:

Note that we expect evolution and changes to these the specific tools and methods we use for scanning and creating accessible content on websites to evolve over the coming years. Review documentation regularly and stay tuned for trainings on requirements and best practices specific to library websites.

What makes a document (in)accessible

The basic principles of accessibility seem to revolve around the fact that computers can’t “read” images or graphics. They rely on the written word to translate the visual world audible or convert into Braille or other forms of communication.

So why would a text-based written document be difficult for a computer to read?

Generally, text-based documents (as opposed to spreadsheets, presentations, brochures, newsletters, etc.) are going to be the most easily interpreted by a machine into non-visual forms or forms more easily read by those who can interpret some visual information. But they still may include elements that will need to be addressed, including:

  • Graphics (even simple logos)
  • Hyperlinks
  • Information presented in hierarchical or non-linear form.
  • Lists (numbered or bulleted)
  • Formatting indicating important content

Using templates and accessibility checkers will make sure that documents uploaded to a website are able to be read by screen readers and other assistive technologies.

Creating Accessible Documents

There are several key principles and best practices in creating accessible documents. It is easiest to do this from the start with a new document.

Principles:

  • Use styles and headings to create your document’s structure.
  • Use a common, plain 12 pt or larger font.
  • Use high-contrast colors for text.
  • When writing for a general audience, write clearly in short sentences and avoid jargon and abbreviations (these may not be read properly by a screen reader).
  • Use numbered lists only when the order of items is important; otherwise use bulleted lists.
  • Provide alternative text for images (including logos).
  • Take extra care in using tables – screen readers do not play well with merged cells, blank rows or column, or nested tables.
  • Use “document properties” for documents.

Best practices:

  • Create templates for common documents (e.g., meeting agendas, reports).
  • Avoid using Google Docs until their accessibility tools are developed well enough to match those of Microsoft Word. Upgrade Word to the latest version and save as a .docx format to preserve accessibility features.
  • Check the accessibility of a document using Word’s built-in checker.

Word Document Templates

First, think about the types of documents you create on a regular basis. This may include:

  • Meeting agendas
  • Meeting minutes
  • Reports
  • Registration forms

You can create your own templates, or you can search for available templates on the internet to get you started.

Your template should include:

  • Formatted header and body structure
  • Font choice and size
  • Standard graphics (logo) with alt text inserted in place

Tip: search for “accessible Word templates” and look at college/university results. They have to provide support for students and often they have digital accessibility services with solid basic templates for use.

Some template resources:

  • Oxford University – Centre for Teaching and Learning: Readable and accessible templates for Word and PowerPoint https://www.ctl.ox.ac.uk/readable-templates  
    • Downloadable templates (general, meeting minutes) 
    • Template guide 
  • University of Colorado Boulder – Digital Accessibility Office, re: Accessibility and Google Docs “Some assistive technology users may have difficulty navigating and interacting with the Google Docs interface, so it is generally better to create content within Google Docs and then export to Microsoft Word if you will be sharing the content with someone using assistive technology or sharing your content publicly.https://www.colorado.edu/digital-accessibility/google-docs-and-accessibility  

Accessible PDFs

An accessible PDF is best started from a previous accessible document. If you begin by creating an accessible Word document, when you save that document as PDF the accessibility features should come along with it.

Since the Title II ADA accessibility requirements for websites and mobile apps specifically deals with documents created after the compliance deadlines, you do not necessarily need to retrofit older PDFs on your website. In theory you can begin by creating new accessible documents and turn them into PDFs.

However, there may be time you want to take an existing PDF and check/update the document’s accessibility. There are several tools for that process. 

PAVE PDF 

Pro:

  • Will both scan/validate a PDF and offer the ability to make corrections and download an updated document.
  • Free

Cons:

  • Works only one page at a time, so would be very tedious for large documents

Adobe Acrobat DC/Pro

Pros:

  • Generally widely available on library computers.
  • Many tools available in the free Adobe version
  • Broad array of tools available (some in the paid version)
  • Has tutorials and training available

Cons:

  • Some features may require the paid version

Nitro Pro

Pros:

  • Nitro Pro is a popular paid PDF creation tool, and does have accessibility tools built in.

Cons:

  • Only available as a paid tool.

Accessibility Toolbar

Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /srv/users/demo/apps/training-librarieswin-org/public/wp-includes/formatting.php on line 4715