Rich is a Distinguished Engineer in the IBM Emerging Technologies Group responsible for accessibility strategy and architecture for Software Group. Rich chairs the IBM Accessibility Architecture Review Board (AARB) and is an IBM Master Inventor. Rich has broad responsibilities spanning all business units withn IBM and is a working member in W3C WAI and HTML working groups as well as the OASIS ODF Accessibility sub team. Rich led Java accessibility development at IBM including the IBM/Sun accessibility collaboration. Rich is leading the DHTML accessibility effort in the W3C and runs an architecture team within IBM responsible for accessibility for the Web, Eclipse, UNIX, Windows, and Java platforms.

WAI-ARIA Growth Cataloged

It is nice to see more players like Adobe join in.

Categories : [   ARIA  |  Firefox  |  W3C  |  WAI  ]

Mar 28 2008, 02:03:43 PM EDT Permalink

CSUN 2008: IBM's Long Term Accessibility Efforts Paying Off

Web 2.0 Accessibility

WAI-ARIA: WAI-ARIA presence grew dramatically at CSUN this week. Until the Microsoft announcement on IE 8 for WAI-ARIA a number of companies had been working on supporting WAI-ARIA but not releasing it. That changed. Google Web Toolkit 1.5 supports WAI-ARIA as does Google Reader. GWT 1.5 should come out in a formal download within the next 2 weeks. Adobe indicated that Adobe's Spry framework for AJAX was adding WAI-ARIA support which will give us tooling support in Dreamweaver. The Apollo SuperNova screen reader/screen magnifier is adding support for it with IAccessible2 support targeted for later this year. WebAIM is adding support for WAI-ARIA as well. Also, the University of Illinois Firefox accessibility plug-in is starting to mature and there are a number of nice features that will help us in WCAG 2.0 support. Google had 2 sessions on WAI-ARIA this week and I saw Microsoft engineers attend at least 2-3 sessions I sat in where they announced to the room that they had support for WAI-ARIA in the IE latest beta. WAI-ARIA is a home run!

On the negative side, aside from Dojo I did not see any demos of any Google or software. I suspect they are not fully debugged. Yahoo and the Paciello Group gave a presentation on their WAI-ARIA implementation in Yahoo Mail and highlighted some of the challenges retrofitting an existing rich internet application. Also, developers are having problems with Window-Eyes and JAWS as they don't automatically switch in and out of application mode. Also, if you turn off browse mode in Window-Eyes a minor refresh can cause it to fall back into browse mode. I discovered Microsoft has a minor problem with the IE 8 beta where you have to turn on WAI-ARIA support in the registry. This is a beta so I suspect this will be corrected in subsequent drops.

• Mashup Session: My mashup session was full with some people standing. Unfortunately, CSUN instituted something new this week which required you to sign up ahead of time and many people were turned away. Many attendees commented that the need for personalization will be very important going forward to address this problem. For most, the mashup problem is new. Here is the mashup presentation.
• Fluid Session: Again, this was a full session. People are very interested in Fluid in that it has created a social network for collaboration of UX designers, accessibility engineers, and application developers. Matt King and I will be discussing how we might use some of its principles into usable access. A number of attendees stated that they wanted to join and participate in Fluid.
• Dojo Session: Becky Gibson's session was very well attended, especially given session given the lateness in the day on Friday. A lot of questions were generated.
• Browsers: In the mind of end users, Firefox was "top dog" at this conference with respect to their accessibility efforts. That said, application developers are looking to IE fully supporting of WAI-ARIA. Microsoft received a lot of well deserved, positive press for their announcement to support WAI-ARIA in IE. There was no word on Safari from Apple on WAI-ARIA support at the conference.

IAccessible2

The IAccessible2 panel was packed! All major screen readers were implementing IAccessible2 support: NVDA, JAWS, SuperNova, and Window-Eyes. Additionally AccProbe and Freedom Scientific's Magic support it as well. There were a lot of great comments from the panel. Adobe would like us to address extensibility and assistive technology vendors and developers on how to implement support for IAccessible2. Also, Adobe had asked that there be performance enhancements for AT handling of large documents.

