jebsblog

Although it is not considered a major update, Microsoft (MS) recently released the latest iteration of its highly popular MS Office. To me, it appears most of the changes to this version (Microsoft Office 2010) are minor in nature and looks very similar to version 2007 – which WAS a major upgrade. That said, there are clearly things “under the hood” that have been revised and it is always fun to try and discover those new things.

I will not comment on the cost effectiveness of upgrading to MS Office 2010 except to say that if you are still using MS Office 2003, this is probably a worthwhile investment. But if you are responsible for ensuring that the documents coming from your organization meet accessibility requirements, MS Office 2010 might be an excellent investment.

Accessibility Checker

For the new version of MS Office (MSO), Microsoft has made accessibility a priority since one of the new features is the Accessibility Checker (MSO-AC) built into three of the core applications: Word 2010, Excel 2010, and PowerPoint 2010. According to the MS promo, the MSO-AC helps users create more accessible content “by identifying areas that might be challenging for users with disabilities to view or use, and providing a task pane to review those areas, users can fix potential problems with their content.” So far, my limited experience with the MSO-AC has been favorable and here is what I have learned so far:

1. To use MSO-AC, click on the File tab [or Alt-F], tab to, or click on Prepare for Sharing and then tab to or click on to Check Accessibility. The MSO-AC dialog panel will appear along the right side of your screen and show you Warnings, Errors or Inspection Results. The MSO-AC works dynamically (see 3 below) and will continue to run as you create or edit your document. To find the location of the error in your document, click or tab to the Warning statement and your screen will refresh showing the error location highlighted.

In the lower panel of the MSO-AC, there is Additional Information which explains the reason for the Warning/Error and step-by-step instructions on how to fix it.

In developing this tool, Microsoft apparently differentiated between accessibility issues that are minor and those considered critical. For example, including extra characters (Warning: Repeated Blank Characters) is considered minor – issuing a “Warning,” whereas the absence of ALT text for an inserted image is considered critical – issuing an “Error”

2. When creating new documents using the default version settings (not documents saved in pre-2007 versions of MSO), the MSO-AC seems to run smoothly as advertised. Documents created in older versions of Office, or saved in the pre-2007 format, may or may not work as expected. For example, testing some 2003 version Excel spreadsheets yielded an error statement: “Unable to run the Accessibility Checker – Cannot check the current file type for accessibility issues.” Attempts at saving the file in the current (2010) version had no effect on this. However, if the data is copied and pasted into a new Excel 2010 spreadsheet, the MSO-AC worked fine.

When using Word and PowerPoint, the MSO-AC worked essentially the same way (error when trying to check documents made by older versions), but sometimes simply saving the document in the new 2010 version allowed MSO-AC to work. Note to Microsoft: I found this to work inconsistently.

3. One of the best features of the MSO-AC is that once activated in the application it will run dynamically and continue to alert you to accessibility issues via the Accessibility Checker task pane (see image on this page) as you continue to create or edit your document. In other words, in PowerPoint, as you add features to a slide such as an image or chart, the MSO-AC immediately notes that the new object is lacking an ALT text description and provides directions and rationale on how to fix the accessibility error. And if you accidently – or purposely – remove an accessibility feature, MSO-AC will note this and provide a description of the issue, how to fix it and why it needs to be fixed. This dynamic feature allows the author to add the accessibility on the fly, as the document is being created. This feature alone has the potential of making the process of adding accessibility features faster and easier. The feature should be very helpful in enterprise settings, ultimately reducing the cost of training and accessibility auditing.

4. When adding ALT description text in MS-Office 2010, the procedure has been thankfully standardized across all applications. Right clicking with your mouse (Note: there are a series steps to accomplish this task using keystroke alternatives) brings up the Format Picture dialog box. Choose the “ALT Text” option at the bottom of the list and add the alternative text. Unfortunately, Microsoft has chosen to add an input box for adding a “Title” and/or a “Description” to this option. Even though the MSO-AC will “approve” an inserted image that has only a Title and not a Description, if you convert this document into another format (PDF or HTML) the Title will not pass as a valid description for accessibility purposes. In other words, for conversion purposes, the Description is more important than the Title. At this point, it is recommended that users add BOTH a Title and Description to their inserted image and make the content of the Title and Description the same.

Final Thoughts

