Published by the World Wide Web Consortium (W3C), the Web Content Accessibility Guidelines (WCAG) are widely considered to be the standards for digital accessibility. In our articles, we regularly discuss how WCAG applies to web content — but WCAG also applies to web-delivered documents.
Why? Simply put, in order to provide an accessible experience to people with disabilities, you need to provide equivalent access to all of your organization's digital resources. That includes PDFs, spreadsheets, PowerPoint presentations, and any other documents available through your website.
Why do web documents need to be accessible?
Your website might use web documents for a number of essential purposes. For example:
- Collecting tax information from employees and end-users
- Providing user manuals or assembly instructions
- Providing online access to catalogs, whitepapers, and other print resources
In many cases, web documents can be replaced by HTML web pages that offer the same information, and that’s generally a good idea.
HTML is natively compatible with screen readers (software that converts text to audio or braille) and other assistive technologies, and in general, people prefer HTML over web-delivered documents. Even so, converting every document to an individual web page may be impractical at scale.
Web-delivered documents can create serious barriers for some users
When organizations ignore document accessibility, the user experience can suffer, particularly for individuals with disabilities. Some common examples of barriers:
- People who use screen readers may be unable to read text from a poorly authored PDF.
- Users may be unable to fill out form fields when using a keyboard alone (with no mouse).
- Users may have trouble navigating if the page numbers on a document’s table of contents don’t match with its actual page numbers.
This is not a comprehensive list of potential barriers. The takeaway: If your business offers access to documents online, you have a responsibility to make those documents accessible to as many users as possible.
Using WCAG to Create Better Web Documents
According to the W3C, most WCAG success criteria can be applied to web-delivered documents. Following the guidelines can help you create documents that are accessible to as many people as possible — and aid in compliance with the Americans with Disabilities Act (ADA) and other non-discrimination laws.
If you’re new to WCAG, start by reviewing the four principles of accessibility: Content should be perceivable, operable, understandable, and robust (often referred to as the “POUR" principles). As you author your documents, keep those principles in mind and use them to guide your decisions.
For a more in-depth discussion of the POUR principles, read: What Are the Four Major Categories of Accessibility?
Examples of WCAG Standards for Web Documents
WCAG 2.1, the latest version of the guidelines, contains 78 success criteria, testable statements that can be used to evaluate accessibility. In general, your web documents should meet the requirements of all Level A and Level AA success criteria.
Below, we’ve listed a few examples of success criteria that can apply to web-delivered documents. Remember, this isn’t an exhaustive list — when you’re preparing documents for publication, you’ll need to follow all applicable WCAG criteria to prevent users from encountering barriers.
WCAG 2.1 Success Criterion (SC) 1.1.1, “Non-Text Content"
All non-text content (such as images, graphs, and audio) should have a text alternative. If your documents use images, those images will need descriptions, often referred to as image alt tags or simply as alt tags.
Microsoft Word, Adobe Acrobat, and other document authoring tools have built-in features that allow authors to add alternative text. When writing these descriptions, make sure to avoid common alt text mistakes. Keep your descriptions brief and accurate.
Related: What is the Best Way to Write Alternative Text?
WCAG 2.1 SC 2.4.5, “Multiple Ways"
This criterion requires that “more than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.”
While the language here is specific to web pages, it’s also applicable to web-delivered documents. If you provide users with a 100-page PDF, they’ll probably need to jump around the document to find what they need.
Properly tagging your PDF will provide order to your document, enabling users to search for information, navigate to different headings, and find specific types of content.
Related: 7 Basic Steps to Making PDFs More Accessible
WCAG 2.1 SC 2.4.6, “Headings and Labels"
This criterion requires headings and labels to describe the “topic or purpose" of the content.
Clear, descriptive headings provide your content with an understandable structure. A generic subheading like “More Information" isn’t very useful, but a more descriptive heading (for example, “More Information About Our Electric Lawnmowers") will help users find the information they need.
Within your documents, your headings should use a logical order and have appropriate tags. Otherwise, people who use assistive technologies may be unable to find them.
Related: Easy Guide to Accessible Headings
WCAG 2.1 SC 1.4.3, “Contrast (Minimum)”
This criterion requires text and images of text to maintain a contrast ratio of at least 4.5:1. Large-scale text should have a contrast ratio of at least 3:1.
Contrast ratio refers to the difference in luminance between text and its background. Following this guideline will ensure that people with color vision deficiencies and other vision-related disabilities can read your content.
Related: Check Out Our New Color Contrast Tool
To build accessible documents, prioritize inclusive design as early as possible
You can remediate accessibility barriers after you’ve drafted your documents, but fixing problems after-the-fact is often more time-consuming (and expensive) than building for accessibility. That’s also true for other types of online content: When inclusive design is part of your content creation strategy, accessibility compliance is much easier.
Get into the habit of asking questions when authoring your documents:
- Does my document include any images or other non-text content? If so, have I provided text alternatives?
- Can readers navigate the document easily when using a screen reader or other assistive technology?
- Does my document make use of headings, and are the headings clear and accurate?
- Does my document contain any low-contrast text?
Finally, if your website contains a large number of web-delivered documents, make sure you’ve thoroughly evaluated those resources for accessibility. At scale, this can be a major project, so work with an experienced accessibility partner for optimal results.
To learn more about document authoring and accessibility remediation, send us a message or read about the Bureau of Internet Accessibility’s PDF and Document Accessibility Remediation services.