There was a strong emphasis by ATVs, like Freedom Scientific, that the fact that they were involved with the development of IAccessible2 that is something that they know will work. Representatives from GW Micro and Freedom Scientific stated that IAccessible2 is only one tool in their arsenal to provide access. Probably, most

Virtual World Accessibility and a look at 3D Internet

IBM gave a wonderful presentation on their research efforts to make virtual worlds, like Second Life, accessible to blind. They are creating an accessible Web 2.0 navigation panel, using Dojo, to Second Life and they discussed a number of tools they are using to make the environment accessible: leveraging social collaboration to add semantic tagging, assistive avatars, and a "virtual" cane to reach out and find objects to move to. ... Another packed session.

Categories : [   ARIA  |  CSUN  |  Fluid  |  IAccessible2  |  SecondLife  |  WAI-ARIA  ]

Mar 20 2008, 12:47:08 PM EDT Permalink

Microsoft announces support for WAI-ARIA in IE 8 beta

The next question we need to ask is what ATVs support this level of WAI-ARIA implementation in IE 8. If we are going to start playing with this we need an assistive technology (AT). Hopefully, either Microsoft or AT vendors will divulge this information for developers soon.

I want to personally thank Microsoft for making this step forward.


Mar 05 2008, 06:30:01 PM EST Permalink

IBM Contributes new Accessibility Tools Framework to Eclipse

Part of the strategy was to address a growing need to have an open source accessibility tools framework. One reasoning was that propriety test tools on Windows prevented us from distributing a modified version of the Windows accessibility test tools of IAccessible2 to developers. Another reason was that creating test tools from scratch was a time consuming process. Why not take the ones we were creating, internally, and donate them to the industry to build upon, free of encumbrances. Also, due to the overwhelming success of Eclipse, we felt it was an excellent place to build a community around a reusable and extensible tools framework that provide developers, consultants, and new technology providers with a starting point. The result is ACTF.

In ACTF we will be donating new tools like "AccProbe" which will allow you to do IAccessible2, MSAA, and WAI-ARIA testing. We will have new browsers and validation tools as well. The best thing about it is that you can participate, or borrow what is there as you see fit ... and you don't have to sign a license agreement!

Categories : [   ACTF  |  ARIA  |  IAccessible2  |  MSAA  |  Tools  |  Web2.0  |  accessibility  |  eclipse  ]

Dec 05 2007, 06:43:15 PM EST Permalink

Review: Open Document Format v1.1 Accessibility Guidelines Version 1.0

These guidelines are intended for office application developers but they are also good reference material for people new to accessibility. The guidelines introduce the developer to a broad range of disabilities and the corresponding needs that must be addressed. Readers will see that there is a strong emphasis in supporting interoperability with assistive technologies. Full interoperability, is often overlooked when addressing accessibility. The ODF Accessibility Subcommittee focused on interoperability in ODF 1.1 and, as a result, you will see how this document directs office application developers to address the interoperability features in ODF 1.1. You will also notice a strong emphasis in preserving document structure when supporting assistive technologies. Structural semantics is critical to accessibility as access to structural information provides context to the user. Readers will also find a section on preserving accessibility information during the file conversion process.

Given the fact that ODF is totally open and lacks platform dependencies, it is important that ODF office application developers use these guidelines to preserve accessibility on each of the targeted operating system platforms even if accessibility is new to those platforms.

We look forward to your review.

Categories : [   ODF  |  OOXML  |  accessibility  |  documents  ]

Oct 30 2007, 05:43:04 PM EDT Permalink

IAccessible2 Growth - What have you done for me lately?

IAccessible2 is in or being implemented in these products today:

• Notes 8 Symphony Office Suite (today)
• Firefox 3 (being added as we speak)
• Open Office (IBM is just beginning the contribution effort)

