PDF and non-HTML documents can be difficult for users with assistive technology. Plus, they can take a lot of work to make accessible. So, let’s learn:
Rather watch the video? Watch our PDF video to learn what makes PDFs accessible and listen to examples of PDFs being read with a screen reader.
What are PDF and non-HTML documents?
Let’s start with what HTML content is. When you navigate the web, most pages are HTML web pages. This means they have underlying HTML code that says what’s a heading, body text, image, etc. For example, the page you’re reading right now is an HTML web page.
Now, let’s cover what PDF and non-HTML documents are. When navigating the web, you’ve probably come across links to or embeds of documents. They can be PDFs, Word docs, Excel sheets, PowerPoints, or other document types. Each of these has specific requirements and considerations to make them accessible.
For example, PDFs need to be tagged so assistive technologies can properly read and navigate them. PowerPoints, Word docs, and Excel sheets also need to be built with specific accessibility considerations in mind.
How do documents affect an assistive technology user’s experience?
When it comes to documents, obviously, inaccessible documents have the largest effect on assistive technology users. They make it so people using assistive technology can’t navigate or, sometimes, can’t even read the content of the document.
But, even accessible documents could potentially interrupt an assistive technology user’s (or any user’s) experience if they open in a new tab.
Let’s discuss both of these more.
Unable to read or navigate inaccessible documents
Let’s get right into what makes the different document types inaccessible and accessible.
Most PDFs on the web are inaccessible. In WebAIM’s 2019 screen reader user survey, 75% of respondents said they were very or somewhat likely to have significant accessibility issues with a PDF.
An extreme, but common, example of inaccessible PDFs are ones with scanned images of text. Since the text is an image, the screen reader literally has nothing to read.
Another example are PDFs with text, but they aren’t tagged properly. These can still be difficult for assistive technologies to read and navigate.
We’ve mentioned “tags” a couple times. PDFs must be tagged to be accessible. Tagging is hidden unless being used by an assistive technology. Like HTML code, tagging defines what content is a heading, list, body text, image, etc. The image below shows what tagging looks like in Adobe Acrobat.
The other part to an accessible PDF is the reading order. This is the order the document is read by a screen reader, and can be the tags or content order. Both the tag and content order need to be checked so the PDF makes sense when read by a screen reader.
The reading order can also affect how a PDF shows up on a mobile device. If the order is wrong, paragraphs, images, and headings could show in the wrong order.
On top of tagging and reading order, PDFs still need common accessibility strategies like alternative text on images, high contrast for colors, table headings and captions, and descriptive form labels.
Word docs, PowerPoints, and Excel sheets
Several of the same accessibility best practices for HTML content are used to make accessible Word docs, PowerPoints, and Excel sheets. That includes:
- Alternative text on images
- High enough contrast for text, images, and graphics
- Proper heading hierarchy
- Descriptive links
- Only use tables to display data
Some specific ways to make PowerPoints accessible are:
- Check reading order for PowerPoint slides.
- Give every PowerPoint slide a unique title.
- Make sure any videos in your PowerPoint are accessible.
Lastly, these are the ways to help make your Excel sheets accessible:
- Add text to the A1 cell in Excel sheets. Screen readers will always start reading A1.
- Give all worksheets unique names and remove blank ones.
Documents open on new page or tab
Before we discuss documents opening on a new page, HTML web pages and documents that open in a new tab can be confusing to anyone – not just assistive technology users.
Also, documents don’t always open in a new tab. It largely depends on the link’s target attribute, and the user’s browser and settings. Since some of this is out of your control, it’s important to consider how someone would be affected by a document opening in a new tab.
To start, most links to documents don’t specify the document the link will take them too. For example, the example content below doesn’t specify the link goes to a document, so a user might assume it’s another webpage.
Example content: Review the assignment and test dates.
Now, the example content is fixed, so it does specify it’s a PDF. This a simple way to prepare the user for a download or for it to possibly open in a new tab
Example content: Review the assignment and test dates (PDF).
Let’s consider how a link that doesn’t specify the document and opens in a new tab might affect a screen reader user. After clicking the link, their screen reader is silent while it waits for the PDF to load and then loads itself. They’re surprised a PDF is opening in a new window. Now, the automatic screen reader voice starts to read the new PDF text. The user wants to get back to the previous page they were on, so they have to get back to the correct tab instead of just using the browser or keyboard shortcut back button.
Limit the use of links or buttons that open new windows or tabs within Web content. In general, it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content.WCAG 2.0 AA standards
What are alternatives to PDF documents?
Since making PDFs accessible takes additional steps and time on top of the other accessibility considerations, most PDFs end up not being accessible.
Instead, create PDF documents as HTML web pages. As long as the HTML web page is built with accessibility in mind, it doesn’t require additional steps to work with assistive technology.
Another alternative is Word documents. In 2021, WebAIM surveyed screen reader users and found that 68.9% thought Word docs were more accessible. Only 12.9% of respondents thought PDFs were the most accessible documents.
How do I determine if documents are accessible?
The best way to determine if a document is accessible is to use a screen reader to test it.
Here are two free screen reader tools you could use:
Read more about PDF and non-HTML documents
Check out these resources for more information:
- WebAIM’s PDF accessibility
- Proposal for a more accessible download link
- WCAG 2.0 Opening new windows and tabs from a link only when necessary
- Excel sheets accessibility
- PDF accessibility
- PowerPoint accessibility
- Word docs accessibility
- Google docs and Google slides accessibility
- PDF and non-HTML documents are linked to or embedded in web pages. They can include PDFs, Word docs, Excel sheets, or PowerPoints.
- When documents open in a new tab or window, it can be confusing for assistive technology users. WCAG 2.0 recommends limiting the use of links that open in a new window or tab.
- To make PDFs accessible, tag them and check their reading order.
- All documents still need accessibility applied through alt text, high contrast between colors, proper heading structure, descriptive links, tables that are used for data, and other accessible design techniques.
- Since making PDFs accessible takes additional steps and time, most PDFs are inaccessible. As an alternative, create an HTML web page instead.
- Use screen reader tools like Mac’s VoiceOver or Window’s NVDA to check if your documents are accessble.
Want to be part of the conversation?
Share questions, feedback, and experiences on Twitter
Sign up for our newsletter to get emails with accessibility content similar to this article. If you subscribe, we’ll email you web accessibility insights or things we learn a few times a month. You can unsubscribe at any time.
Check any page for accessibility errors
Check all your pages at once with Pope Tech. Your web accessibility data is ready in just a few minutes.
Make accessibility part of content editors’ and developers’ process with WebAIM’s WAVE extension tool.