I want to thank you all for coming. It is a pleasure to be back in the U.K. and I would like to thank the RNIB for
inviting me to speak to you today. I come to you from the great state of Texas.
I have been living in Texas for roughly 13 years. What I have been told is the United States is divided into two main areas - Texas and, well, everybody else. We also have great spicy food and I was told that well, England
does not and I heard this from a colleague from Sheffield. He mentioned something about national food being “bubble and
He did say, however, that what I really needed to try was "mushy peas." That was not the type of food I would think a country should be bragging about. Well, I am happy to say I did try them and they were quite good. Although you might consider serving hot sauce with it.
Seriously though, all of us do have a lot in common. We work in one of the most challenging fields in the computer
industry – accessibility.
Those working in the accessibility field compare it to the legend from Greek mythology of King Sisyphus, who was
cursed by the gods to repeatedly push a huge boulder up a hill for all
eternity, only to watch it roll down again. As you, no doubt, experienced with
your success, persistence, passion, and determination can lead to tremendous
rewards along the way and make pushing that rock just a bit easier. That is no
different than how we are approaching the rapidly changing Web environment.
My career in accessibility began in 1990 in the halls of the IBM Watson Research Center. At this time industry was
switching from a text-based interface to one that was graphical. Screen reading
technology, at the time, could easily gain access to the text on the screen but
when it was converted to graphics the concern was that it would all come to a
halt. Just imagine the fear that a blind individuals had when faced with the
prospect of losing their jobs, or one of the vehicles for basic communication
with friends and colleagues. In 1991, Joe Lazarro published an article called
“Windows of Vulnerability” in Byte Magazine that described this fear as the
industry moved from DOS to graphical interfaces such as Windows and IBM’s OS/2.
Quietly, I had been working with a team of engineers at IBM to create the first
Screen Reader for graphical user interfaces, which provided blind users with
access to OS/2. By the way, graphical user interfaces are known in the industry
as GUIs. In December 1991, I published an article called “Making the GUI Talk”
in Byte magazine, that showed the community how we made it work. That day the
earth shifted to meet the needs of users with disabilities. I recall my boss,
Jim Thatcher, walking into a government building in Washington to discuss the
loss of access to computers by blind users. When Jim approached the meeting
room, stacks of the magazine containing the article greeted him at the door.
This early innovation was based on capturing what was drawn on the screen,
using reverse engineering to guess what it represents such as a menu item or a
button, and reproducing a textual representation that could be read to a user.
Since this time we have defined new standards that allow desktop application
developers to provide the textual information as well as semantics and
structural information representing the rich desktop interface to assistive
This resulted in a much more reliable and usable experience. The first of these standards were the
Microsoft Active Accessibility in 1995 and the Java Accessibility Application
Programming Interface, a collaboration between IBM and Sun, in 1998. Looking
back, both pieces of work were seminal in that they formed the foundation on
which applications provide the necessary information required by assistive
technologies for over a decade. If implemented properly, an assistive
technology can ask for the information they need rather than guessing.
In 1999, the Worldwide Web Consortium published the first Web Content Accessibility Guidelines, which
became known as WCAG 1.0. At the time WCAG 1.0 was published, the Web consisted
of static documents where the idea of a dynamic page meant reloading a new
one. Also, navigation of a web
page, by a person with a disability was archaic, slow, and tedious requiring constant
tabbing to navigate to get to anything on the page. Even worse, the markup
language used to code Web pages, HTML, was not entirely keyboard accessible.
This was largely because it was expected that the user would spend most of the
time using a mouse for navigation. It was a time where the concept of making something accessible was
limited mostly to adding alternative text and rudimentary semantics found in
HTML; where usability for people with disabilities was an afterthought; and
where you restricted the technologies used by the web site author to meet
compliance. The Web experience, for many, was a step back from what users
experienced on the desktop. Yet, the ability to access such a tremendous amount
of information was so compelling and necessary that these drawbacks had to be
accepted. That is changing. Like in 1990, another paradigm shift is now under
way. It is called Web 2.0.
Today, the Web is moving to a richer desktop-like experience, tied to back-end services driven by the need to
deliver easily consumable information on all platforms. Ajax, which stands for
to a web page without having to reload the page, or fight with browser
manufacturers on how data gets delivered to the page. Ajax has opened up a new generation
of Web applications that has created a Renaissance in the browser. With it,
companies can deliver the same Graphical User Interface experience, found on
desktop computers. Developers can now use HTML, Cascading Style sheets, and
desktop operating systems. This allows developers to use GUI constructs like
menus and notebook tabs to hide information until the user asks to see it.
These Web applications also have brought in a new wave of social collaboration and for the first time users can
connect with friends, old and new, and on an international scale that has been
unprecedented. Yet, this shift has created similar concerns by many people with
disabilities as the most powerful access to information, the Web, may be
slipping away. Web 2.0 application developers are creating new user interface
exist in HTML. And the designers of HTML never provided a mechanism to allow
the author to provide the necessary information to an assistive technology as
to what the new elements are and the state they are in. Furthermore, there was
not even a provision to make them keyboard accessible. For years this problem has been blamed
in fact the WCAG 1.0 guidelines from 1999 effectively prohibited their use.
Roughly four years ago Web 2.0 was in its infancy yet, at IBM, we knew the ability to deliver applications with
ubiquity on the Web would change everything so I was asked to go solve the
made it clear the problem was with HTML. By applying accessibility information
used to enable Windows, Java and Linux and by enhancing the keyboard
accessibility of HTML we had the opportunity for greater accessibility and
usability on the Web than ever before. To make it all real, our strategy
- This new accessibility information to work with
existing HTML and with existing markup and all browser
- open source software, and
- community collaboration by industry leaders, assistive technology, and browser vendors
Today, this new accessibility information is provided in a new specification from the World
Wide Web Consortium called the Web Accessibility Initiative Accessible Rich
Internet Applications or WAI-ARIA. It is changing the way industry thinks about
accessibility. WAI-ARIA is a way for authors to provide semantic “sugar” to a web page to allow a browser to support the
accessibility services provide by an operating system which are used by
assistive technologies. We call this “interoperability.” Prior to WAI-ARIA,
industry’s notion of accessibility was more in line with what you needed in
static HTML documents (headers, alternative text, and structural
elements). With Web 2.0 applications authors create new user interface elements, such as a folder tree and notebook panels, where information is hidden until you are able to use it and the accessibility of the page
changes as you operate it. This semantic “sugar,” or meta data, allows the
author to tell an assistive technology, such as a screen reader, that the
object is a folder tree and whether or not it is expanded. And it uses the
document structure of HTML, and semantics, to tell you where you are in the
folder tree hierarchy. We call this the “user context.” With WAI-ARIA we can
also tell an assistive technology and the web browser the common landmarks on
the page such as the main content, the banner, a search region, or the
Prior to WAI-ARIA, keyboard navigation was limited to the use of form elements and anchors, which were all
in the tab order. Everything else in HTML was not keyboard accessible. Imagine a mobility-impaired user having
to tab through 1000 links on a page to get to the last link. With WAI-ARIA,
keyboard accessibility is similar to that in the desktop environment where the
Tab and Arrow keys can be used together to create a more efficient experience.
All HTML elements can be keyboard accessible without requiring that they be
included in the tab order. This constitutes a paradigm shift to one where you
tab to significant elements on the page, such as a menu, which manage the
information you see, and use the arrow key to navigate within. This is a huge
step forward as now a Web page can have accessibility and usability, normally
found only on the desktop, benefitting all users.
Despite these successes we have some challenges facing us. I would like to highlight three challenges ahead of
us. The first involves Web accessibility compliance. Many countries have
adopted WCAG 1.0, which requires web authors to produce web content that must
effect robbing the user of an accessible and usable solution. But the Worldwide
Web Consortium, or W3C, now has a new Web accessibility standard. WCAG 2.0,
which became a W3C recommendation at the end of last year, removes these
restrictions and focuses on the basic accessibility principles needed to
produce accessible solutions such as being interoperable with an assistive
technology. Consequently, WAI-ARIA is a key component for conformance to WCAG
2.0. Countries need to begin migrating their Web accessibility policies to WCAG 2.0 as soon as possible.
A second challenge will be better tooling designed to test the
accessibility of Web 2.0 applications. Today, our accessibility test tools are
largely geared to:
- WCAG 1.0 restrictions
- Static web content resulting in “snapshot” testing.
- Basic HTML (no “sugar” if needed)
This, as we can all see, is quite a limitation. Rather, tooling must now consider
- Taking a Functional Verification Approach where the tool repeatedly tests the page as the tester exercises the application
- Testing for proper implementation of WAI-ARIA
IBM has taken an open community approach to tooling. Through the Eclipse Foundation, we first provided an Accessibility Tools Framework to this open source tool platform and provided accessibility tool plug-ins for Web and Java applications. Most recently, we have started a new tools effort in the Open Ajax Alliance called the “Accessibility Tools Task Force.” We have pulled together in an open setting, many of the major tools providers including Microsoft, Deque, ParaSoft, Mozilla, Adobe, and educational institutions. Our intent is to deliver a collection of rules and reporting best practices to assist Web application developers in producing accessible solutions. In fact, we expect this work to be integrated not only into test tools but also into development tools used to create Web applications.
The third challenge comes with what is called “the programmable web” and the extensive use of rich graphical content. I believe these come hand in hand. Today the notion of how a Web application is built is changing rapidly. Today companies, and individuals, are creating reusable web application fragments through the use of web services as the new Application Program Interfaces or APIs. These APIs, listed at programmableweb.com, totaled 1,145 at the time I wrote this presentation. Last year at this time there were only 600. Companies, and in fact individuals, mash them up, hence the name “mashup,” into their own application leading to rapid application development. These services are then wired together in your web page. For example, you may choose an address of a customer contact on one side of your page and then an airport location on another side of your page. The address information from both supplies the source and destination of a travel route that is used to configure a graphical map in another. In this case, the source and destination may be provided through a web service that accesses this information in a contact and transportation data store respectively. The combination may then be wired to configure a Google map using their web service. This highlights a number of problems for users:
- The services are created autonomously and the combination may be unusable
- The services may not be accessible for a given set of users
- We don’t know the author and may be unable to get these problems fixed.
- The industry needs to use complex visualizations to represent complex data
- For some users it may not be possible to make these services accessible in their current form
These issues require us to look at accessibility at a much higher level. It requires us to look at the basic fabric of how the Web is constructed. In order to solve this problem we need to step away from the one-size-fits-all approach to accessibility where a single web page must be readily accessible to all users as-is. We must step outside our constraints of thought and think of the Web as one that should be flexible and personalized. To address this we need to look to the learning and educational space where they are dealing with delivering solutions based on inclusive design.
A flexible and personalized web is one where the user specifies how they would like to see the Web delivered to them. Imagine a Web where accessibility becomes a preference rather than a solution and what is accessible depends on what the user deems to be accessible or usable. To do that you would need to also know something about the capabilities of the resources forming your page.
For example, does the video on a page support closed captioning? Does the video support closed captioning in the language I speak? If not, do you have one that does? Great, give me that one!
Is your resource a complex visualization, such as a map? I prefer a text equivalent, such as the textual driving directions. Do you have one? Great! I will take that one and I can give it to my driver too.
Do you support large fonts? Great, please deliver the page in large fonts and in high contrast if you have it.
These concepts are not fantasy. In fact there is a specification called the Access-For-All specification from the IMS Global Learning Consortium and it is used in some new learning systems being developed like those by Angel Learning, Teacher’s Domain, and a project called Fluid led by the University of Toronto. What is not there is a standard way to use these specifications to arbitrate personalized content on the Web. This is now in the early stages. In the World Wide Web Consortium Ubiquitous Web Applications Working group we are in the process of harmonizing a core set of Access For All preferences into standards that define how content is delivered to all devices.
This is a first step toward making your mobile device a truly personalized digital assistant. We must then define standards for how we access the personalized information and tag the accessibility capability of resources, such as a map, to deliver a form that is consumable by the user. When that fabric is in place and is widely adopted companies, like IBM, will be able to deliver a personalized experience to all users.
The Web is, and continues to be, the most important vehicle for delivering information to all users. Its power is rooted in its open pipeline to the masses. Looking forward I encourage all of you to become part of that open community. The ability to contribute to open standards and open source has allowed innovations like WAI-ARIA to move the web ahead at tremendous speed and advance accessibility for all to new heights. I encourage you all to participate and set the course for a Web without barriers.
Working together, pushing that rock up the hill gets a lot easier!
The accessibility industry has noticed some recent IBM accessibility resource adjustments as a result of the economy.
IBM has been doing much of the heavy lifting, both financial and with resources, for the WAI-ARIA work. This includes working with assistive technology vendors, browser manufacturers, and industry. At this point we believe WAI-ARIA is far enough a long that the browser manufacturers can carry that aspect of WAI-ARIA forward. With that statement I would like to give praise to the excellent work done by the Mozilla Foundation on WAI-ARIA and the latest work by browser manufacturers like Microsoft.
We, now, have to invest in applying WAI-ARIA and WCAG 2 to our products and that will require us to focus more inwards. I will continue to chair the WAI-ARIA subcommittee in the WAI PF working group and work with AT vendors to ensure that it works for people with disabilities. The WAI-ARIA specification and best practices guide are very far along and we are working to wrap things up to get to last call. I would like to point to this outstanding podcast by Freedom Scientific.
Similarly, the Linux Foundation has done a stellar job in delivering a new standardized accessibility API in IAccessible2. IBM and industry uses IAccessible2 in products like Lotus Symphony, Acrobat Reader, and Firefox as well as a host of mainstream assistive technologies. Consequently, we consider IAccessible2 an overwhelming success and will step back to let industry move forward with continued adoption. At this point we feel IAccessible2 is at a point where the Linux Foundation can carry the ball. It is in good hands.
Going forward, as a member of the Accessibility Interoperability Alliance steering committee, I will be working to help coordinate efforts with the Linux Foundation to ensure greater interoperability with assistive technologies on multiple operating systems.
WAI-ARIA introduces additional semantics necessary to make Rich Internet Applications fully accessible, and usable, to assistive technologies. It also may add the needed punch to improve the usability of static documents by people with disabilities. We hope to bring WAI-ARIA to last call status in the first quarter of 2009. Already it has huge implementation support and on line education. One of the most important resources now established for WAI-ARIA is CodeTalks. This site is extremely active with code samples, references to educational videos, and online collaboration growing daily. Another critical resource is the Google Group Free ARIA. Many from the W3C WAI WAI-ARIA community and CodeTalks communicate on Free-ARIA.
The lack of appropriate tooling to validate Rich Internet Applications against WCAG 2.0 is a serious problem. To address this gap two efforts are being kicked off. One I am pulling together is the Accessibility Tools Task Force in the Open Ajax Alliance. Here we are developing best practices and rules to aid test and development tools in valdating these types of applications and assisting developers. Participation in the Open Ajax Alliance is free and participants are asked to sign a minimal agreement. Another effort being kicked off is the WA-ARIA Firebug Accessibility Dashboard Project which can be followed on CodeTalks. This effort is being led by IBM and the Mozilla Foundation under Aaron Leventhal and is designed to assist authors using the Firebug IDE to produce accessible Rich Internet Applications.
In 2008 we have seen a dramatic enhancement in the accessibility API support in browsers driven by the need to support WAI-ARIA. Firefox 3 added IAccessible2 support on Windows and ATK support on Linux. Microsoft is in the process of adding UI Automation support to Internet Explorer.
Finally, in 2008 we are starting to see advancements in assistive technologies user interfaces to make Web 2.0 applications more usable. Jaws 10
released on November 3 with a host of user interface enhancement to support WAI-ARIA. Some of these usability enhancements included automatic forms mode switching, WAI-ARIA landmarks, and early support for Ajax live regions.
With WCAG 2.0 out and these advancements I expect 2009 to be a year where we see the usability of the Web to take a dramatic leap in usability by people with disabilities as products start to adopt it.[Read More
IBM posted an insightful video
highlighting the need to address access to the Web by the growing senior population and an IBM solution called the EasyWeb browser. While IBM is very involved in accessibility standards and infrastructure this video shows IBM's efforts to create assistive technology when the need presents itself.
Taking a step back, a feature of the "EasyWeb" solution is its personalization capabilties. The end user is allowed to specify how the web experience is delivered to them without any special assistive technologies. Personalized access is a key component of a long term strategy industry must take to deliver a workable solution for all users. For the growing 65+ senior population, this is a transformational solution allowing them to participate in the "digital generation."
When asked why I work in accessibility - this is why.[Read More]
WAI-ARIA brings Web accessibility on par, or better, than what is available for today's desktops. It provide the Web developer with the tools to deliver fully keyboard accessibility as well as full interoperability between web applications and an assistive technology either through the DOM. If the browser manufacturer chooses, it can make the interaction with the assistive technology even easier by mapping the new found WAI-ARIA meta data in the DOM to the accessibility API supported by the browser. While this will carry us very far with Web accessibility it does not take us all the way.
A number of critical shifts are under way in how we a web applications. Web developers are beginning to make use of complex visualizations and mashup technology to do rapid application development through re-use of existing web services. Many of the services may be inaccessible given that WAI-ARIA is new. Also, making complex visualizaions accessible, like a map or a pie chart, accessible is just a waste of time. Rather, we need to consider the fact that a one-size-fits-all approach to accessibility may not make a lot of sense.
The IMS Global Learning Consortium and ISO SC36 have been working on something called the Access For All standards. These standards define accessibility user preferences and corresponding resource meta data (data which describes the adaptability of a resource such as a web page or video) to meet the users needs. IMS and ISO have been working on new versions of these specifications which allow for better adaptation of today's content and for better adaptation to mobile devices. One of the features of this strategy is the ability to replace a resource with an equivalent alternative to a resource. One example would be to replace the map with an HTML alternative which conveyed the directions for the blind. These specifications have been adopted with limited success in the Learning and Education space. What is really needed is for the broader web to adopt a similar strategy.
I recently attended a Ubiquitous Web Face to Face meeting in Pisa, Italy. Aside from the beautiful scenery we actually managed to kickoff a new piece of work which was to incorporate Access For All personalization into the W3C Delivery Context Ontology (DCO). The DCO provides a model of the characteristics of the environment in which devices interact with the Web or other services. The delivery context includes the characteristics of the device, the software used to access the service and the network providing the connection among others. The W3C has a direct relationship with the OMA which defines standards by which mobile devices request information, such as web pages, from a server so that web content may be delivered in the form best suited for the target environment. The DCO defines the parameters by which a device requests this information. Assuming sign off from ISO and ISO, this effort constitutes the first mainstream effort toward being able to allow a user to specify personalized content irregardless of the device they are using.
Going forward, I encourage readers to watch this blog for other related work underway in the area of personalization.[Read More]
I had not reported on IAccessible2 adoption
recently. I was pleased to see Stephen Partridge's blog posting of Adobe Acrobat investigating support for IAccessible2
. This is sure to improve the accessibility of Adobe Acrobat. This is exciting news given the recent IAccessible2 Request for Comment
. IAccessible2 is an enhancement to the Windows Accessibility API Microsoft Active Accessibility. It bring the Windows platform capability in line with Linux. IAccessible2 is a proven technology with strong implementations in the recently released Firefox 3
and Lotus Symphony
A new, free, open source accessibility test tool is also in development called accprobe. I encourage developers to try it out and provide feedback to the Eclipse ACTF team.
Recently, IBM lost one of its accessibility heroes - Cynthia Ice
. It has taken me a very long time to formulate the words that would come close to conveying the impact Cynthia Ice has had on IBM and the type of person she was to me.
Working in the accessibility field is extremely difficult. It requires very specialized skills - including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up. Furthermore, the quality of access must be even higher when you have such high end-user impact products as Lotus.
Cynthia has worked tirelessly to deliver Lotus products that are accessible and usable to our customers and employees. She has been a beacon of leadership in an area few are willing to venture. We owe Cynthia our deepest thanks and prayers.
Cynthia, Thank you for all you have done. You have made the world a better place.[Read More]
I have been adding to a new wiki which is cataloging ARIA growth. I think people will be amazed by whose adopting it. Check out "Who Supports ARIA?
"" on the Mozilla web site.
It is nice to see more players like Adobe join in.[Read More]
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. Yahoo and the Paciello Group gave a presentation on their WAI-ARIA implementation in Yahoo Mail and highlighted some of the challenges retrofitting an existing rich internet application. Also, developers are having problems with Window-Eyes and JAWS as they don't automatically switch in and out of application mode. Also, if you turn off browse mode in Window-Eyes a minor refresh can cause it to fall back into browse mode. I discovered Microsoft has a minor problem with the IE 8 beta where you have to turn on WAI-ARIA support in the registry. This is a beta so I suspect this will be corrected in subsequent drops.
- Mashup Session: My mashup session was full with some people standing. Unfortunately, CSUN instituted something new this week which required you to sign up ahead of time and many people were turned away. Many attendees commented that the need for personalization will be very important going forward to address this problem. For most, the mashup problem is new. Here is the mashup presentation.
- Fluid Session: Again, this was a full session. People are very interested in Fluid in that it has created a social network for collaboration of UX designers, accessibility engineers, and application developers. Matt King and I will be discussing how we might use some of its principles into usable access. A number of attendees stated that they wanted to join and participate in Fluid.
- Dojo Session: Becky Gibson's session was very well attended, especially given session given the lateness in the day on Friday. A lot of questions were generated.
- Browsers: In the mind of end users, Firefox was "top dog" at this conference with respect to their accessibility efforts. That said, application developers are looking to IE fully supporting of WAI-ARIA. Microsoft received a lot of well deserved, positive press for their announcement to support WAI-ARIA in IE. There was no word on Safari from Apple on WAI-ARIA support at the conference.
The IAccessible2 panel was packed! All major screen readers were implementing IAccessible2 support: NVDA, JAWS, SuperNova, and Window-Eyes. Additionally AccProbe and Freedom Scientific's Magic support it as well. There were a lot of great comments from the panel. Adobe would like us to address extensibility and assistive technology vendors and developers on how to implement support for IAccessible2. Also, Adobe had asked that there be performance enhancements for AT handling of large documents.
There was a strong emphasis by ATVs, like Freedom Scientific, that the fact that they were involved with the development of IAccessible2 that is something that they know will work. Representatives from GW Micro and Freedom Scientific stated that IAccessible2 is only one tool in their arsenal to provide access. Probably, most
Virtual World Accessibility and a look at 3D Internet
IBM gave a wonderful presentation on their research efforts to make virtual worlds, like Second Life, accessible to blind. They are creating an accessible Web 2.0 navigation panel, using Dojo, to Second Life and they discussed a number of tools they are using to make the environment accessible: leveraging social collaboration to add semantic tagging, assistive avatars, and a "virtual" cane to reach out and find objects to move to. ... Another packed session.[Read More]
I was elated to find that Microsoft has added support for WAI-ARIA
in Internet Explorer 8
. Although I am sure support is not complete, this is a statement of commitment by Microsoft and it gives the effort support by over 90 percent of the Web browsers. IBM is already incorporating support for WAI-ARIA
in toolkits, like Dojo, which is being consumed by many IBM products to deliver a usable, accessible experience to people with disabilities for Web 2.0 applications.
The next question we need to ask is what ATVs support this level of WAI-ARIA implementation in IE 8. If we are going to start playing with this we need an assistive technology (AT). Hopefully, either Microsoft or AT vendors will divulge this information for developers soon.
I want to personally thank Microsoft for making this step forward.[Read More]
Some of you may have seen the announcement announcement about the Accessibility Tools Framework (ACTF) donation
. 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]
At long last we finally got the ODF 1.l Accessibility Guidelines
out for public review
. These are the first accessibility guidelines for office application developers.
These guidelines are intended for office application developers but they are also good reference material for people new to accessibility. The guidelines introduce the developer to a broad range of disabilities and the corresponding needs that must be addressed. Readers will see that there is a strong emphasis in supporting interoperability with assistive technologies. Full interoperability, is often overlooked when addressing accessibility. The ODF Accessibility Subcommittee focused on interoperability in ODF 1.1 and, as a result, you will see how this document directs office application developers to address the interoperability features in ODF 1.1. You will also notice a strong emphasis in preserving document structure when supporting assistive technologies. Structural semantics is critical to accessibility as access to structural information provides context to the user. Readers will also find a section on preserving accessibility information during the file conversion process.
Given the fact that ODF is totally open and lacks platform dependencies, it is important that ODF office application developers use these guidelines to preserve accessibility on each of the targeted operating system platforms even if accessibility is new to those platforms.
We look forward to your review.[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?
- We and the Mozilla Foundation provided assistance to ATVs to do the work
- A solid design with a gradual migration path to the new API. - Think why DOS users migrated to Windows over OS/2
- Regular architecture meetings with ATVs held separately with a strong focus in protecting their intellectual property
- Open standards
- Support by key, significant in terms of size, significant with respect to the needs of the consumer, open source products.
- Community building
- No hidden agendas
- Open source projects which generate business for the accessibility community (consultants, ISVs, ATvs, etc.)
- Corporate leadership
- No IP barriers to entry
- Support by major accessibility advocate groups
- Open Collaboration
- Interplay between standards and implementation - ODF standards, IA2 standards, AT implementation, app implementation - all done in parallel (an open coummunity effort)
Lack of these things is why it has taken other accessibility API efforts so long to take off or stumble. I also believe the availability of open source tooling will help dramatically. We modified the MSAA inspect tool internally to test Symphony support for IAccessible2 but then we had to throw the code away because MSAA inspect tool licensing prohibited our releasing derivative works. This set us back a good 6 to 7 months to create a new open source tool we will be releasing in the next quarter.
Since I have taken over accessibility strategy for IBM software I have pushed for one that is open and barrier free. In 5 years I doubt people will remember that IBM started all this (open accessibility on Windows) but I do hope we have a more barrier free, interoperable, accessible environment for which people with disabilities don't have to wait years to access. A look back at early accessibility API work on Windows showed it took years for adoption of that work by ISVs and ATs. IAccessible2 has been able to achieve stellar results in a very short period of time.
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
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 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:
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 :
States and Properties:
- Features which reduce the code needed to add ARIA accessibility support: owns, activedescendent
- AJAX live region support: live, atomic, relevant
- Improved support for trees: level, posinset, setsize
- A datatype specifications for values
- A flowto mechanism to allow logical navigation of flow beyond DOM structure
- Ability to detect sorting mechanism such as in a grid column: sort
- The log role to support web chat sessions
- Enhancements to the RDF role taxonomy to accomodate AJAX
The live region support is clearly the most important. Live regions are portions of your page which may be dynamically updated, using AJAX techniques, without requiring a page reload. We now have a way to tell an assistive technology whether a region of the web page is live as well as how (atomic, relevant) and when (live) to handle the updates to that region. Through the use of the controls property an assistive technology may detect how one object controls another such as a live region. For example, a region may control an entirely different portlet.
These updates constitutes critical semantics that have been needed for web and desktop applications for some time.
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.
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:
- Allow developers and assistive technologies to leverage their investment in Microsoft Active Accessibility (MSAA)
- Complement MSAA to allow Open Document Format (ODF) supporting office applications and other rich office applications to support a rich usable experience for persons with disabilities
- Remove the need to reverse engineer information needed for accessibility on Windows (screen scraping and other techniques which result in unreliable access)
- Dramatically reduce the porting effort to enable industry applications on other platforms
- Support our W3C ARIA efforts
- Make it an open standard
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.
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.
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.