Two other major application vendors are adding it to their products as well. It also appears that KDE's QT library may be adding support for it on Windows as it is similar to the UNIX accessibility API. Even more encouraging is the size of these applications. These are not small apps.

Assistive Technologies adopters:

• JAWS
• Window-Eyes

It is being added to the NVDA screen reader. ZoomText has added support for a lot of IAccessible2. We, and the Open Accessibility IAccessible2 working group continue to work with other AT vendors. Open Office and Firefox are a big driver for ATVs. These are high impact consumer products to which developers can have access to the source and see how it is implemented.

New Tooling:

We are creating a new accessibility test tool that will be open source. It will be part of a new open source accessibility tools framework we are initiating. This tool will support Java, IAccessible2, MSAA, and Web 2.0 ARIA-enabled applications running in Firefox. It was designed with input directly from companies like Freedom Scientific. So, it will work with screen reader vendors products, and is designed to assist vision impaired as well non-vision impaired users. For example, a screen reader requirement was to process events in-process with applications to give the same response the AT would expect to receive from the application.

So, why is IAccessible2 so successful?

• We and the Mozilla Foundation provided assistance to ATVs to do the work
• A solid design with a gradual migration path to the new API. - Think why DOS users migrated to Windows over OS/2
• Regular architecture meetings with ATVs held separately with a strong focus in protecting their intellectual property
• Open standards
• Support by key, significant in terms of size, significant with respect to the needs of the consumer, open source products.
• Community building
• No hidden agendas
• Open source projects which generate business for the accessibility community (consultants, ISVs, ATvs, etc.)
• Corporate leadership
• No IP barriers to entry
• Support by major accessibility advocate groups
• Open Collaboration
• Interplay between standards and implementation - ODF standards, IA2 standards, AT implementation, app implementation - all done in parallel (an open coummunity effort)

Lack of these things is why it has taken other accessibility API efforts so long to take off or stumble. I also believe the availability of open source tooling will help dramatically. We modified the MSAA inspect tool internally to test Symphony support for IAccessible2 but then we had to throw the code away because MSAA inspect tool licensing prohibited our releasing derivative works. This set us back a good 6 to 7 months to create a new open source tool we will be releasing in the next quarter.

Since I have taken over accessibility strategy for IBM software I have pushed for one that is open and barrier free. In 5 years I doubt people will remember that IBM started all this (open accessibility on Windows) but I do hope we have a more barrier free, interoperable, accessible environment for which people with disabilities don't have to wait years to access. A look back at early accessibility API work on Windows showed it took years for adoption of that work by ISVs and ATs. IAccessible2 has been able to achieve stellar results in a very short period of time.

Categories : [   ARIA  |  Firefox  |  IAccessible2  |  MSAA  |  OpenOffice  |  Windows  ]

Sep 27 2007, 12:57:00 PM EDT Permalink

IBM's Accessibility Contribution to OpenOffice.org

I recently read an article about the donation, "IBM beats Microsoft over the head with its own code" which took a kernel of a fact -- that IA2 is an extension of Microsoft Active Accessibility (MSAA), a Microsoft-developed technology -- and in the interest of simplifying it for his readership, made a few mistaken conclusions about it.

Let me clarify by saying IAccessible2 is an accessibility API, which you can add to your MSAA enabled Windows application, to provide additional accessibility features needed to handle rich internet applications, rich text, and documents - in this case ODF. IAccessible2 in no way modifies MSAA. Microsoft has made MSAA available to industry as as a standard accessibility API for Windows and modifying it would break interoperability with assistive technology. Furthermore, Microsoft made MSAA available for all to use on Windows. IAccessible2 is derived from work we did on Java Accessibility and the UNO Accessibility API (which I discuss in an earlier blog entry). It is in no way derived from Microsoft work.

