Insight
How to make your digital documents accessible
May 18, 2023
James Bateson
.jpg)
When considering the digital products we design and build, we consider accessibility from the start and throughout. We also communicate important information internally and externally via digital documents such as presentation decks, word documents, spreadsheets, and PDFs (more on those later).
However, making these accessible can often be forgotten. But how many people could we be excluding by not checking them? We don't know who may one day need to consume the information we present and how vital this may be to them.
At Code, we currently use the Microsoft suite of document applications, which all have ways of checking for accessibility. In this blog, I will run through how these checks can be done and some common issues that you may find in your documents.
NOTE: I'm going to mainly use PowerPoint as an example. However, the techniques to check for accessibility are the same in other Microsoft document editing applications.
You can open the accessibility pane using the "Review" menu item and then the "Check Accessibility" menu item. You should see any accessibility errors, warnings, and tips in a side panel.
To take a few steps out of the above, pin the accessibility checker to the bottom helper toolbar.
To do this (if you don't already see accessibility there), secondary click on the bottom toolbar (where the language is shown) and choose to show the accessibility checker.
As well as being easier to access and show the checker, it also shows a handy little status as you create your document. Either "Accessibility: Good to go" or "Accessibility: Investigate", along with an icon.
Tip: You can also toggle the "Keep accessibility checker running while I work" checkbox to hide/show it in the status bar.
So now we can open the checker; what kind of issues are common to see? Although documents are a slightly different type of communication method from something like a website, the easy-to-fix, high-impact issues we see are similar to those associated with web accessibility.
When set, alternative text is used by assistive technology, such as screen readers to describe the content of an image. On the web, images are commonly used to support content and convey extra context or emotion, for icons, and just for visual decoration proving no extra information or context.
This is the same in digital documents. However, alternative text for these images often isn't considered and can be added. Let's look at how this can be done and any considerations that can be made.
When inserting an image, you can secondary click on it. In the menu that opens, you should see a "View Alt Text..." menu item. Selecting this will open up a panel in the same area as the main accessibility one. Here you should see a text box to enter the alternative text you want for the image. There is also a checkbox for marking the image as decorative and some nice explainer text on why the alternative text is important.
Choosing when and what to write as alternative (alt) text can be trickier than it sounds. As a general rule of thumb, if the image gives the supporting content extra information, context, or emotion, then it should be described with alternative text so that people using screen readers do not miss out on it.
Objects such as icons, shapes, and background images (in some cases) do not necessarily need to be announced if they offer no relevant and important information; this is where the decorative checkbox comes in. This can be checked to ensure that accessibility requirements are met but that people do not need to hear about this image.
The decision can be particularly important in digital documents as they often contain images of charts, graphs, tables, and infographics. Showing information that is vital to the document. It is key that these images are described with the content they display. Otherwise, people are excluded from being able to consume the document and may miss out on something vitally important.
A11y Project - using alt text properly
There are a few instances when we've seen images added, and the software does its best to add alternative text. Whilst this is quite cool and undoubtedly improving with the current AI trends, alternative text still needs human context and consideration. The accessibility checker will flag images with alt text set in this way as a warning, and it's worth checking these to make sure something nonsensical that will mislead somebody has not been added.
To generate the alt text, you can use the "Generate alt text for me" button.
Sufficient colour contrast is required so people can easily see the content. It's measured by programmatically checking the contrast between a background and foreground colour (for example, text against the background it sits on). Many automated tools check this on the web, and the document accessibility checker will also flag errors where they are insufficient.
Keeping on top of these and checking in often is important, especially if you're creating template documents that others may reuse. This one is easy to fix and can have a high-impact result by ensuring people do not miss vital content.
As I would also advise with web accessibility, it's generally not a good idea to try and include text over the top of images, it can make finding a good contrast very hard. If this is needed, try and still include a solid background colour behind the copy.
While there doesn't seem to be any in-built tool for checking the contrast ratio (the issues are just reported as "Hard-to-read to contrast"), there are many tools available online that you can use to check.
A colleague at Code, Alex Clapperton, has built a brilliant contrast checker- colourcontrast.cc that can be used on the website and as a Chrome extension. And you can also download apps that allow you to check contrast anywhere on your screen (so when in other apps etc), for example, the TPGi colour contrast analyser.
Just as content design and structure are an important part of accessibility on the web, the same can be applied to digital documents. After all, they are effectively just larger content pages. In Word, you can choose heading levels. This can help visually and hierarchically break up documents, making them easier to read and scan.
People using screen readers may wish to navigate documents by the headings, therefore ensuring they are set, logically ordered (heading 1, heading 2, heading 3, for example, not skipping levels), and suitably worded can go a long way to making a document more readable for everybody.
Word offers styles for document titles, subtitles, and then heading levels. These can be found in the styles pane, where you can add more levels if needed.
The content structure of presentations is made up slightly differently, as it's a series of broken-up slides, as opposed to a single document/body of content. However, it's still important to ensure that each slide has an associated title. After all, if these are missing or duplicated, how is somebody who wants to quickly navigate the slides supposed to know what they relate to?
Duplicate slide titles can happen when dedicating sections of presentations to one topic, having the same slide title repeated, and then revealing a bit more information on each slide. If doing this, it may be worth considering using a staggered animation to bring this content in one slide.
The most common examples of missing slide titles I see are when the slide just contains a full image, a logo, etc., and these images have no alternative text, and the slide has no title. This slide would not be readable to somebody using a screen reader, and they would miss any information or context it contained.
To open the slide content outline, select one of the missing slide title errors from the accessibility pane, or use View - Outline menu items.
From the accessibility checking toolbar, you can set slide titles in a couple of ways. You can assign a slide a title (if there is some existing text, for example), or you can set hidden slide titles too. Setting this will show the title you enter above the slide. When you present, it will not be seen. Crucially, however, it does give the slide an associated title.
Powerpoint seems to flag many instances of this when running the accessibility checker. They are flagged as warnings, so things need to be manually checked.
Reading order is dealt with oddly, however, and it can be hard to find. In the accessibility checker view toolbar, find the "Arrange" panel and open the little dropdown arrow. This should then show a "Reading order" menu item. Selecting this will open a panel (in the same location as the accessibility checker) with the different elements on the slide in order.
The reading of slides determines what order the information on them will be interpreted by assistive technology such as screen readers. This is important to avoid confusing information in the wrong order that could change its context, etc.
This displays all the elements on the slide that would be read out and the order in which that would happen. The slightly odd thing is that Powerpoint decides this from bottom to top. So although it can be tempting to put the title at the top, then the subtitle, the title would go at the bottom and then the next bit of information visually, and so on.
To re-order the items, you can drag them around to re-order. This doesn't affect the order visually.
Tip: Remeber to keep in mind that this seems to be handled differently between Mac and Windows app (see differences at end of article).
Find out more on slide reading order
Emails form a large part of digital communication in nearly all organisations. Although many can simply be quick notes or small blocks of text, it's still important that they are accessible and inclusive for people that may need to know about the information they contain.
Outlook also has an accessibility pane to check your email content. This can be found by using the three dots at the top right when composing an email.
In some app versions, you can also select File > Options > Accessibility and turn on little tooltip accessibility notifications as you compose emails.
Many websites link to or offer downloads of PDF documents that contain important information. PDFs can be notoriously difficult to make accessible and require a lot of upkeep and maintenance. There are ways to check the accessibility of PDFs using tools such as Adobe Acrobat, but it might not be possible to use software like this, and can often have large quantities of large, complex PDFs.
This section has been included slightly separately because I would generally recommend asking if, rather than using a PDF to display information, a static page on the website would be a better alternative. Not only does it save people from downloading a document, possibly coming at a larger data cost, but as long as the site is accessible, it will inherently be easier to make the information accessible.
One of the things I've found most frustrating when trying to learn more about digital document accessibility, demo it and pass that knowledge on is the differences in features the applications offer from Mac to Windows to Web versions.
I believe that accessibility should be the core of any product, and not including some across different OS versions is highly frustrating.
Here are some examples that I've come across and to watch out for:
There is more information on checking accessibility whilst working in office apps.
In this intro to digital document accessibility, we have run through some common accessibility issues that can occur when putting together digital documents. This list is by no means exhaustive, but with continual checking of these documents as we produce them, many can be easy to fix and keep and top of and have a massive impact on making them inclusive and allowing people to consume your content. You never know who may need the information in them one day.
Some top-level things to take away and consider:
Here are some useful articles that explain how you can check accessibility in the software mentioned in this article. Where applicable they cover any differences between the apps on various operating systems.
