Accessibility Strategy and Architecture
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.
IAccessible2 is in or being implemented in these products today:
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:
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.
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?
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.
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.
schwer 120000D6E4 Tags:  msaa firefox uia accessibility aria windows fsg iaccessible2 odf gnome 3,479 Views
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.[Read More]
schwer 120000D6E4 Tags:  ajax odf fsg accessibility aria firefox windows iaccessible2 msaa 1 Comment 3,291 Views
IBM and the Free Standards Group (FSG), today, announced IBM's donation of IAccessible2 to the Free Standards Group. IAccessible2 is a new accessibility API, developed in the project codenamed Missouri. In developing IAccessible2 we had a number of goals in mind:
Project Missouri constitutes one of the largest, and perhaps the largest, accessibility efforts in the history of our company. It was named Missouri as the State of Massachusetts laid down the gauntlet in front of IBM to "show me" an accessible solution for ODF in 2007. It's creation constituted a multi-continent design and development effort between IBM Productivity Editor developers in Beijing, accessibility engineers in Austin, and assistive technology vendors in Florida, Georgia, Indiana, and Wisconsin. The accessibility engineers from IBM's Software Group Emerging Technologies Accessibility Architecture and Development team are industry accessibility leaders in the areas of ARIA, Firefox, Linux, and Java with some working on accessibility for 20 years. Project Missouri is a true testament to IBM's commitment to accessibility as is the donation of IAccessible2 to the Free Standards Group.
The FSGs acceptance to make it an open standard will speed up the process to make future industry innovations accessible. At the Free Standards Group Accessibility meeting yesterday two large enterprise companies joined the IAccessible2 standards effort - Oracle and SAP. All companies who innovate and who are committed to accessibility desire a vehicle to make those innovations accessible. The Free Standards Group Accessibility group now develops accessibility API standards for both Windows and UNIX. When a new technology is developed participating members have a vehicle, if needed, to extend the existing standards to meet their needs and with help from accessibility efforts from across the globe.
IAccessible2 includes support for rich Tables, editable text, documents, relationships (critical for AJAX, model-based authoring tools, etc.), extensible roles (key for ARIA), hyperlinks, selection, multiple descriptive actions (critical for mobility impairment and onscreen keyboards). Going forward we will be contributing developer guidelines, and open source tooling to aid developers.
Most importantly, IAccessible2 will have support by assistive technology vendors which removes a critical barrier to adoption.
In summary, IAccessible2 is a key ingredient in the convergence of rich Web and desktop applications. It supports usable access for people with disabilities on Windows, while reducing developers' efforts to support accessibility on other operating systems. With a rich open accessibility ecosystem in place with the FSG for accessibility API development we should now be able to move on to broader usability issues rather than fighting interoperability problems with assistive technologies in the native platform.
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.[Read More]
I recently spoke at the annual NFB Convention, in
Rob Sinclair, the Microsoft Accessibility Director, gave a great presentation on
Later in the meeting Joe Steinkamp, from the Texas Department of Assistive and Rehabilitative Services spoke on the resources required to run
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
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
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.[Read More]
In the last month, IBM and Sun have come together on their efforts to make Firefox accessible on Linux. Solid communication between Sun and IBM facilitates the separate teams working as one large extended team with a agreed upon schedule. The following are the team makeups:
Mozilla is also kicking in resources to address cross-platform issues such as keyboard navigation in and out of plugins as well as investigating cross-platform accessibility support which incudes Mac OS X and ATK.
In additon, the Mozilla foundation is providing mini-grants (up to $10K) to developers for Mozilla accessibility projects. This list is not meant to be restrictive. If you are interested in putting together a proposal, you may contact Aaron Leventhal. Proposals are under consideration for completing the Accessible XUL Authoring Guidelines and creating automated checking tools for them.
What is important is this is a team effort between IBM, Sun, and Mozilla. The companies are setting aside corporate barriers to accelerate accessibility of an open source browser and operating system. This speaks volumes about the benefits of open source development.[Read More]