The W3C WAI User Agent Accessibility Working Group, in which I participate, is looking for your comments on the current draft of UAAG 2.0. Within the document, you will find specific areas that we are seeking comment on.
User agent, if you are not familiar with it, is the term used by W3C to describe what we more commonly call a Web browser, but it can also apply to media players and other software that provides a user interface to Web content.
UAAG 2.0 will eventually replace the UAAG 1.0 guidelines, which became a W3C Recommendation in 2002. Much has changed on the Web since the release of 1.0 and the current working draft is intended to bring the accessibility guidelines for user agent developers up to date.
Comments should be sent to the WAI UA public comment email address, email@example.com by April 22, 2009.
No, I am not changing the blog theme to Horticulture. Instead, I wanted to write about some digital talking book developments announced two days before today’s official, and snowy (here in New Jersey) start of Spring.
On March 18, the DAISY Consortium announced the second release of Save as DAISY for Microsoft Word, and in the same announcement introduced ButtercupReader, a Web-based DAISY player implemented in Microsoft’s Silverlight by a firm called Intergen. These are exciting developments, and worth taking a look at.
I will admit that I generally don’t rush out to praise efforts by Microsoft, but in this case, their support of DAISY is to be commended, albeit late in coming to fruition.
Save as DAISY, or in short, SAD, is not a new concept, as products from Dolphin Computer Access have provided similar functionality for some time. What distinguishes SAD is its open source approach, and the fact that it is freely available. It promises to provide every user of Microsoft Word the capability to generate a digital talking book publication based on the DAISY open standard.
So, does it work? Yes, but not without problems. Within a few minutes after installation, I was producing, or as SAD calls it, translating, full text and audio DAISY books from my Word documents. I was even able to listen to these books using Buttercup Reader (more on that below). Feeling confident, I made a few, what I would consider, minor editing changes to the first document I had successfully translated, and then started the translation process again. Unfortunately, this time I wound up with no book and a corrupted Word document. I dutifully reported this to the DAISY SAD forum, and await their response. In the meantime, backing up your source documents before using SAD is a good idea, or you may find yourself in a sad state.
In spite of the problem, I was impressed by the fact that I could start with a Word document and in minutes, have a working DAISY publication, with the audio narration automatically generated using the default Microsoft Speech API Sam voice installed with Windows XP. I am not that enamored with Sam’s narration of my fine prose, so I’ll be exploring how to change the speech synthesizer SAD uses when time permits.
Can Save as DAISY convert every Word document to the DAISY format? Short answer, no. DAISY is based upon a model of structured, semantic markup, with guidelines available for authors to aid in correctly structuring their documents. The current version of DAISY (DAISY 3 or ANSI NISO Z39.86-2005), uses an XML language called DTBook, designed specifically for representing the structure of books and other publications.
Converting any document to DAISY requires a process of mapping the structure in the source document to DTBook. Microsoft’s Word format is notorious for the junk that results when converting to HTML, but Office Open XML has attempted, with mixed success, to bring some order to what was often chaos. The key to creating a well structured DAISY book in Word is to apply the same rules we generally use for any accessible document authoring. Extra care has to be taken, though, when using headings (e.g., Word’s Heading 1, Heading 2, etc.) to maintain proper nesting of levels, a key to creating the navigation structure for a DAISY publication.
Save as DAISY is certainly promising, but not apparently without flaws. I would also comment that in Microsoft Word 2007, SAD installs as the Accessibility ribbon, which I think is a little confusing. Though, SAD, and DAISY are great developments for accessibility, the use of the label Accessibility may promise the Word user more than it delivers, especially for those already at a loss on where to find common accessibility features such as adding alt text to an image. Why not just label the ribbon DAISY? Unless, of course, SAD’s goal is to add more accessibility related features for Word documents in the future. SAD’s documentation also leaves something to be desired, and seems more beta than a release 2 product would suggest.
As a concept, being able to produce a DAISY talking book from a mainstream product such as Word is a significant step for accessibility. Adobe should do the same across their products, as has been suggested to them in the past. It should be noted that Adobe has added support for saving as DTBook (or ePub) from within InDesign, a good first step, and FrameMaker’s XML capabilities can support DTBook. And, there is even a Save as DAISY plug-in for OpenOffice Writer. Let’s see if other mainstream products will follow this lead.
Buttercup Reader was a pleasant surprise. This isn’t the first time that Silverlight has been used to build a DAISY player, as Tanakom Talawat has had a beta of his DAISY Now project available since last year. And it joins other Web-based DAISY players such as Charles Chen’s cool Dandelion prototype.
As a Web-based player, ButtercupReader comes across as slick, functional, and well designed, especially given that it is termed an early demo. I have had my concerns about Silverlight, but perhaps now I will be a bit more open minded. The developers of Buttercup, Intergen, state that they will be using the player as a vehicle for demonstrating how to create accessible, rich internet applications using Silverlight, and have a presentation and demo at MIX09 to get the ball rolling.
I tested Buttercup using Firefox on both Windows XP and Mac OS 10.4, and was able to read the supplied samples as well as my own local DAISY books. Buttercup requires locally stored DAISY books to be within a zip archive, which meant that I needed to zip up the books I wanted to read. Given that it is only demo, we can ignore that the bookmark feature is not functional, and a common DAISY player feature, speed up and slow down of playback, is not present. However, Buttercup is a great start, and I hope the developers follow through and turn it into a full product.
The section on the
alt attribute in the current HTML5 working draft that begins with “What an
img element represents depends on the
src attribute and the
alt attribute” really seems to miss the point. This is the semantic Web era, correct? Isn’t the conditional logic of the current draft really trying to affix a meaning or purpose to an image in all the wrong ways? Ambiguity is not the way.
I can just see the HTML5
alt attribute logic working so well in other contexts:
The Product Safety Agency announces a new toxicity labeling system. All poisons are clearly labeled, except when they are not poisons, as indicated by a blank label. For products whose toxicity has yet to be determined, no label will be affixed.
Other applications of this logic come to mind, all equally frightening.
The very idea that
alt be changed to a non-required attribute troubles me much more than the complete departure of
longdesc. There have been ongoing discussions on this issue for some time, often heated, and WAI-PF is working on a response to the HTML WG.
Having been an early supporter and implementer of
alt, I see only one real solution.
role attribute is a key foundation in the WAI-ARIA efforts. Within ARIA, a
presentation can be applied to an image, indicating that the image is not part of the page structure and should be ignored by assistive technology.
Explicit indication of the authored intent of the image goes a long way toward reduction in ambiguity. Rather than trying to infer the role of an image from the presence or absence of the
alt attribute content, or of the attribute itself,
role would explicitly define the authored intent of the image and its purpose in the interface.
I think, however, the current ARIA roles are insufficient (and yes, I will be responding to the request for comments on the Working Draft).
Following are two example cases of images with blank alternate text and the role attribute.
A purely decorative color bar:
<img src="colorbar.png" alt="" role="presentation" />
An image in a photo library, for which no alt text has been specified:
<img src="kif001293.jpg" alt="" role="content" />
I am not suggesting
content as the ideal role for images which have a need for alternate text or description. One could go off the deep-end and suggest photo, figure, map, etc. This needs to be simple, and content is a starting point, but not the end point.
Of course, we can still have an accessibility problem if
alt is still left blank, but we won’t be guessing as to whether the image is decorative or the author just hasn’t gotten around to specifying the alternate content.
And as someone who once developed a non-visual browser, creating rules for dealing with alt (and its absence), and likely being among the first to implement
longdesc support (for what it was worth), having the ability to know that an image is really content is an important plus. Further, knowing that an image defined as content happens to have a blank
alt value could motivate the user agent and assistive technology to look for meaning where it can be found. ARIA’s
describedby would be an obvious choice.
As an occasional optimist, I do have hope that technology will help mitigate the problematic assumption that content authors will neglect specifying
alt (for a variety of sometimes understandable reasons). Authoring tools can become a bit more clever (or manipulative) in their approach to gleaning image
alt text from authors. And, embedded metadata, such as EXIF, may give us some clue about an image, where it was taken and when. It is not unlikely that we will see more useful metadata available, either in the image itself or queryable. And research is obviously looking for ways to solve the large photo library problem, and that can only help accessibility.
alt required in HTML5, add
role as a required attribute, encourage use of
aria-describedby. Problem solved?