IAccessible2 does not just support screen reading. Accessibility features of IAccessible2 also assist alternate input solutions for people with mobility impairments. IAccessible2 also provides support for screen magnification solutions. AI Squared, developer of the industry leading ZoomText screen magnifier, provided valuable feedback in IAccessible2's design as well for this reason.

One of my functions is to co-chair the ODF Accessibility Subcommitee in OASIS. The accessibility subcommittee is pleased to see the article recognize our accomplishment in making ODF accessible and our recent work called “Accessibility Guidelines for Implementations of Open Document Format v1.1.”

Categories : [   Accessibility  |  IAccessible2  |  MSAA  |  ODF  ]

Sep 12 2007, 06:28:56 PM EDT Permalink

ATRC OOXML Accessibility Assessment

While this is a lengthy document, and a good read for the accessibility community, the main point of contention I have with OOXML is it needs an accessibility review by industry as we have done with ODF 1.0. That review resulted in a new ODF 1.1 specification that not only addresses accessibility but also raises the bar over other standards. After all, access to office documents is what we call a "high impact" use case for people with disabilities. It is almost as important as web and email access. A look at the ATRC white paper shows what always happens when you do an accessibility assessment - you drum up numerous problems with the technology or specification in question. Why? - because people with disabilities need to have access to all the features of subject in question. So, how does this apply to this document?

As ATRC highlights, there are numerous parts of the specification that are ill-defined and refer to proprietary behaviors as in section 3.4. What is autoSpaceLikeWord95 and useWord97LineBreakRules mean? Imagine yourself being a non-Microsoft office application, on Windows, MacOSX, or Linux, and you wanted to support accessible access to text through the platform accessibility API. How would you do it? This is no different than an office application needing to render the content. I would also contend that an accessibility review could not be completed until these holes in the specification were filled.

OOXML is now a published specification (ECMA-376) submitted to the International Standard Organization's JTC-1 committee for fast-track (get it out fast no matter what state it is in apparently) consideration of its adoption as an international standard. If this gets approved by ISO you have to question the ISO standards acceptance procedures, given that only one company can implement the standard, and its commitment to accessibility - which in the past has been exemplary. I do hope that ISO lives up to its reputation and demands an international accessibility review and that Microsoft be required to address the findings. If not, the creation of an open standard will have had no impact on the status quo and people with disabilities will continue to be left out in access to other office applications and operating system platforms - and accessibility gaps will still exist in Microsoft Office. To the best of my knowledge blind users still don't have access to MS Office on the Mac.

Categories : [   ODF  |  OOXML  |  accessibility  ]

Jul 25 2007, 09:19:21 PM EDT Permalink

Change in Accessibility Focus on Linux

W3C WAI releases a new WCAG 2 Working Draft

Yesterday, the W3C announced publication of an updated working draft of the Web Content Accessibility Guidelines (WCAG) 2.0. Although not yet a recommendation, the need for WCAG 2.0 is long overdue. WCAG 1.0, which became a W3C Recommendation in 1999, is the standard by which many governments and individuals assess the accessibility of their web sites. But in 1999, the vast majority of Web sites consisted of static HTML content. Emerging technologies, such as CSS and JavaScript, were not well supported in browsers or assistive technologies used by people with disabilities. WCAG 1.0 therefore requires that websites be operable with technologies like CSS and JavaScript disabled in your browser and the focus of the guidelines is simply on how to make HTML content accessible.

A principle-based approach

The new W3C Accessible Rich Internet Applications (WAI-ARIA) specifications for Web 2.0, under development, is an example of such an emerging Web technology. It turns out that the lack of JavaScript support in assistive technologies was not the only accessibility problem for JavaScript implementations. The HTML specification itself was lacking some accessibility features. ARIA focuses on interoperability and usability by a broad range of users, and fills the accessibility gaps in the HTML specification. Browser and assistive technology support are being developed concurrently with the specification, therefore, the combination of JavaScript and ARIA technologies will be accessibility supported by the time WCAG 2.0 becomes a W3C Recommendation.

