I received an email the other day from a very respected leader in a major accessibility advocacy group. He wanted to know, after their endorsement in 2006, whether IAccessible2 has gone anywhere. Also, there has been a lot of discussion on TEITAC with respect to how we get AT vendors engaged. So, I thought I would respond publicly for those companies I can talk about.

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.

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

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.

Recently, IBM announced its participation in the Open Office development effort. One of the benefits to the Open Office community is that they will be able to benefit from our accessibility implementation in the Notes 8 Productivity Editors. In the Notes 8 Productivity editors we implemented a new open accessibility API called IAccessible2. IAccessible2 was contributed to the Free Standards Group, now the Linux Foundation, in 2006. IBM is a big supporter of open accessibility standards and we are pleased to see Open Office benefit from the work.

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.”

As you can tell from my blog I have been deeply involved with the ODF accessibility effort at OASIS and IBM. There have been a number of questions asked me about the accessibility of OOXML. This is no small request given that the documents are over 6000 pages long. That said, the University of Toronto Adaptive Technology Resource Centre recently published a white paper called Accessibility Issues with Office Open XML. ATRC has been asked to review accessibility around OOXML in the ISO standardization review process in Canada. I recently had the pleasure of attending one of the calls as an invited expert.

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.[Read More]

Over the last few months, we have been working with customers on their open client initiatives, and have come to better understand their requirements in this space. It is clear to us that enterprise focus is on applications that leverage cross-platform capabilities such as Mozilla, AJAX, and Eclipse, rather than on native applications for Linux. We have been working in the W3C on ARIA as well as working with the Eclipse community on all aspects of the client from open standards to implementations. Our approach has always been one of shared contribution and investment with the open communities that we participate in. Our decision to focus our accessibility efforts above the Linux operating system itself should in no way be construed as lack of support for Linux as a client operating system or accessibility as an important characteristic. We have full faith that our efforts, combined with those of the broader Linux community and the projects that support it, will continue to strengthen the arsenal of accessible solutions based on open client infrastructure.[Read More]

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

WCAG 2.0 focuses on a principle based approach for all Web delivered content and applications and on core interoperability between assistive technologies and applications. It also removes the absolute restrictions on the use of non-HTML technologies. Instead, WCAG 2.0 offers some criteria for selecting technologies that are accessibility supported and can therefore be relied upon to be supported and enabled in the user's browser and assistive technologies. This approach should enable WCAG 2.0 to be a lasting Web accessibility standard and avoid becoming outdated in the near future. It is inevitable that new Web technologies will continue to be developed. Once they contain sufficient features to allow conformance with WCAG 2.0 and are supported by assistive technologies, then they are considered accessibility supported Web technologies and can be relied upon on WCAG 2.0 conforming websites.

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

It has been said that WCAG 2.0 is more complicated than 1.0. There have been some improvements in the language since the last draft that should make it easier to understand. My strong belief, however, is that WCAG 1.0 is less complicated only because it addresses one simple scenario - static HTML websites. Given that it was the first specification of its type, this is understandable for a 1.0 version. We really needed a 2.0 version a couple of years ago as the Internet has changed significantly since 1999. It's not just about static HTML websites anymore. Fortunately, it looks like the wait is almost over. The WCAG working group should be commended on a fine job bringing this effort to its current state. Developing a set of accessibility guidelines that are testable and address a broad range of Web technologies is very challenging and is changing the way people think about accessibility.[Read More]

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:

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.

Application vendors and toolkit providers are already jumping on board. Trolltech was one of the first as seen by their reference on the Qt blog. So, who uses Qt? ... Google Earth and Skype for starters. It would be nice to be able to improve access for mobility impaired uses for both products. Google Earth would be a great use of IAccessible2's IAccessibleAction interface.

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 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.

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.

