Sorry for the cryptic title but I've just introduced my 5 year old boy to the timeless classic, "Princess Bride", and riddles and Buttercup came to mind... but anyway I digress. The real answer is a cool project I've been involved in called ButtercupReader - it's a showcase of how Silverlight 2.0 can be used to build an application that blind and partially sighted folks can use to read digital books (DAISY 3.0 formatted books that is).

We worked closely with Microsoft (the sponsor) and The Royal New Zealand Foundation for the Blind and in a relatively short period of time (weeks not months) we came up with a pretty cool application.


I'd like to showcase some of the accessibility features of ButtercupReader and talk a bit about how Silverlight could really change the way we view applications over the web.

Web Standards and Accessibility

One of the interesting aspects of this project is that, while we have built a highly accessible application, it does not comply with existing accessibility web guidelines (at least not here in NZ).

In New Zealand, like other countries, we have a set of accessibility web guidelines (New Zealand Government Web Standards) we have to follow when building sites for government departments and agencies. The goal of the guidelines is clear - to make web applications accessible to as wide an audience as possible without disadvantaging those with disabilities. And I'm totally behind this.

However, the downside to the standards is the limitations they place on building rich web user interfaces. The web is a restrictive medium at the best of times but not being able to rely on JavaScript (13.1) makes things even harder(AJAX anyone?). Of course you can invest time and effort to ensure sites degrade when JavaScript is not enabled but this is rarely affordable on typically tight budgets.

It would be great if ButtercupReader prompted a rethink in the web standards community about how we can provide accessible applications over the web.

Even building an application in HTML is itself a major limitation. We all know that HTML was never intended to be the foundation for delivering complex web applications. I remember a year or two back when  I thought the end of our obsession with the web was coming - smart clients were the promise of a new future and I could sense the renaissance of the rich client. But no, bloody Web 2.0 arrived on the scene and everyone went gaga for web again.

So when the opportunity to work on a Silverlight application came along I thought - great, the best of both worlds, a web application but with the richness of a desktop application.

Supporting Screen Readers

One of the reasons that web sites can be made accessible to screen readers is that they know how to interpret well formed HTML (as promoted by the guidelines) and can traverse a document and 'read' its contents. So what happens when you're building an application using XAML? It's pretty easy really, you can mark your XAML up with special attributes to expose accessibility information via a standard known as UIAutomation (UIA). Screen readers, and other accessibility tools, that know about UIA (or its predecessor Microsoft Active Accessibility (MSAA)) can interpret the user interface elements.

    AutomationProperties.Name="Open Book"  
    AutomationProperties.HelpText="Open a Daisy book from your local computer"

Using a tool like UISpy you can see the AutomationElement properties that have been exposed.


Mark Rideout has written a more details overview of accessibility features in his article, Creating Accessibility-aware Silverlight Content.

Other Accessibility Features

Some of the other accessibility features in ButtercupReader include,

  • Shortcut Keys - all functionality is available through the keyboard. One gotcha here is that it is not possible to override the shortcut keys used by the host browser. So, for example, we couldn't trap Ctrl + F to initiate a search. Instead, we chose to implement most shortcuts as single (standard keyboard) keys.


  • Self-Voicing - throughout the application, and when you set the focus to an element, you will hear speech to provide contextual information. For example, when a button receives the focus its name (AutomationElement.Name) will be spoken and when you press Numpad * additional help text (AutomationElement.HelpText) is spoken. Note that this feature relies on SAPI and will only work in IE.
  • Contrast Settings - lots of partially sighted users have a preferred contrast setting. For example, photo-sensitive users will likely choose yellow on black, whereas other users may depend on a high contrast, black on white setting.

image image image

  • Zoomability - clearly, the ability to be able to zoom into text and images is important and Silverlight makes this possible without losing any quality or definition.

image image

So you can see we've had fun on this project and I really hope it opens up some debate on the future of accessibility on the web.