Two other key positive features of WCAG 2.0 are the supporting documentation and test criteria. Even though the volume of supporting documentation seems overwhelming at first, the Quick Reference is a convenient tool that most developers will want to use to quickly index into the information that is most relevant to them. Testers and evaluators will be pleased to have documented test criteria for each technique. In a parallel effort, the W3C WAI-ARIA work will produce test suites with lots of source code which may be included in the plethora of techniques already provided.

The broader perspective

IAccessible2 Increased Media Coverage

I just finished reading Brian Bergstein's fine article, "Designers Work to make the Web Accessible," Aaron Leventhal, Cynthia Ice, and Becky Gibson gave a great interview. The article was heavily screen reader centric when in actual fact IAccessible2 has extensive mobility access features that well voice recognition and dictation systems as well as onscreen keyboards. IAccessible2 supports features that allow voice recognition systems to edit text in a document without having to simulate expensive system keyboard and mouse input functions. Furthermore, IAccessible2 support collections of named actions, and/or hypertext links, which may be exported by an application for enumeration in an onscreen keyboard.

Here are just a few of the recent articles that went out in latin america:

• Venezuela: IBM Develops assisted technologies for people with disabilites
• Columia: Unlimted accessibility to know the web
• Peru: Searcher for Intraet and Webs

Here are a few of the many launched in China:

• Explore the Human Potential: IBM Explainse the Deep Meaning of Accessible Information
• Creative Technology Helps to Build an Internet Platform for the Blind - IBM Launched IAccessible2

Again, many of these articles have been blind centric. I expect that is because our early demonstrations have been around screen reading. As IAccessible2 continues to grow we will see much broader assistive technology support.

W3C ARIA Specifications Advance to Second Working Draft

The W3C Web Accessibility Initiative (WAI) Protocols and Formats (PF) working group announced the second working drafts of ARIA specifications this week. Accompanying these specifications is a new high level  ARIA Suite Overview of the effort that was created out of the WAI Education and Outreach Working Group.

There are a number of enhancements which developers and project managers should be aware of :

• The Roadmap Deliverables Timeline

States and Properties:

• Features which reduce the code needed to add ARIA accessibility support: owns, activedescendent
• AJAX live region support:  live, atomic, relevant
• Improved support for trees: level, posinset, setsize
• A datatype specifications for values
• A flowto mechanism to allow logical navigation of flow beyond DOM structure
• Ability to detect sorting mechanism such as in a grid column: sort

Roles:

• The log role to support web chat sessions
• Enhancements to the RDF role taxonomy to accomodate AJAX

The live region support is clearly the most important. Live regions are portions of your page which may be dynamically updated, using AJAX techniques, without requiring a page reload. We now have a way to tell an assistive technology whether a region of the web page is live as well as how (atomic, relevant) and when (live) to handle the updates to that region. Through the use of the controls property an assistive technology may detect how one object controls another such as a live region. For example, a region may control an entirely different portlet.

These updates constitutes critical semantics that have been needed for web and desktop applications for some time.

Why IAccessible2 and not UI Automation

I recently visited Andy Updegrove’s blog, following our IAccessible2 (IA2) announcement, and I noticed his question regarding why we chose to create an API other than UI Automation (UIA). I have had similar questions asked both publicly and privately. The answer to that begins in March 2005.

At CSUN 2005, I approached Microsoft with the idea of producing an industry standard, unencumbered, royalty free, accessibility API. Industry needed a comprehensive, standard, accessibility API to support solid interoperability between applications and assistive technologies. We had a 2 pronged strategy. Microsoft, I was sure, would push for the API being UIA and if this was not successful our alternative was a new accessibility API we were creating out of project Missouri that you all know now as IAccessible2.

