The sun setting behind the Sundial

PDF Accessibility

The common use and sheer ubiquity of PDF files can make the road to accessibility seem rather intimidating. To date, most content creators know very little about requirements and even less about methods for following them.

To PDF or NOT to PDF?

For those who are unaware, PDF files are not typically created in Acrobat. They are usually created in another program and then converted to PDF. For example, many documents are created in a word processing application, such as Microsoft Word, and then exported as PDF documents. 

Before delving further into the topic of PDF accessibility, however, it's best to consider why you are using a PDF to distribute your information. Is it meant to take the place of information on a web page? Is it made available so users can print the information? PDF is great for distributing documents that need to be printed. But no matter how tempting it might be, you should never use PDF for content that you expect users to read online. According to user expert Jakob Nielsen, forcing users to browse PDF documents makes your website's usability about 300% worse relative to HTML pages.

Ask yourself the following questions when considering PDF:

  • Is the information meant to be read online? If so, rendering that information as a web page is always preferrable. Consider the following advantages of HTML:

    • Customized to device
    • Contains navigation and easy access to other site content
    • Standard interface
    • Easy to search
    • Easy to share by link
    • Linked to data repositories
  • Is the PDF a form that can be created online? (Ask us about Formstack! This form tool is easy to use and 100% accessible!)
  • Can the information be printed just as easily from a web page? Even when considering the print factor, you should keep in mind that web pages can also be printed, especially when using a good print stylesheet.
  • Will the document need to be remediated on a regular basis? If so, this could be time-consuming and costly.

Creating "Friendly" Documents for PDF

Optimally, document accessibility begins in the native document format. Dozens or probably hundreds of programs can create PDF files, but very few of them produce "tagged" PDF files.

Tagging is just one of the many things that must be done in native document applications to support accessibility. Tags express the structure of the document, including the logical text-flow or reading order, and the presence of significant elements such as figures, lists, tables, and so on. Even seemingly small errors in document structure can easily render a file completely incomprehensible by readers with disabilities. In fact, you might consider using your computer with the screen turned off to get some idea of how important logical text-flow is to anyone who needs a screen-reader!

Other characteristics of a fully accessible PDF include alternate descriptions for all images, valid Unicode assignments for all characters, and management of all interactive features to ensure their maximum usability.

Make It Simple

When the PDF represents a document that is also used in hardcopy form (e.g., a printed brochure), you may want to consider creating a separate, simpler version for downloading and reading offline. This can make your job of remediation easier and less costly. 

For this simpler version, think about ways you can eliminate elements that create accessibility barriers. Does the document contain a front cover, title page, or other pages with lots of decorative text and/or images? Does it contain color and outlined and/or shaded boxes? Make sure that the elements you choose are done so purposefully. Can the reader understand the information without the use of those elements? If the answer is "yes," then you are probably better off not using them.

Follow These Guidelines

Appligent Document Solutions has provided the guidelines below, which you can follow when creating the native document to help ensure that your PDF will be accessible and less likely to require third-party remediation. Taking the time to follow these guidelines for appropriate fonts and formatting at the outset will save you both time and money.

Fonts and Bullets

Don’t use custom typefaces or "fancy" bullets: In addition to taking up more space in your document, they can trigger Unicode mapping errors in accessibility checkers.

Use OpenType fonts, or Base 14 fonts (installed as a part of the Adobe Acrobat installation): OpenType and Base 14 fonts add little size to your document and include options such as the Helvetica, Times, and Courier standard font families (regular, italic, bold, bold italic), as well as Symbol, and Dingbats. Base 14 fonts don’t need to be fully embedded, which can help significantly reduce file size. Bullets and other special characters should also be picked from these fonts.

Avoid extra bold, black, or heavy font variations: Such styles can cause text to appear multiple times in the tagged document.

Don’t use small caps: Using small caps can cause text to appear as a mix of capitals and lower case characters in tags and cause the screen reader software to 'stutter.'

Formatting Issues

Avoid double-page spreads: Headers, body text or tables split into two pages are seen and tagged as separate pages by Acrobat. These require time-consuming manual work to make them read properly because each page will auto-tag separately and will probably make no sense without manual reorganization of the tags.

Use embedded, flattened .jpg files: In files with layered graphics (such as Illustrator drawings) and multiple layers of background shading, tagging can change layer order and 'break' images or cause text to disappear behind shading.

Simplify tables: Multiple levels of row/column headers are very difficult and labor intensive to tag. Even when structured and tagged perfectly, many screen readers will read them row by row, making them difficult for a non-sighted end-user to decipher.

Limit 'visual' cues and information: Avoid using graphic elements or color coding to convey essential information. Differently colored or formatted words (such as bold, italic, etc.) need to be separated and tagged individually and supplied with alternate text. This increases tagging time significantly.

Don't forget your ALT text: Alternative text is required for Section 508 compliance. All graphics and relevant visual elements need descriptions that can be read by screen readers.

Formatting Issues Specific to Microsoft Word

Be careful with file extensions: Always save Word documents as .doc, (not .docx) then output as PDF.

Watch your spacing: Spacing and line breaks should be created by using paragraph settings, not by hitting return. Using "return" creates many empty space tags in the PDF, that will cause screen reader software to keep reading "Blank, Blank…" if they are not removed.

Use consistent formatting: If styles are used, they should have standard names such as Header1 or H1, body text, etc. and be used consistently. Otherwise, if a style is named something like "documentXX_headerFirstLevel" or "documentXX_bodytext," the tags use those titles instead of the standard <H1>, <P>, etc. A screen reader can recognize <List>, <P>, <H> tags and read them accordingly, easily navigating the different elements. In particular, if all headers are marked as H1, H2, etc., a user can choose to scan through the document by navigating from header to header.

Text boxes should be avoided as much as possible: Text boxes with heavy frames and shading will typically be perceived as an image in PDF. Some text boxes may even lose their 'grouping' in the tagging process so that the text will be hidden behind background shading. Also, "sidebar" text boxes can interrupt the flow of body text. When reading a document visually, you can skip over a sidebar but when you are listening to the document being read by a screen reader, the interruption can be annoying or confusing.

Use text, not images of text: Screen readers cannot read images of text. If your PDF files are scanned images, they need to be processed through Optical Character Recognition (OCR) Software. This will convert the images of text to actual text and significantly decrease the overall size of the PDF file. For example, using images of text to display tables caused one of our clients to receive an estimate nearly three times the cost it would have been if the text had been OCR’d. Also, the file size correspondingly decreased from 13 Mb to 6 Mb.