Along comes Prezi which can best be described as a whiteboard with wings. Think of a giant whiteboard on to which you have written, pasted and embedded various pieces of text, images, animations and video. Now instead of just viewing this from afar, imagine being able to fly in and out and all around the whiteboard to view the content. If you can’t wait, just run on over to prezi.com and view the demo.

But all of this animation will no doubt reek havoc for my screen reader user friends. I seriously doubt Prezi will be accessible. But I won’t know until I try.

I’m going to start with an embedded version of a test file I made. We’ll see what happens…

Sadly, I must report that SP1 does not solve the issue of fixing the program so that VoiceOver, the resident screen reader for Mac OSX, works with the product. VoiceOver is still not able to read the content of the document pane. VoiceOver will read the toolbars and their content, and says that it is “interacting with document pane view” but that’s all. VoiceOver cannot read the content of the document pane, thus the product is still not accessible.

Now the bad news: MS Office for Mac still does not fully work with VoiceOver. VoiceOver will read the toolbars and their content, and says that it is “interacting with document pane view” but that’s all. VoiceOver cannot read the content of the document pane, thus the product is still not accessible.

_____________

I was hoping that with my recent purchase of the latest version of MS Office for Mac – version 2011 – I would be happily telling you about the outstanding accessibility features of the new version. I was hoping that unlike its predecessor, MS Office for Mac 2008, there would now be the ability to add alternative descriptions to images (see below for an explanation as to why alternative descriptions are important) and that when converting or saving documents made by the new version, the PDFs and HTML pages created would all be accessible. I was sure that given the fact that this is a brand new version of Office it would work fluidly and fully with the Mac OSX native screen reader VoiceOver, a built-in feature in Mac OS since version 10.4 (Tiger) in 2005, nearly SIX YEARS AGO.

But no, I can’t report any of this because, in terms of accessibility for people with disabilities, Microsoft Office for the Mac – 2011 is a complete failure. Not only can you not make accessible documents with this product, it does not work with VoiceOver. That’s right; you cannot read documents created in MS Office for Mac 2001 with VoiceOver.

A VPAT – Voluntary Product Accessibility Template – “is a tool used to document a product’s conformance with the accessibility standards under Section 508 of the Rehabilitation Act. The purpose of the VPAT is to assist Federal contracting officials and other buyers in making preliminary assessments regarding the availability of commercial ‘Electronic and Information Technology’ products and services with features that support accessibility” (quoted source itic.org). The VPAT, as the name implies, is a voluntary statement made by the manufacturer regarding their own evaluation of their product in terms of how it meets the Section 508 requirements. In a rather bizarre finding, the VPAT for MS Office for Mac -2011 proudly notes that VoiceOver effectively works with the toolbars and “the ribbon” of MS Office for Mac 2011.

Unfortunately, Apple’s own office suite, iWork, isn’t much better when it comes to making accessible documents. iWork ’09, the latest iteration, does not have the capacity to make accessible documents either. Specifically, there is no way to add alternative descriptions to images or other objects inserted in a document.

But the good news is that at least VoiceOver can read the contents of documents made in iWorks in addition to working with all of the menus and toolbars.

If you need a word processor, or spreadsheet, or presentation software for your Mac, save your money and download the latest version of open source solution LibreOffice (3.3.0). Oh, if you don’t speak Spanish, the word “Libre” means “Free,” as in no dinero!

LibreOffice (v 3.3.0 for the Mac) does have the capacity to add Alternative Descriptions to image and works completely with VoiceOver. That said, when converting your LibreOffice documents to other formats, you will need to test them to make sure all of the accessibility features have been carried over.

Link to download LibreOffice

Why Alternative Descriptions for images are important in all digital document

Images present the most difficulty to persons using screen reader technology. These assistive technology (AT) devices convert the written text into spoken words or into Braille so that persons who are blind or who have visual impairments can “read” the document presented on their computer screen.

While many, if not most, images in documents are “pretty pictures,” there are times when a document contains an image that is vital to the understanding of the document. Without the Alternative Description of the image, the screen reader generally will alert the user that there is an image but cannot communicate anything else.

Since modern communications between and among people are increasingly done with the sharing of many forms of office documents – including word processor, spreadsheet, presentational (e.g., PowerPoint) and PDF documents – it is imperative that all of these documents be made as accessible as possible, particularly if the intention is to share the document publicly.

Fortunately, the use of the ALT description has gotten wide notice. I’d like to say that it has become well known (and well implemented), but sadly most digital documents are still prepared and published without the inclusion of any alternative descriptions for images.

You probably already know the definition and purpose of the ALT description: it is underlying code added to images that have been inserted into a digital document. The code is used by assistive technologies called screen readers to provide users who are blind or have visual impairments with a textual description of the inserted image.

For years, the debate of “when to use the ALT description” and “when to use the Null ALT” (i.e., ATL=”” in HTML) has been discussed within the accessibility community. My own personal – and completely unscientific – research revealed that there has been no universal agreement on this debate. My observations among screen reader users has been that those users who had become disabled later in life, or who still had some limited vision, preferred that every and all image have an extensive and detailed alternative description. On the other hand, those born blind seemed to me to care less about the “pretty pictures” – as one friend called them – except in situations where the image was a “text graphic” and contained information needed by the user.

For years, I have operated with the philosophy that states “less is best.” I have determined that nearly all of the images added to digital documents are in fact “pretty pictures” and that since they do not provide any important meaning to the document, it is best to use the Null ALT. It should be noted that an equivalent method for adding a Null ALT to digital documents, other than HTML/XHTML documents, does not exist. For word processed, PDFs and the like, you will still need to add some text to create any alternative description. See my series of articles about accessible documents.

My brevity philosophy apparently has some support. A new resource by Australian, Dey Alexander, which takes a similar position as mine, has recently gotten some attention in the accessibility world. Alexander suggests that for purely “decorative” images, and for those “informational” images that repeat information already in the body of the document, the Null ALT is perfectly acceptable. When I was a graduate student, my professors always preached that a well written research document describes everything the person needs to know in the text of the paper and that the charts, graphs and images are only there to support the written content – not the other way around.

At this point I am not ready to discuss the ALT descriptions for completely visual content like graphs and charts. You’ll have to stay tuned for my opinions on that. Suffice it to say that these purely visual elements present a great challenge for people concerned about accessibility and for screen reader users as well.

But getting back to the point of this commentary…I have not (yet) found the definitive explanation for how to write decent/good alternative descriptions.  I suspect that any offering in this regard would be something no one could agree upon and result in more cantankerous debate.

A few months ago, fellow accessibility guy, Cliff Tyllick from Texas offered this suggestion on what a good ALT would/should be. Cliff wrote that a good ALT description would be “…a succinct statement of the meaning you expect a sighted person to get from that image.”

Sounds reasonable to me, but I can see the hair-splitters fighting over the word “succinct.”

For a final thought, I’ll turn back to another article by Dey Alexander called “The 5Es of Content Usability” which speaks to the need for Effective, Efficient, Engaging, Error tolerant and Easy to learn writing. I know that “a picture is worth a thousand words,” but maybe it is safe to assume that you should use less than a thousand words in an ALT description for that picture.

Happy New Year.

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

Ten Tips for Accessible Documents – from Microsoft Accessibility – added 10/15/10

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.

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.

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