At this time, the UNIX accessibility efforts were such that a new API was tenable although we would have, and did, take a lot of heat for suggesting it. That said, we felt it worth the effort to make this happen. We were willing to use UIA even though we had reservations which I discuss later in this blog entry. An indication that this effort was going on can be seen in a June 2005 Microsoft announcement. By October 2005, we were unable to make this happen and we had to cut and run because it would hold up our UNIX accessibility efforts in the Free Standards Group (FSG) as well as our new office suite enablement work for Workplace.

At this juncture I told Microsoft that we would take an alternative approach to achieve the goals I outlined above. Shortly after, the State of Massachusetts laid down the aggressive timeline for ODF accessibility and Missouri kicked into high gear across IBM. If we had stuck with UI Automation we would not have met the states needs, as you will soon read. Also, through industry contribution, UNIX accessibility had now matured significantly and going back to UIA would be similar to a slash and burn effect for that platform. Apple was in a similar situation. Fortunately, in the background we had been creating IA2. The goals of that project are defined in my previous blog entry.

My reservations about UI Automation then and today are multi-faceted and this is a result of a similar situation which happened when Microsoft released Microsoft Active Accessibility (MSAA) in 1995. So, let me digress:

MSAA (formerly OLE Accessibility) was designed with Assistive Technology Vendors (ATVs) input but with little contribution by the developer community creating a chicken and egg problem. Upon release it had little to no ATV support because application vendors did not implement it. This was because ATVs did not support it and because very little guidance was given to developers on how to implement it. As a result, MSAA had great promise but suffered from a number of gaping holes such as: support for rich text; tables (spreadsheets, etc.); hypertext links; relationships; and multiple named actions. Over the years industry vendors have produce a plethora of proprietary APIs, including Microsoft, to expose the information needed to fill the holes. ATVs have had to aggregate support for all these APIs and less reliable, dated, engineering techniques like “screen scraping” to produce an offscreen model. The result has been a nightmare for Assistive Technology Vendors (ATVs) and application developers to support and the results are often unreliable. In fact, one could argue that no single, comprehensive, standard, accessibility API for Windows exists.

Microsoft developed UI Automation with the intention of filling these holes but many similar problems exist today. Today, assistive technology participation in UI Automation appears to be limited to design time. Currently, the major ATVs don’t support UI Automation (UIA).

UIA is divided into a provider(application) and client side (ATV) API. The client side portion runs in managed code called the Common Lanugage Runtime environment. Today UIA requires ATVs to rewrite all or part of their software to run in a managed environment to access them. This has prevented widespread ATV adoption of UIA and thus application vendor support. Microsoft needs an unmanaged client-side UIA implementation, which ATVs can support, but that is not currently available for Vista or XP. Given the absence of an unmanaged UIA API and the extremely few applications that support UIA, we believe UIA really needs more ATV testing to prove readiness for wide scale adoption. Microsoft's challenge will be to get large applications, like MS Office, and ATVs to support UIA to work out any defects.

Now, all this said, the Vista desktop needed to be accessible. Vista access by screen readers is a combination of MSAA and screen scraping. In short, access to the Vista desktop is like XP today. Screen scraping is limited to the unmanaged environment. For managed applications Microsoft provided some basic UIA to MSAA mapping and some text access but the accessibility is limited. Consequently, support for managed applications is currently dependent up on a limited client side unmanaged API layer. Due to the limited number of managed applications, there is little business justification for ATVs to support them.

Getting back to IA2, I will turn the clock bat to 1997 when IBM and Sun got together to collaborate on a new accessibility API for Java – now called the Java Accessibility API. You can learn about the early work in my 1998 CSUN pitch with Phill Jenkins. The presentation includes a link to guidelines I created to assist developers. A new Java Accessibility API was needed because of MSAA’s dependence on other technologies, like offscreen models, which were not available on other platforms. Additionally, IBM created a pure Java Screen Reader called the Self Voicing Kit for Java to test the implementation on Swing with a real, scriptable, screen reader. This work is something both Sun and IBM are very proud of as it is also the basis for the work on UNIX, UNO, and IA2. The API works. Java’s accessibility problems today are not with the API but the transport layer in the Java Access Bridge. The use of MSAA and IA2 would be an excellent replacement.

