Document Guidelines


Digital files are required to adhere to the same Web Content Accessibility Guidelines (WCAG) 2.0 standards as websites. This is a broad categorization of content, and includes file types like Microsoft Word, PowerPoint, Excel files, and PDFs.  

Without intentional actions, most digital files are not accessible out-of-the-box. This page lists ways to make several common file types more accessible.  

A Note on PDFs

Minimizing the use of linked or downloadable documents, especially PDFs, is the single best thing you can do to improve the accessibility (and overall user experience) of your digital content and services. Whenever possible, add content directly to your website instead of uploading documents. Many departments have institutional inertia and resist this change; here are some reasons to stop uploading documents:

Creating Accessible PDFs is a lot of work for poor results

Making PDFs accessible is time-consuming and laborious, and even the most accessible PDFs are less accessible than properly formatted web pages. All PDFs require manual review and revisions before they can be uploaded and published. Even if the source document (like Microsoft Word) is formatted perfectly, and Word’s accessibility check reports no errors, you will need to make manual changes within Adobe Acrobat Pro after you export it to a PDF.

Simple documents can be reviewed and published in 10 minutes apiece. Complex documents, especially those with forms and tables, can take hours to review and revise. 

If the content on your document changes frequently, like a staff directory for a large department, you need to make these accessibility changes on the PDF every time it is edited and re-exported to a PDF. 

These efforts do not scale. If you have 100 pages on a website, and realize there is the same accessibility error that affects all of them, a developer can make a code change in one place, and it will fix the error on every page on the site in one pass. If you have 100 PDFs with the same accessibility error, you’re making the same change, manually, on 100 different documents, then uploading 100 different updated documents.

PDFs are not mobile-friendly

You might create and manage most content on a desktop computer, but most content is consumed – especially by the college-age demographic – on mobile devices. PDFs do not display well on smaller screens. They don’t resize, requiring people to zoom in to read the content, and the content doesn’t present in a single column layout, as it does on most mobile websites. The user needs to scroll both horizontally and vertically to read the content, and large PDF sizes can be especially prohibitive for users who are not connected to WiFi. 

For users on mobile devices, PDFs aren’t just less convenient, they frequently don’t get read at all.

PDFs are less visible to your audience

If you have business-critical information, you don’t want to bury it in a PDF. Some search engines are able to index content in PDFs, but not all. Putting content in a PDF means fewer eyes will see it. 

What to do instead?

The only recommended use case for PDFs is for documents that are intended to be printed. In other cases, create pages on your website to host this content. Once you are familiar with the content editing interface within your content management system, it’s frequently easier to create this content as pages on your website, especially if you update this content frequently.

There may be a higher initial effort to create content as a web page, but depending on the functionality of that page (e.g. a web form) the automation that can be built into web pages may have a lower long-term cost.  


If you opt for hosted documents, follow these accessibility techniques, which apply to all file types and all platforms.  

Describing Images 

Images are inherently inaccessible to people who are unable to see them. All common content editing software allows the content editor to add an image description, commonly called alt (alternate) text, to an image. 

  • Alt text is not visible on the page, but gets read by screen readers. It should describe the content contained within the image in a brief sentence or two, and in fewer than 125 characters.  
    • Don’t include “Photo of…”, “Image of…” etc., in the image, as screen readers will announce the media as an image before reading the alt text. 
  • Most content editing software has the option to flag images as decorative. If the image is purely for visual effect and does not contain meaningful content, mark it as decorative.  
    • This tells screen readers to skip over this content.   
    • If the image is not marked as decorative, and does not have alt text, some screen readers will read the file name of the image (e.g. stylized_horiz_graphic.jpg) which is a poor user experience.  
    • If there is not the option to flag an item as decorative, but you can manually edit the alt text, give it an empty text string (e.g. alt=””). 
  • Complex images, such as graphs and infographics, cannot be sufficiently described within the parameters of alt text. Provide a brief explanation of the complex image in alt text, then provide a more thorough description of the graphic as plain text on the document. This is more accessible to everyone, including people with full sensory perception who might have difficulty understanding the graphic. Note that in HTML web content, this can be handled with the longdesc attribute, but this functionality is not available on uploaded documents like PDFs.
  • If for some reason you are not able to add alt text to an image that needs it, add an image caption beneath or adjacent to the image that is visible to everyone. 

Color Contrast 

It is important that colors sufficiently contrast against each other so all content on your media is readable. This applies to text against solid backgrounds, and to text in front of images. 

  • As examples, yellow text on a white background, or dark gray text on a black background is hard to read, vision-impaired or otherwise.  
  • The color contrast between two elements needs to be at least 4.5:1 for regular sized text, or 3:1 for large (18pt or 14pt bold font) text. More contrast is always better. 
  • Use a color contrast checker to see if there is sufficient color contrast between the text and background. Avoid putting text over top of images and patterns when possible. If necessary, add a tinted color overlay behind the text so it stands out more against a background. 
  • Logos are exempt from color contrast requirements.

Identifiable and Meaningful Links 

To ensure the links in your documents are accessible, they should have meaningful link text, and be visually identifiable by some means beyond color alone. 

  • Links are commonly styled using blue text. This is permitted, but there should also be some other means of identifying that text is a hyperlink. This is most commonly done by making the links underlined. If that conflicts with your style guidelines, you may alternately make links bold (if in HTML, use the <strong> attribute, not the <bold> attribute). 
  • Link text should be meaningful, it should clearly tell the user where it goes. Text like “Read More” is ambiguous and should be avoided. Avoid using the same link text to link to different destinations. Similarly, avoid using different link text to link to the same destination. 

Examples of good link text: 

Examples of poor link text: 

  • Students should send an official CDC vaccination card to the Student Health Center with their completed COVID-19 Immunization Verification Form, found here.
  • ( if you have any questions about class registration. 

Use Structured Data Whenever Possible 

Most content editing software has pre-formatted options for presenting content. For example, Microsoft Word and Powerpoint have different tiers of Headings available, as do Google docs and Slides. Headings will make the text larger, change the color, add line spacing, amongst other stylistic changes. Using these types of structured data to convey content organization and hierarchy is always recommended. Using structured data also adds metadata to the content, information that is not visible on screen, but allows assistive technologies to understand the layout and structure of the document content  

  • For Headings, use the Styles pane in Microsoft and Google products, versus directly editing the font styles. If you don’t like the default styles provided by Microsoft or Google, use the Styles pane first (which adds metadata) then go and revise the styles afterwards. The Styles pane adds metadata and is more accessible

Microsoft Word Headings Pane:

Headings Pane in Microsoft Word

Microsoft Word Styles Pane:

Styles Pane in Microsoft Word

Google Docs Headings Pane (dropdown menu):

Headings Pane in Google Docs

Google Docs Styles Pane:

Styles Pane in Google Docs

Directly editing styles does not add meta data and is less accessible. Only revise these styles (font family, color, size, etc.) after you’ve already marked up your content using the options in the Styles pane. 

  • Use the predefined numbered list and bullet list options. This provides structure to the lists, and allows screen readers to understand that this is content presented in list format. If you try to “fake” a list by manually adding hyphens to regular paragraph text, it visually looks like a list, but lacks the underlying structure. If you dislike the default bullet / numbered list styling, create it using the built-in list tools, then restyle afterwards. 
  • The structured layout options will vary substantially by platform. In general, if a structured element is available, use it!