Accessibility: August 2009 Archives

Creating an Accessible PDF from Word on the Mac

| | Comments (0)

Developing accessible PDF from a Word File on the Mac is sort of a trick question because the tool set is different than that on Windows. It's not terribly difficult, but you DO have to purchase the full version of Acrobat (I know, accessibility shouldn't cost this much). But if you have Word and Acrobat, here's what you can do.

In Word

Some tips for creating accessible content in Word are the following:

  • Use a legible font - Times New Roman is a default, but it isn't so legible. Verdana and Arial are classic sans-serif choices, but you may want to try , but if you prefer serif text, you may want to consider Palatino or Bookman Old Style. I am also a fan of Chalkboard (versus Comic Sans) and Optima.
  • Use Heading 1, Heading 2 styles - In many contexts, these Word styles will correspond to H1,H2 tags in HTML. Even if your Word file is headed for Dreamweaver, using these styles may mean they convert to H1/H2 in a cut and paste operations.
  • Use the list tool in Word (instead of using Option+8 to manually insert bullets). Again, the list will be recognized as UL or OL lists in other documents.

Convert to PDF

I will assume that you will take the free option and print as a PDF file in the Mac print dialogue. The result is that text will be preserved as text, but it will not be "tagged" into levels according to Adobe Acrobat.

Printing to PDF is not inaccessible, but it is not as accessible as it could be.

Adding Tags in Acrobat Professional

Now comes the finicky part.

  1. Open the .pdf file you generated in Acrobat Professional 9.
  2. To see if a document is "tagged", open File >> Properties. In the pop-up, there will be a Tagged PDF field at the bottom. If it's set to "No," you have to add tags.
  3. Click OK to close Document Properties window.
  4. Now go to Advanced >> Accessibility >> Add Tags to Document. A processing slide bar will be displayed.
  5. To actually see the effects of tagging, so to Advanced >> Accessibility >> Touch Up Reading Order. You should see a pop-up window along with series of gray boxes with numbers in the upper right. The numbers indicate that the order the block will be read in.
  6. To add an ALT tag to an image, make sure the Touch Up Reading Order window is active. Then select an image and right-click (or control-click) and select the option to add an ALT tag. Note: Beware of multiple images together. Apparently the PDF conversion merged them into one big image (Sigh).

There are more accessibility tools to explore including a Tag tab and the table cell editor, but I think you get the idea....

Accessibility Developer Disconnects

| | Comments (1)

I've been exploring some accessibility issues and have noticed some disconnects in how accessibility can be implemented. It seems like that the community is making some critical assumptions such that 1) All online content is developed by professionals or that 2) everything is on a PC and 3) that developers are really going to manually disable Flash to check their content.

Online Content from "Non-Professionals"

One of the bigger challenges here at Penn State is that "online content" is actually being developed by instructors and students. In theory, we would like all "online course content" to be accessible, but if that were true literally then we would require that every podcast file be transcribed, every Office document & PDF file be tagged, every page generated by a content management system be accessible, and every image labeled with an ALT tag.

This can be done but it requires time and worse, some specific training. Yes, you can an ALT tag to an image in Word, but you have to know to right click and look for the "Alternative Text" field (and it only works on Window). Similarly, you can tag a PDF file, but you need to check the advanced menus in Acrobat (currently costing about $60) to make sure it is done right. This is much more difficult than clicking a "Convert to PDF" button (and more expensive as well).

The allure of the current online tools is that they are easy. Anyone can make a video, but right now only a few can make one with captions.

Mac Developer/PC User

An quasi disturbing accessibility trend I am noticing is lack of information/ability for Mac developers on how to make output accessible. Although most tools such as the JAWS screen reader assumes a Windows audience, it is a fact that many multimedia developers, particularly those for video or Flash are on a Macintosh.

This wouldn't be a problem except that the accessibility community seems to write many tutorials assuming everything is produced on Windows. The worst case is Microsoft Office which allows users to add ALT tags to images in Word or Powerpoint...but only in the Windows version. The only way an image in a Mac Word doc can get tagged is to export it to some other format, like HTML.

Many accessibility tools are also Windows only. There's an excellent Office Accessibility Wizard , but guess only works on Windows. Admitedly, most users are on Windows, but again NOT everyone and possibly NOT developers who might be charged with this (because they are on a Mac). There are locations where multiple platforms are available, but not everyone's budget can support both...And in any case, it is a major inconvenience to switch between two platforms.

Debugging Flash

Perhaps one of the most serious problems facing accessibility is developing and debugging accessible Flash content. The good news about Flash is that it works across platforms. Which is why it is being incorporated into so many tools from YouTube to Adobe Connect and more. Flash video is truly the wave of the future.

The bad news is that building in accessibility is complex (you need to build in keyboard alternatives, alternative text descriptions for screen readers and check color contrast...somewhere in the application). Worst of all - it's difficult to discern if the developer has done this. Unlike straight HTML which have checkers like WebAIM WAVE and Cynthia Says, there are no tools to check Flash accessibility without doing something drastic such as disabling the Flash player or testing in JAWS.

There are lots of interesting Web 2.0 tools out there, but it's very difficult to evaluate if support for screen readers, captioning or keyboarding have been built in without checking the vendor specs or running it on JAWS. If you don't have JAWS (say, in a Mac only shop) and can't find vendor specs - you have to assume it's inaccessible. Too bad.

I may think the application is the coolest thing I have seen in a while, but can I recommend it? Sure, but somewhere in the back in my mind I'm thinking "We need a backup."

Dreamweaver Model

Although I am describing three different scenarios, they are symptoms of the same problem. At the moment accessibility is treated as a fairly arcane topic requiring lots of technical knowledge and even hacking of code.

I don't think it has to be this way. One reason I keep recommending Dreamweaver is that their accessibility tools are so easy to find and use. For instance if you drag an image into Dreamweaver, a pop-up window prompts you for an ALT tag. Once you fill in that field, you are done. There are similar prompts for forms, tables and even inserting Flash movies. I suspect that this strategy could be implemented in many more tools such as Word, Flickr or PowerPoint.

Expanding to Flash, could it possible to add more visible prompts to add alt text and keyboard alternatives? It sure would help developers understand that they should be there. The great thing about the prompts is that they recognize that accessibility should be part of the workflow, not an afterthought that only happens if a problem is reported.

Wrapping this blog post, I think my other point is that developers are an important an audience to consider. Browbeating them will only get the community so far (especially if "developers" include teenagers and busy instructors). It really is important to consider how accessibility tools can be just a little more accessible.