The Open Document Accessibility (ODF) Subcommittee is developing a new document called Accessibility Guidelines for Implementations of Open Document Format (ODF) v1.1. This is currently out in draft form for review. To date the only guidelines like this have been developed for web user agents. We felt it necessary to to assist office application writers in now to fully utilize the accessibility features of ODF 1.1. The OASIS Technical Committee for ODF is currently taking the ODF 1.1 specification toward a fully recommended OASIS standard. IBM, Sun (Open/Star Office), and the RNIB (DAISY conversion) have signed up to support the standard. Through open standards contributions industry has been able to rapidly raise the bar on the accessibility of office applications. The new accessibility features of ODF 1.1 will make a more usable document format for people with disabilities.

I encourage review comments to be taken back to the ODF Accessibility Subcommittee.

I recently had the great opportunity of presenting the IBM software accessibility strategy at the annual China Accessibility Information Forum in Beijing this November. The event was co-hosted by the Information Industry of PRC(MII), China Disabled Persons' Federation (CDPF), China Foundation for Disabled Persons (CFPD), and Internet Society of China (ISC), and cosponsored by IBM. This annual event is the most important event in China focusing on IT accessibility. This annual event, for which IBM has been a key cosponsor for the past 3 years, is the most important event in China focusing on IT accessibiliity.

The forum's theme was to "Promote Innovative Science and Technology, Establish an Accessible Information Environment." More than 300 attendees discussed the status of accessibility standards and regulations in China, as well as accessibility trends in technology innovation and business transformation.

My impression is that China is going through a major transformation on how they address accessibility. In the last 3 years, accessibility has gone from back to center stage. China is moving very rapidly, however their initial focus is one of eduacation. In the United States, the EU, and many other countries there are services and infrastructure for persons with disabilities (PWDs). In particular, our school systems have already made the transition to provide special education for PWDs. To me, it was apparent that China put this as a top priority and services organization and special education is stepping up to meet the challenge. Also, accessibility legislation is beginning to develop.

IBM, over the past 2 years, has been educating China on the improtance of accessibility legislation harmonization and it appears to be gaining traction. Recent indications are that China is looking to adopt the W3C Web Content Accessibility Guidelines (WCAG) 2.0 which has applicability beyond your basic web content. China realizes it can learn from our successes and mistakes and are eager to work with us, in industry, to accelerate their accessibility efforts. A webcast, in Chinese, of an interview with Frances West, the IBM Human Ability and Accessibility Center director is availablee at http://webcast.china.com.cn/webcast/created/973/44_1_0101_desc.htm and a live web cast of the 2-day forum is available at http://www.china.com.cn/tech/zhuanti/3wzalt/node_7005320.htm.

With the growth of accessibility comes business opportunity for assistive technology vendors. Chris Park (GW Micro), Jim Halliday (HumanWare), as well as Caroline Van Howe and David Dikter (ATIA) were present at the conference,

I applaud China's accessibility efforts and at the rate with which they are moving forward I expect to see great progress at next years forum. In our own way, IBM is helping develop accessibility competency in China at our own China Software Development Lab where enablement of our Productivity Editors (office applications supporting the Open Document Format) is being performed.

I was pleased to see the W3C announced the first working drafts of the roadmap and specifications addressing the accessibility of Rich Internet Applications. This was work I had initiated over 2 years ago in the W3C and it is nice to see that accessibility through open standards works. Although I initiated, and helped lead this, the end result is certainly a team effort by the W3C.

What is important about this announcement is that it also address the accessibility and usability of the Web by persons with disabilities by closing the usability gap between the web and rich graphical user interfaces much the same way that the new Web Content Accessibility Guidelines are meant to address the accessibility of all types of content which may be delivered over the Web.

As the article states, this work provides the tools the author needs to make these types of applications accessible and usable. This, in fact, addresses accessibility reform on the Web by allowing the author to add semantics to the web page to facilitate platform accessibility infrastructure support of your web application by the browser. It will also allow us to consider new web accessibiltiy test tools that are capable of handling both GUI and Web-based applications.