We do believe that more work is required for application vendors to use UIA. With IA2 we complement MSAA, as is, and we have fully tested ATV support today. To validate this I refer to GW Micro's endorsement of IAccessible2:

"MSAA provides a great base for allowing applications to make themselves accessible. However, over the years it has become apparent that MSAA lacks important information needed to make certain elements accessible. IBM has taken the lead on extending MSAA, using the new IAccessible2 interface. IAccessible2 resolves the major holes left with MSAA by enhancing it, not replacing it. Switching from MSAA to other standards, such as UIA, is possible in the future, but is likely to be a very expensive endeavor. IAccessible2 allows you to keep existing MSAA support but then allows you to enhance in areas that MSAA falls short. GW Micro has been working with IBM to fully integrate IAccessible2 into its screen reader, Window-Eyes. Having Window-Eyes support IAccessible2 allows application developers to test using serious accessibility tools. IAccessible2 completes MSAA."

-- Doug Geoffray, Vice President of Development, GW Micro 

The effort to enable IA2 supporting applications on other platforms is significantly smaller than with existing APIs. We have heavily designed and tested IAccessible2 to work on an entire office suite and with input from the Mozilla foundation who would implement this on Firefox. As indicated here, and Peter Korn's web log, IAccessible2 is not new in that it is derived from working APIs we helped design and implement on UNIX and Java. Also, IA2 was designed with the help of ATVs like Freedom Scientific and GW Micro during its implementation on IBM's Productivity Editors for Notes 8.

During the design of IA2 we added support for W3C ARIA unlike UIA. We believe changes to UIA are required to support Web 2.0. Going forward, IAccessible2 is an open standard and will allow others in industry to enhance it as new technology warrants. Proprietary APIs are much more restrictive and this kind of participation is very difficult. We believe they can both exist on the same platform as both are built on top of the COM transport layer.

An important benefit, for ATVs, is that they can continue to run in-process to get the performance enhancements they have realized with MSAA. This may prove difficult with the provider/client side architecture in UIA. For the non-techies running "in-process" is like talking to the person next to you vs. shouting across a street. The noisy interruptions will cause the conversation to take a lot longer to complete.

In short, because UIA has not been used by major application vendors and ATVs we believe it will take some time to be fully realized. In the mean time IAccessible2 will already have been implemented to support large rich desktop applications and W3C ARIA with full ATV support. UIA's immediate benefit may be for managed applications.

Beyond the planned IA2 support in Firefox 3 and our productivity editors in Notes 8 (Open Document Format support), we will be adding support in Eclipse. That work has just kicked off. By implementing it in Eclipse any application built using Eclipse will be able to make use of IAccessible2 and more usable access. This will allow us improve the usability of things like of rich model-based authoring tools for persons with disabilities in our Rational product line. Many vendor products work on Eclipse. IA2 will make the already strong accessibility of Eclipse more usable by persons with disabilities on Windows and once implemented it will be easier to make Eclipse fully accessible on other platforms.

I should point out that there are other vendors planning to support IA2 and I hope they will be making those announcements in the near future.

It is our hope that Microsoft will join the Free Standards Group and participate in IAccessible2. The effort dramatically improves the interoperability problem, between ATVs and application vendors, on Windows which does nothing but help Microsoft. Also, due to IAccessible2's synergy with MSAA, Java, UNIX, and UNO accessibility the uptake should be swift. Microsoft's  experience in the area would be greatly welcomed and they could benefit from future accessibility innovations produced by the FSG. Like IBM, I believe Microsoft would like to move on to other accessibility challenges which have not garnered as much attention today. Here is the opportunity. I am cautiously optimistic.

Project Missouri and IBM's donation of IAccessible2 to the Free Standards Group

New Draft of Accessibility Guidelines for ODF Supporters