Mono Accessibility 0.9 Released!

Yesterday, Brad announced the first release of the Mono Accessibility team's work, which started a little less than a year ago. It's pretty exciting for us to put out this developer preview release; I'm interested to see what people make of it.

The goal of the first phase of our project, which will culminate in a 1.0 release early next year, is to make Winforms applications accessible in Linux with traditional at-spi tools like Orca and Accerciser. In 0.9, we offer support for most Winforms controls (Button, Label, ComboBox, ToolStrip, WebBrowser, etc). In 1.0, we will be rounding out this support to include the remaining controls (DataGridView, TreeView, custom controls, etc), in addition to fixing bugs and improving stability.

It may not sound that exciting to enable accessibility for Winforms apps. After all, you probably aren't using very many on your GNOME desktop today. However, there certainly are some cool open source apps out there (Paint.NET, NClass, etc). And the main benefit will be for overall Linux adoption. There are many businesses, large and small, schools, governments, non-profits, etc...that are stuck on Windows because they have custom applications written using APIs like Winforms. One goal of the Mono project is to provide a migration path for these potential Linux users. Accessibility support is often a requirement, so by making these custom Winforms applications fully accessible in Linux, we are enabling Linux adoption scenarios that would have been too expensive before (rewriting your internal tools is not cheap or easy).

If you are not familiar with our project, let me briefly explain what it is we are doing:

We are implementing Microsoft's "User Interface Automation" (UIA) specification on Linux. During the first phase of our project, we are focusing on the "provider side" of this specification, which offers interfaces that are implemented by the accessibility/automation "provider" for a given control. This is similar to implementing ATK interfaces for a GTK+ widget, if you are familiar with that. We have been writing UIA providers for all of the Winforms controls.

The other half of our work this phase has been creating a bridge from UIA to ATK. This bridge translates between UIA interfaces and ATK roles/states/etc. This is the piece that makes a Winforms application look like a GTK+ app (or any other app written in a toolkit that exposes a11y info over at-spi) in a tool like Orca.



It's pretty cool the way this fits together. Next year, after 1.0 is released, we'll begin the second phase of our project. It includes two major efforts:

First, we will be making Moonlight accessible in the same way we have made Winforms applications accessible. We will create UIA providers for Moonlight controls, and they will automatically gain accessibility via the exiting UIA<->ATK bridge.

Second, we will implement the "client side" of the UIA specification. This is a set of interfaces designed to allow an accessibility tool (think Orca) to interact with accessible applications. It is similar to the at-spi interfaces, and we will in fact be implementing it as another bridge, this time translating "client" UIA calls into equivalent at-spi calls. The benefit here is that as Windows developers create accessibility and automation tools using the UIA interfaces, they will be portable to Linux (and vice versa).

Accessibility is a great feature for users and potential customers. Automation support is invaluable to testers, software QA, and even users who just want to streamline common tasks. With the release of Mono Accessibility 0.9, we are growing the landscape of accessible applications. We look forward to your feedback (and bug reports)!