The accessibility of Web applications which use JavaScript have been been a cause for concern over the years. In actual fact, these specifications provide the author with the tools to make web applications, which use JavaScript, more usable by persons with disabilities than with much of the static content that is currently available. It does this by managing the amount of content that could be displayed by storing it in GUI-like widgets on the page. Also, the newly introduced semantics could lead to the facilitation of web content adaptation for small devices - leading to new mainstream advantages.

What is clear is the W3C has made leading a quantum leap into area that brings the usability of the web experience, for all users, in line with rich GUI applications without the overhead of supporting multiple operating systems.

Recently, Aaron Leventhal wrote a tremendous article called "Firefox: an open source accessibility success story." I strongly encourage readers to take a look at the story as it gives you some insight as to how a lot of passion and a little support from a large corporation can help transform an industry with open source.

A few years ago, David Boloker convinced me to leave IBM research to join IBM's Emerging Technology team in Software Group and establish ground breaking accessibility infrastructures to enable these new technologies to be adopted. To do this, I needed crack, passionate, accessibility veterans like Aaron to make this happen in order to allow these technologies to be used by people with a broad range of disabilities. Before bringing in Aaron, our goal was to make accessible rich internet applications a reality. This was well before AJAX added the excitement to "Web 2.0" applications. In order to address the accessibility of these applications I needed a strategy that encompassed browsers, open standards, documentation, industry awareness, component reuse, assistive technologies, and tooling. Going the IE route was not going to happen. Microsoft was focused more on XAML than web-related activities and they appeared to be investing little in IE at the time. The obvious choice was Mozilla and open source which would also leverage IBM's browser team. Mozilla also offered cross-platform opportunities.

I had known Aaron since his days at Raised Dot Computing and of his passionate work on Mozilla. Aaron was working at AOL at the time who had recently worked out a deal to adopt IE as their browser which left the Mozilla accessibility work unfinished. Aaron also owned the accessibility modules for the Mozilla foundation. After a period of time I was able to get Aaron on board.

Aaron's first task was to establish a Mozilla browser as an accessible alternative to IE on Windows and weave the rich Internet application accessibility support, I had initiated in the W3C, to prove the standards worked. What Aaron needed was assistive technology support and we were able to establish that through work with GW Micro and then later with Freedom Scientific. I can't count the number of hours that Aaron put in but it reminded me of the days IBM developers worked on OS/2 around the clock. In October 2005 IBM announced Firefox as an accessible browser which supported rich internet applications. This hit when the excitement about Firefox was huge and what happened next is largely due to AAron's passion for accessibility and the IBM announcement.

Aaron managed to gather NFB support for Firefox as an accessible browser. Aaron worked with Frank Hecker at the Mozilla Foundation to establish an accessibility grant program. Aaron also helped establish the first VPAT for a browser which clearly stated its compliance to U.S. Federal regulations. IE's compliance is buried in the compliance of the Windows desktop and other browsers just don't state compliance. The article states numerous open source projects around the Firefox browser created by this grants program. As a result of this work, Firefox is clearly being established as the most accessible browser. It has shown how open source development can be used to solve the most critical accessibility problems. It has also allowed IBM to consider many more open source initiatives in the accessibility space such as we are doing on Linux.

I recently spoke at the annual NFB Convention, in Dallas, with Becky Gibson. Here is a summary of the meeting:

Rob Sinclair, the Microsoft Accessibility Director, gave a great presentation on Vista and the upcoming accessibility features. Vista is Microsoft’s first step toward adapting content to meet the needs of the individual. Rob showed a talking login as well as the Window-Eyes screen reader reading parts of the desktop. Rob stated he wanted to raise the bar in the accessibility space. Due to the audience, Rob did not show off their speech recognition technology which will be bundled with Vista. I saw this at CSUN and was quite impressed. The downside is the new Vista functionality, much which is not accessibility related, comes at a price.

Later in the meeting Joe Steinkamp, from the Texas Department of Assistive and Rehabilitative Services spoke on the resources required to run Vista which will be prohibitive for many individual consumers and businesses. Vista takes 2 gb of RAM and a 128mb graphics card. For those running screen magnifiers, 256mb RAM is required. Also, it appears that a dual core processor is required. So, unless your company is forcing you to go to Vista or you buy a machine bundled with it, I don’t see many in the blind community being an early adopter.