One can only hope that the next version of MS Office will expand the Accessibility Checker to MS Publisher and all of the products within the suite. Hopefully MS will also include this feature in updates to its version of MS Office for the Mac OS.

As I continue to play with MSO-AC, I will no doubt find new and interesting features. I will post them as additions to this blog article or as separate entries. See the Resources below for links to what others have said about MS Office and accessibility.

Resources

MS Tutorial on how to use the MSO-AC

A blog article from MSO2010 Engineering (January 2010) describing the how the MSO-AC was developed and more about what it checks for.

WebAIM article about how to build accessible documents. Includes information about the new MSO-AC.

Another blog article from Microsoft on Office Web Applications accessibility

Media Access Australia blog about the new MSO-AC

YouTube Video on MS-Office 2010 Accessibility features

NOTE: 9/29/08 – I have added a few more resources about accessible PDFs at the end of this blog entry. If you find (or know of others) I will add them as well. Thanks to everyone who has commented.

I attended the Adobe Acrobat Users webinar a few weeks back and was pleased and satisfied that both what I have been doing, and what I have been advocating others to do, is the proper course of action.

This webinar did indeed introduce me to some of the more subtle nuances of Adobe Acrobat Professional that I was not aware of (although I am not sure if they are all part of the older version of Acrobat Professional that I own). But the dominant message – one that came across loud and clear – was the fervent appeal to create document that are accessible BEFORE converting them over to PDF (Portable Document Format).

