Wednesday, November 26, 2008

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)!

11 comments:

Unknown said...

is there an addon plan to test UI on monodevelop?

Sandy said...

@duff: No, nothing like that is planned. What did you have in mind?

Anonymous said...

Maybe Im getting this project wrong here but does this project enable lets say gnome style (instead of windows winforms style) on winforms applications through mono?

Sandy said...

@Anonymous: Yes, you are misunderstanding this project. Adding accessibility (a11y) to Winforms applications means making it usable by people with disabilities, who interact with their computer using tools like Orca (a screen reader).

Accessibility support also allows for automation of the UI, which is useful to testers. See Strongwind or Dogtail for examples of UI testing tools that use GNOME's a11y support.

This project has no effect on the visual style of winforms applications.

Anonymous said...

Congratulations on the first release.

When do you plan to implement the UIA client code so we can start creating managed ATs?

Sandy said...

@doffm: Well, our roadmap shows the 1.0 release of our phase 1 work on February 27th. So we won't even start phase 2 (moonlight and client-side) until then. We have not yet finalized our schedule, so I don't know if we'll be working on the client API first or Moonlight support first. I do know that that phase 2 is scheduled to be complete around this time next year, though.

Unknown said...

I think to something similare to http://msdn.microsoft.com/fr-fr/vstudio/dd262186.aspx
but it is in french...

Anonymous said...

@Sandy: Thank you for the clarification.

Pablo Santos said...

Hi,

Great job guys!

One question: I'm currently trying White Project http://www.codeplex.com/white. Do you know whether it could be compatible with your implementation?

It would be simply great for testing.

Sandy said...

@pablo: I haven't read a lot about White, but my understanding is that they provide an API built on top of UIA *and* Windows messaging calls. I'm not sure how well that would work on Linux; even if it did work, it might only support Winforms apps. More research is required to say anything definitively, though. It certainly is a cool project from an awesome source.

Pablo Santos said...

Hi,

Yes, the project looks cool, basically because they provide a way to write tests in .NET, which is always welcome.

I posted a screencast showing our Plastic system under test. We're most likely moving towards creating a new test suite in White.

http://codicesoftware.blogspot.com/2008/12/white-testing-plastic.html

Since our app is MWF based on Linux/Mac, it would be cool to automate its testing. I'm looking into both LDTP and this automation one.

I've seen this article too:
http://www.mono-project.com/Accessibility:_Test_Strongwind_Basics

What would be really great is being able to write StrongWind tests in Mono...