Accessibility Strategy and Architecture
schwer 120000D6E4 Tags:  secondlife iaccessible2 fluid csun wai-aria aria 1 Comment 2,649 Visits
The net of the 2008 CSUN Conference for me was that all of our hard work on Web 2.0 and IAccessible2 has resulted in widespread and growing adoption across the board. WAI-ARIA was being implemented everywhere but many of the implementations have yet to be fully fleshed out. Our next step will be to help ATs revamp their UIs to better help developers and end users. As a result, I believe a more accessible and usable web and desktop experience will be had by all.
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. 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 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.[Read More]
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
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.[Read More]
schwer 120000D6E4 Tags:  ajax odf fsg accessibility aria firefox windows iaccessible2 msaa 1 Comment 3,083 Visits
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.
schwer 120000D6E4 Tags:  accessibility eclipse tools actf web2.0 aria msaa iaccessible2 3,034 Visits
Some of you may have seen the announcement announcement about the Accessibility Tools Framework (ACTF) donation to Eclipse. As many of you know, IBM promotes an open accessibility strategy in an effort to reduce the time that new technologies become accessible. In the past we have done this by initiating and leading: the Accessibility for Rich Internet Applications (WAI-ARIA); donating code to Firefox to support WAI-ARIA; creating IAccessible2 and donating it to the Free Standards Group, now the Linux Foundation; and contributing to Linux accessibility.
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![Read More]
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.
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.
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 perspectiveIt 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:
Here are a few of the many launched in China:
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.
schwer 120000D6E4 Tags:  msaa firefox uia accessibility aria windows fsg iaccessible2 odf gnome 3,313 Visits
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]