In nearly all situations, an author considering the use of a PDF file will have created the original document in some other application. The exception might be a PDF “form” which one might create with Adobe LiveCycle Designer (not exactly Acrobat, but it comes with the Acrobat Pro package. Since MS-Word is the dominate player in this area, it is most likely that the PDF conversion will be from a Word document, but authors may be using MS Publisher, Adobe inDesign or any other document producing software.

I’ve already written about how to make accessible Word documents and other types of documents so I won’t repeat that information here. But I should note that there is a new White Paper from Adobe on Creating Accessible PDF with Adobe inDesign CS4 [PDF] that was just published.

The good news is that accessibly-designed document files will generally convert into accessible PDFs with almost no effort. But, the key here is that the original document has to be accessible first. And in most instances, the original document can very easily be made accessible by following some basic rules. Those rules fit into a nice acronym – H.I.T. The “H” stands for Headings, the “I” stands for Images, and the “T” stands for Tables. This is not to say that there aren’t other accessibility issues to be concerned about, but if the author attends to these three, they will be addressing the ones that often cause the most problems with users of Assistive Technology (AT).

Headings

Contrary to popular belief, the purpose of Headings in a document is not to make the font larger and more distinctive; the real reason is to create a semantic framework for understanding the relationship between and among the sections of content. The use of this semantic layout is essential for persons using AT.

When a person with a visual impairment, using a screen reader or some other AT device, reads a document, they most typically use the Headings to scan the document in exactly the same way a sighted person would scan it visually. Printers and typographers learned long ago that by changing the size, shape and spacing of the font, the reader can more easily semantically understand the organization of the document. The person with a visual impairment uses the hierarchical order of the Headings to semantically understand the document. Using a feature built into their screen reader, the user will simply jump from Heading to Heading to peruse the document. The hierarchical order of the headings cues the reader of the importance of the heading and the content that follows.

If you think of a typical textbook, the document starts with a title page that includes the name of the book and other identifying information (the name of the author, publisher, etc.). The most important information on that page is the title itself. For this reason, the title should always be Heading #1 and all other headings below this should be numbered Heading 2, 3, 4 and so on. While some will argue with me on this point, my general recommendation is to have only one Heading 1 in each document. My logic is that documents have only one Title.

In the typical textbook, there are usually a number of chapters and sub-chapters or sections. In our example, each of the chapter numbers and names would use Heading #2. Sub-chapters would then be styled with Heading #3 and sections within each would be Heading 4, 5, 6 as needed (Note: it is rare to see more that three or four sub headings in most documents). This is illustrated in Figure 1.

It is noted that different applications may call Headings by different names, but they all operate the same way. In Microsoft Word 2007, Headings can be found in the Styles section of the Ribbon. In Apple’s iWork Pages, the Headings elements are found in the Styles Drawer. And in Open Office Writer, the Heading can be found in the Styles drop-down bar.

Images

Images, whether they are on a web page, or in a word processed document, can present difficulties to many people using AT. Screen reading software, when encountering an image in a document, will announce the discovery by stating the word “image” followed by the alternative (or ALT) description provided by the author. Without the ALT description, the screen reader simply announces “image” leaving the user to guess what this means. This can be particularly problematic when the image in question is graphic text, that is, text embedded into an image such as in a logo. Even worse is when this image contains a hyperlink to some other resource. In these cases, without an ALT description, the screen reader user has to go to that new link to find out (or try to find out) what that resource is. It all makes for a rather confusing experience.

When creating web pages in HTML, the author is required to use ALT description for the image. But the author also has the option of using the “null” attribute – that is ALT=”" – which is a command to the screen reader to simply skip over the image completely. When creating other documents, whether they be word processed or PDFs, there is an option for adding a descriptive text to the image. However, unfortunately there is no capacity to make this a “null ALT” so all images must have a description.

As I have discussed in previous articles, most images in documents are simply “pretty pictures” designed to “catch one’s eye” and to make the overall document more visually appealing. They may be used as placeholders, to fill in white space, or to simply attenuate the topic of the writing. But in most cases, they add nothing to the understanding of the document. So choosing an ALT description for a PDF document can present some challenges. The general consensus among the designers I know is to try to keep ALT descriptions short and to the point. Here is a more thorough discussion on how to write good ALT descriptions.

Tables

Finally tables, or tabled data, in a document can present challenges to users of AT if the tables are not constructed correctly. To understand a table, the reader must understand the meaning of the data in each cell and this is typically accomplished by the use of column and/or row headings. Most tables use the top row of the columns for this heading information so most word processors software packages, when they create a table, will automatically assign this top row as the heading.

For example in Table 1, the first column contains the list of months; the second column the number of cars sold. A screen reader will read this as: Month, car sales, Jan, 67, Feb, 56, etc. In other words, the screen reader will read each cell starting in the upper left corner and read across the page to the right and then down to the next row.

In a large table with many rows and columns, a person using a screen reader could easily become lost in the data not knowing what row or column they are on. By the use of the “Table Mode” and special commands commonly found in most screen reader software, users are able to navigate around the table in various ways (e.g., reading columns or rows separately). But if the layout of the Table is not correct, the screen reader user can easily get lost in a sea of numbers and disconnected data.

Table 1.

Month	Car Sales
Jan.	67
Feb.	56
Mar.	34
Apr.	67
May	86
Jun.	56
Jul.	44

Therefore, tabled information in documents should generally be kept as simple as possible and the author must ensure that the layout of tables is constructed in such a way as to make the information understandable to all users. If a large complex table is required, it is best practice to publish this on a separate page in the document (or on a separate webpage if an HTML document). Ideally, a complex data tables should be kept in a spreadsheet application (e.g., MS Excel) and sent along as a separate document.

Converting Documents

Converting documents into PDF format can be done by any number of conversion solutions. Perhaps the most robust converter is the Adobe Acrobat PDFMaker, a plug-in that comes with the Adobe Acrobat Professional suite. However, I have discovered that when using Microsoft Office 2007, the Office Add-in: Microsoft Save as PDF does a much better job of converting Office files with fewer errors and faster results.

If you are using Open Office 3.1, the application has a built-in “save as PDF” feature. However, my experiments with this feature showed mixed results with most converted PDF documents failing to pass the accessibility test.

Note: As of this writing, I have only been able to test Apple iWork08. Regretfully, documents made by this application cannot be made accessible. I have ordered iWork09 and will report on those results on my blog as soon as possible

Testing Documents

Before making any PDF document available to the public, it should always be tested thoroughly for accessibility using the Adobe Acrobat Professional. Apart from actually testing the document with a screen reader like JAWS, Acrobat Professional is the only application I am aware of that tests PDFs for accessibility. Not only will the Acrobat Professional accessibility application test the page, it will provide detailed instructions on how to remedy any errors that are reported. For details on using this feature on Acrobat Professional, please visit the Adobe website or the Acrobat Users website.

Resources

Previous article about Accessible Documents

Accessibility resources from Adobe

Acrobat Users website

Here are some more web-based articles about accessible PDFs:

• Accessibility testing 14 PDF creation tools by Ted Page of PWS
• No Fuss Accessibility by Antonio DaSilva
• Are PDFs more important than web accessibility? by Mark Magennis