Converting Word to PDF or HTML: Options for Accessibility

I write a lot. I'm writing this blog post in the rich text editor that's provided with WordPress, and I trust it will output nice clean HTML. This is good way of working, but often my writing involves much lengthier documents, and often I'm writing in collaboration with others. The tool of choice for these projects tends to be Microsoft Word, and often the final document will be published either in PDF or HTML.

I also evangelize a lot, encouraging authors to take a few simple steps to ensure the documents they produce are accessible to readers with disabilities. Most authors I work with are writing and editing in Word, and when their document is finished they will publish and distribute it in PDF, motivated primarily by the desire to ensure consistency across platforms, and in some cases to protect it from modification.

I'm also a Mac user, as are many of the people I work with. This blog post documents my quest for Mac-only solutions for converting Microsoft Word documents to accessible tagged PDF and clean, accessible HTML, but my lessons learned on this quest might apply to users of other platforms as well.

Continue reading

Accessible Dropdown Menus Revisited

Back in March 2012 I wrote a blog post titled Accessible Dropdown Menus summarizing my observations with various accessible dropdown menu models, including Suckerfish, Son of Suckerfish, Superfish, Dropper Dropdown, UDM4, Simply Accessible, YUI MenuNav Node Plugin, and the Menubar widget example developed by the Open Ajax Alliance. Of all these, I liked the Open Ajax Alliance (OAA) example the best. Here's the original OAA menubar, and my customized OAA Menubar. Over the last 21 months, my thinking has evolved a bit, aand I've done quite a lot of further experimenting. Since lots of folks have stumbled upon and are referencing my earlier tests, I thought I should post an update documenting how my thinking has changed. Here goes... Continue reading

Choosing a Web Portal: NetVibes vs Protopage

Given the death of Google Reader in July and the eminent death of iGoogle in November, I've been shopping for alternatives. I need a single service that will serve as my dashboard and web portal, providing me with news updates, RSS feeds, and convenient access to bookmarked websites all from a single location. It needs to be cloud-based, browser-agnositc, free, and ad-free.

I've been combing over online reviews and soliciting input from trusted friends and colleagues for months, and a few weeks ago I finally narrowed my focus to two services, NetVibes and Protopage. Since then I've been using both together in separate tabs in various browsers. And finally, I've made my decision.

Here are my impressions based on the features that matter most to me.

Continue reading

Spam and Literature

I've long been an enthusiast of collage in various media—visual art, literature, music. This Fall I hope to unveil my latest musical project, a grand musical mashup that I've been actively working on for over a year, but my interest in such things originated much earlier. Back in the 80's I was into William S. Burroughs's literary cut-ups, and as a computer guy I've come to appreciate the vast potential for digital creativity in this space. For example, check out The Morality Rock Story: Defending Urination, political art inspired (and produced) by Dragon NaturallySpeaking. There's a well-developed and fascinating course on this topic on

I've recently come to appreciate the contribution that spammers are making to this artistic genre. In an effort to slip past spam filters, they're producing digital cut-ups from a wide variety of source materials and combining them in ways that are sometimes quite intriguing, maybe even... beautiful. I'm not alone in thinking this. There's an entire movement of people who are into "spam lit", as examined in

This blog post is inspired by the spam email I received this morning. The focus on college basketball, and the insightful quote from Hofstra's web design manager, are on target given my interests and profession. I wonder if that's coincidence or intelligence? Perhaps they're tapping into the same data about individuals that Google and Facebook are using to provide targeted advertising. Anyway this is fascinating reading, and I feel compelled to share it. Hopefully the author won't sue me. The subject of the email was Introducing, but I'm opting to title this work...

Continue reading

Comparison of Browsers on HTML5 Video Accessibility

Browser support for HTML5 video is constantly evolving, including support for accessibility features. Consider this a snapshot of the current state of accessibility support as of June 14, 2013. It may change tomorrow.

First, here's the code one might use to add video to a web page, including captions, subtitles and text-based audio description:

<video controls width="640" height="480" aria-label="Video Player" 
  <source src="video.mp4">
  <source src="video.webm">
  <track kind="captions" src="captions.vtt" default label="English">
  <track kind="subtitles" src="subtitles_fr.vtt" srclang="fr" label="French">
  <track kind="subtitles" src="subtitles_es.vtt" srclang="es" label="Spanish">
  <track kind="description" src="description.vtt" srclang="en" label="English Description"> 

Some explanations:

  • The controls attribute shows the browser's default player controls. This is optional since some developers may want to create their own controls.
  • There are two <source> elements, since browsers don't all support the same video file formats. They're coming around, but for now WebM is a reliable fallback for browsers that don't support H.264 (MP4)
  • The <track> element is used to synchronize timed text with the video. There are several kinds of track elements, as indicated by the kind attribute (I'm most interested in captions, subtitles, and description).
  • Audio description is not supported by any browser, but the framework is there in the HTML5 spec for possible future support.
  • The default attribute is (according to the spec) optional, but if included is intended to enable that track by default, e.g., to deliver the video with English captions turned on. My tests show that default is actually required; otherwise captions don't work at all in Chrome, Safari, or Opera.

Also, the <video> element receives keyboard focus in all browsers, but in some browsers the video focus indicator is sorely inadequate (a thin dashed line) and it's practically impossible to tell when the player has focus. For this reason I like to add a visual focus indicator using CSS, something like this:

video:focus { 
  border: thick solid yellow;

The observations described below were made with variations on this sample HTML5 video page, which features the AccessComputing video IT Accessibility: What Campus Leaders Have to Say.

Continue reading