Rob plugged the new Vista Accessibility API, called UI Automation. UI Automation is a dramatic change from MSAA in that it is very focused on behaviors and automated testing. The behavior piece is a certainly good fit for automated testing. The challenge, as I see it, is the dramatic change from how other accessibility APIs work on legacy Windows, the Mac, Linux, and Java. When the user encounters a new UI widget they should be able to tell whether it is clickable, scrollable, togglable, and so on. This is good, however I am concerned over the lack of information that would indicate how the object would relate to other objects the user is familiar with - unlike what we are doing for Dynamic Web Accessibility in the W3C. Time will tell. At this point the major AT vendors do not support UI Automation. Rob recognized the need for a client API that did not run in managed code and that the work to do that had begun to address this. AT vendors do not want to rewrite as managed applications. It remains to be seen if this will be addressed in the Vista timeframe.

Becky Gibson and I gave a presentation entitled “Firefox and AJAX IBM’s efforts on accessible Open Computing.” In the talk we discussed why and how Firefox came to be accessible and support Rich Internet Applications. The talk was designed to convey how this open source accessibility project has advanced the accessibility and usability of the Web and the resulting accessibility ecosystem that resulted from this work. The Mozilla foundation, who at one time was not focused on accessibility now has one of the biggest supporters and in fact has instituted an accessibility grants program that has spawned such projects as Mac enablement and XForms accessibility support for Firefox. Additionally, Firefox is being enabled for Linux. This is a collaboration between Sun, IBM, and the Mozilla foundation.

Becky gave a demonstration of DHTML and AJAX accessibility and discussed her work on the Dojo open source accessibility project which she is leading for IBM. I finished up with a discussion of our work on Linux accessibility and the open source accessibility ecosystem growing around our Linux Screen Reader and full screen magnifier projects. The point being, open source accessibility projects are attracting developers worldwide to contribute and accelerate new solutions.

Finally, Joe Lazzaro, the lead for the state of Massachusetts Information Technology Division Department of Accessibility spoke on the move to the Open Document Format. Joe stated that the department will be following U.S. Public Law 508 accessibility guidelines. My take-aways from Joe’s speech is that the legislation has decided to hold the role out of ODF until it is accessible. The fight to make that decision was akin to the threatened Microsoft boycott led by Charlie Crawford back in 1995.

Joe said the group was evaluating two interim MS Office plug-in utilities to import/export ODF documents. They were from the Open Document Foundation and Sun Microsystems. Other than recent discussions around ODF I had not seen Joe in years. I was pleased to see the ITD group pick Joe to lead this effort.

Accessible open computing took another positive leap forward to accelerate the accessibility of Rich Internet Applications with IBM's announcement to contribute AJAX Software Development Technology to Dojo. So, you might ask, why are we doing this?

Three of the biggest failings of accessibility efforts in recent years are:

Failure to implement and validate your infrastructure

Failure to ensure a workable, usable solution that interoperates with assistive technologies

Failure to provide reusable, accessible component libraries to reduce the enablement work of developers

Of the enhancements, the group went beyond basic compliance to address the usable access of office solutions

We were able to include a diverse set of users and technical experts addressing a broader range of issues

The group has agreed to continue the work to raise the accessibility bar for office solutions through ODF. Many of the group members are also members of the Free Standards Group Accessibility Workgroup. In this group we will be investigating new open standard accessibility API extensions that will enhance the open document experience.

IBM is and has been involved with a number of open standards and open source accessibility efforts. Like with Firefox, the ODF accessibility work effort shows that through industry collaboration we can address accessibility issues faster and at the same produce innovative accessibility solutions. This effort is indicative of an IBM initiative highlighted in an article called Partner or Parish which illustrates IBMs effort to address tough industry problems through partnerships.