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.

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

~John Brandt

Adobe Acrobat logo

UPDATE: New versions of Acrobat Reader 9 and Professional 9 are now available for download. Updates and patches to older versions are supposed to be available tomorrow, March 18th. Also note that I patched what I could and then today received what I thought to be a very suspicious e-mail with a PDF attachment. Read about it on my other blog

I learned this on Twitter a few days ago and am frankly surprised it has not become more widely knows. Basically, there has been a security problem found in the Adobe Acrobat Reader and Adobe Acrobat Professional which allows certain malware to attack your computer. Initially it was reported that by simply disenabling the JavaScript switch in Reader (and Professional) the problem went away. As an interesting aside, I did this and the very first PDF I downloaded and read an hour later came from Adobe and it required the JS switch be turned back on.

Anyway, in this latest report from ZD Net, it appears that that advice does not mitigate the problem and that Adobe is no closer to a solution than it was a few days ago.

So, the only general advice we can give sportsfans is to avoid opening Adobe Acrobat files until the security issue is resolved. As is stated in the ZD Net article: “All users of Adobe Reader/Acrobat should therefore show extreme caution when deciding which PDF files to open regardless of whether they have disabled JavaScript support or not.”

Here is a link to the ZD Net article with details

Update:  Here is more information from Adobe – but the general consensus is to make sure you have you Anti-Virus programs running and up-to-date.

http://blogs.adobe.com/psirt/2009/02/adobe_reader_and_acrobat_issue_1.html

http://www.adobe.com/support/security/advisories/apsa09-01.html

~jeb