Adding alternate text to images in electronic documents is simple. In most authoring software you simply right click on an image, select an option such as "Format Picture" or something equally intuitive, and locate a form field where you are prompted to enter alt text. Unfortunately it’s a bit more complicated than that in Microsoft Office.
First complication: In Office 2007, when you right click on an image you find alt text located under "Size and Position", which isn’t so intuitive. Fortunately all other versions of Office, before and after 2007, have this feature under "Format Picture" where it should be.
Second complication: In Office 2010 for Windows and Office 2011 for Mac (SP 1 or higher), there are now two fields in which to enter alt text: Title and Description. There used to be only one.
In the Windows dialog, Microsoft explains how the Title and Description fields differ:
In the Mac dialog, the description is slightly different but the idea is the same:
This seems like a good model, and is consistent with how we have historically described images in HTML, using the @alt attribute for a short, sweet description and @longdesc if needed for a longer description to describe charts, graphs, diagrams, or other images that require a more detailed description. Since some screen reader users won’t be interested in the detailed description, they can simply be informed that it’s available, and given an option to access it if desired. Some screen readers have historically supported this functionality in HTML, so there’s a part of me that’s glad to see the same model finding its way into Microsoft Office.
However…
How are Title and Description supported?
When we use Microsoft’s built-in conversion utilities to convert an Office document to another format (whether Office 97-2003 document, an HTML file, or a PDF) the result is always the same: The Title and Description fields are combined into a single alt text value that merges the content of both original fields and prefaces each with "Title:" and "Description:".
Thus, the model described in Microsoft’s instructions is not the model that’s been implemented, unless they’re expecting assistive technologies to parse the value of the alt text and extract the title and description from that text, which would be a hack. JAWS doesn’t do this when it announces images in a Word 2010 file – it just calls them like it sees them, and reads the combined title + description alt text as described above. There is no way to read only the title or to request the description separately.
The result is a lot of extra verbosity. The "Title:" and "Description:" prompts are obnoxious if there are enough of them. Also, if authors actually follow the instructions and write lengthy descriptions into the descriptions field, users will be force-fed this extra information, even if they haven’t requested it.
Of the two fields, Description is the only field that is backwards-compatible. It maps to the original singular Alt Text field in previous versions of Office for Windows. So if you add a Title in Office 2010 and open the document in an earlier version, the Title is lost. Similarly, current third-party tools that export or convert Office documents (such as the Save as DAISY Add-In for Microsoft Word and LecShare, which converts PowerPoint to accessible xanaxonlinebuy.com HTML) utilize only the Description field, not the Title field.
Therefore, my recommendation is:
Add alt text to the Description field. Leave the Title field blank.
A Note About Office for Mac
To add alt text to images in Office for Mac, you need Office 2011 SP 1 or higher. There is no support for alternate text at all in earlier versions.
A Few Notes About Exporting to PDF
Office for Mac 2011 can save as PDF, but it doesn’t produce a tagged PDF, so any accessibility information, including heading structure and alt text, is lost in the conversion. So, don’t use Office 2011 for Mac to convert to PDF!
Prior to Office 2010, saving an Office document to a tagged PDF required the Adobe PDFMaker Plug-in.
Office 2010 has the ability to Save As… PDF without a plugin. By default the output is a tagged PDF, with accessibility information such as heading structure and alt text intact and fully accessible. However, when saving as PDF the Save As dialog includes an option to "Minimize size (publishing online)":
It might be tempting to check that box, but if you do so, that automatically removes the structure tags, and with them go all hopes of accessibility. So, you would then need to be sure to select the Options button, then in the Options dialog check the box to include "Document structure tags for accessibility" before finally saving.
I did a quick test to see how minimization and accessibility are related.
I created a one-page Word document that included 163 words and two images. Then I saved it as PDF using three different settings:
- Standard document with tags = 160 kb
- Minimized document, no tags = 143 kb
- Minimized document, with tags = 152 kb
I also tried with a larger document, 41 pages with 18,756 words and two large images. After thrice saving to PDF, I had produced:
- Standard document with tags = 381 kb
- Minimized document, no tags = 356 kb
- Minimized document, with tags = 373 kb
In each case, the minimized tagged file seemed ok – the tagged structure was identical to the standard version. So if file size is a high priority, there is some benefit to minimizing the file, but the trade-off is that you now have an extra step to remember: Always be sure to turn the document structure tags feature back on after choosing to minimize.
In all versions of Office, printing to PDF is different than saving as PDF. Printing to PDF does not capture any of the accessibility information, so don’t do it.
A Few Notes About Saving As HTML
Word can save as HTML, but it’s infamously bloated, invalid, and generally awful code. In Word for Windows, there’s an option to save as "Filtered HTML" which produces a cleaner version. In Word for Mac, the same option is available but under a different name. To produce relatively clean HTML in Word 2011, select "Save only display information into HTML". Not sure what that means, but it works.
PowerPoint 2011 for Mac does not have an option to save as HTML.
PowerPoint 2011 for Mac is also unique in that when an image is added, it automatically populates the description field with a file name. File names do not make good alt text – be sure to replace this. I haven’t observed this behavior in any other version of any other product within the Office suite for many years, although it does bring back fond memories of one of my all-time favorite Microsoft products…
3 replies on “Musings on Microsoft Office: Alt Text, Save as PDF, and More”
Terrill, you are right — by following this approach, people using MS Word 2010 can turn accessible Word documents into accessible PDFs. But there is still better news. The feature you have described is also available through a free add-in for MS Office 2007. If it wasn't bundled with your copy of Office 2007, you can get a free download of the add-in from Microsoft. So for the many folks whose employers are still one step behind the adoption curve, it's possible to create accessible PDFs.
As I'm one of those folks, I don't know how this feature works in Office 2010, but I do know how it works in Office 2007 — and that's rather inelegantly.
If you choose "Save as PDF or XPS" from the menu under the Office button, you would think that you're well on your way to saving the file as a PDF. But the truth is that you have only reached the same dialog box you would have reached had you chosen "Save as…" alone. If you don't pay careful attention, when you finish the process, you'll find no new file. You will have merely saved over your existing document, because the preselected file format is the standard format for the Office application you're using — for example, .docx if you're using MS Word.
The key is to go to the second selection box — the one for file format — and change the format to be saved to PDF. Then the process continues as you've shown above. You see the same dialog boxes and must make the same choices. But I have created many accessible PDFs in Office 2007, and so can anyone else.
Thanks @Cliff for the info about Microsoft's Save as PDF or XPS plugin. I haven't used that, but I've used Adobe's PDFMaker Plugin, which also works in Office 2007 as noted in the article.
It sounds like the latter might save a step and avoid some possible confusion, but if anyone has used both I'd be interested in knowing whether there are benefits to using one over the other.
So did Microsoft screw up Title & Description? I haven’t read the MS Office “Open” XML specification, aka ISO/IEC 29500:2008 (5000 pages…), but I have been looking at how OpenOffice.org and LibreOffice handle text alternatives for images. LibreOffice (and OpenOffice.org) Writer also distinguish between Title and Description. When you read the ODF specification carefully, it becomes clear that Title maps to what we now as the alt attribute in HTML. However, the XHTML export filter (not to be confused with save as HTML!) exports the Description to the alt attribute and ignores the Title. A patch for LibreOffice 3.5 will map Title to the alt attribute, but a solution for Description still needs to be found.
Why this lengthy explanation about LibreOffice? Because ODF’s Title and Description seem to match MSOOXML’s Title and Description. If MS Office users start writing alt text in the Description field while LibreOffice users use the Title field, we get inconsistent practices for authors and incompatibilities when one office suite tries to import or export the other office suite’s native format. Accessibility loses again…
P.S. odt2daisy, the “Save as DAISY” extension for LibreOffice and OpenOffice.org, exports Title to the alt attribute; the next version will probably export Description to a paragraph below the image, unless a better alternative is found. Merging Title and Description in the alt attribute doesn’t seem attractive.