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!
I have been asked a number of times about XForms and accessibility. During the course of the blog I will highlight the accessibility features of XForms.
is a delarative markup. The engineers who designed XForms took the standard use cases for how we create forms and built in support for the standard actions performed in a web form. From an accessibility perspective, this means these functions should be available from the browser independent of platform. So, rather than guess what an onclick does on a form, the user should be able to access the available functions and Notification events that are used in that specific form as defined by the XForms standard.
- next and previous
- focus change
- help and hint
You are also notified of events which actually occur during form operation. These types of events allow applications, like a screen reader, to provide alternative modalities such as speech.
- Value change
- Select and Deselect
- Scroll First, Scroll Last
- Insert, Delete
- Valid, Invalid
- ReadOnly, ReadWrite
- Required, Optional
- in-range, out-of-range
XForms 1.0 support is being added to Mozilla
. Exposing access to this information will greatly improve the access of Web-based forms.
A part of the problem is that semantics are limited to the tag elements names. For example, a table when read to a screen reader must always be a table. In some instances it may be used for layout.
To address Dynamic HTML accessibility, we have a roadmap in place in the W3C to fix the problem. The intent is to allow the author a way to provide accessibility information into a web page to support the Accessibility API on the platform. I will be presenting information on this effort at the annual CSUN "Technology and Persons with Disabilities" March 14-19, 2005 for those who are interested.
Her is a link to the discussion overview: http://www.csun.edu/cod/conf/2005/proceedings/2524.htm
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]
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]
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 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 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 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.
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.
I recently spoke at the annual NFB Convention, in Dallas, with Becky Gibson. Here is a summary of the meeting:
Rob Sinclair, the Microsoft Accessibility Director, gave a great presentation on Vista and the upcoming accessibility features. Vista is Microsoft’s first step toward adapting content to meet the needs of the individual. Rob showed a talking login as well as the Window-Eyes screen reader reading parts of the desktop. Rob stated he wanted to raise the bar in the accessibility space. Due to the audience, Rob did not show off their speech recognition technology which will be bundled with Vista. I saw this at CSUN and was quite impressed. The downside is the new Vista functionality, much which is not accessibility related, comes at a price.
Later in the meeting Joe Steinkamp, from the Texas Department of Assistive and Rehabilitative Services spoke on the resources required to run Vista which will be prohibitive for many individual consumers and businesses. Vista takes 2 gb of RAM and a 128mb graphics card. For those running screen magnifiers, 256mb RAM is required. Also, it appears that a dual core processor is required. So, unless your company is forcing you to go to Vista or you buy a machine bundled with it, I don’t see many in the blind community being an early adopter.
Rob plugged the new Vista Accessibility API, called UI Automation. UI Automation is a dramatic change from MSAA in that it is very focused on behaviors and automated testing. The behavior piece is a certainly good fit for automated testing. The challenge, as I see it, is the dramatic change from how other accessibility APIs work on legacy Windows, the Mac, Linux, and Java. When the user encounters a new UI widget they should be able to tell whether it is clickable, scrollable, togglable, and so on. This is good, however I am concerned over the lack of information that would indicate how the object would relate to other objects the user is familiar with - unlike what we are doing for Dynamic Web Accessibility in the W3C. Time will tell. At this point the major AT vendors do not support UI Automation. Rob recognized the need for a client API that did not run in managed code and that the work to do that had begun to address this. AT vendors do not want to rewrite as managed applications. It remains to be seen if this will be addressed in the Vista timeframe.
Becky Gibson and I gave a presentation entitled “Firefox and AJAX IBM’s efforts on accessible Open Computing.” In the talk we discussed why and how Firefox came to be accessible and support Rich Internet Applications. The talk was designed to convey how this open source accessibility project has advanced the accessibility and usability of the Web and the resulting accessibility ecosystem that resulted from this work. The Mozilla foundation, who at one time was not focused on accessibility now has one of the biggest supporters and in fact has instituted an accessibility grants program that has spawned such projects as Mac enablement and XForms accessibility support for Firefox. Additionally, Firefox is being enabled for Linux. This is a collaboration between Sun, IBM, and the Mozilla foundation.
Becky gave a demonstration of DHTML and AJAX accessibility and discussed her work on the Dojo open source accessibility project which she is leading for IBM. I finished up with a discussion of our work on Linux accessibility and the open source accessibility ecosystem growing around our Linux Screen Reader and full screen magnifier projects. The point being, open source accessibility projects are attracting developers worldwide to contribute and accelerate new solutions.
Finally, Joe Lazzaro, the lead for the state of Massachusetts Information Technology Division Department of Accessibility spoke on the move to the Open Document Format. Joe stated that the department will be following U.S. Public Law 508 accessibility guidelines. My take-aways from Joe’s speech is that the legislation has decided to hold the role out of ODF until it is accessible. The fight to make that decision was akin to the threatened Microsoft boycott led by Charlie Crawford back in 1995.
Joe said the group was evaluating two interim MS Office plug-in utilities to import/export ODF documents. They were from the Open Document Foundation and Sun Microsystems. Other than recent discussions around ODF I had not seen Joe in years. I was pleased to see the ITD group pick Joe to lead this effort.
Accessible open computing took another positive leap forward to accelerate the accessibility of Rich Internet Applications with IBM's announcement to contribute AJAX Software Development Technology to Dojo. So, you might ask, why are we doing this?
Three of the biggest failings of accessibility efforts in recent years are:
- Failure to implement and validate your infrastructure
- Failure to ensure a workable, usable solution that interoperates with assistive technologies
- Failure to provide reusable, accessible component libraries to reduce the enablement work of developers
The intent of this work is to address all of these issues. This effort will allow the W3C WAI Protocols and Formats working group to have an interoperable test suite to validate its standards efforts. Firefox 1.5 and the sample web componentry provided on the Mozilla web site is a start. There is also test suite work going on at the University of Illinois. This library is targeted at robust industry reuse. As we progress with the standards effort, we can ensure that our specifications are well grounded in workable, interoperable solutions. This will facilitate moving the new specifications to recommendation.
I just returned from a face to face meeting of the Oasis Open Document Format Accessibility Subcommittee held at the RNIB Employment and Learning Center in Edinburgh, Scotland where we completed our accessibility report to the Oasis ODF Technical Committee. The public report highlights our requirements to fill accessibility gaps in the ODF 1.0 specification. A summary of our effort and the report can be found on Peter Korn’s blog.
What is significant about the effort is:
The group has agreed to continue the work to raise the accessibility bar for office solutions through ODF. Many of the group members are also members of the Free Standards Group Accessibility Workgroup. In this group we will be investigating new open standard accessibility API extensions that will enhance the open document experience.
It was completed in only 5 months
It only produced 9 enhancements to the specification
Of the enhancements, the group went beyond basic compliance to address the usable access of office solutions
We were able to include a diverse set of users and technical experts addressing a broader range of issues
IBM is and has been involved with a number of open standards and open source accessibility efforts. Like with Firefox, the ODF accessibility work effort shows that through industry collaboration we can address accessibility issues faster and at the same produce innovative accessibility solutions. This effort is indicative of an IBM initiative highlighted in an article called Partner or Parish which illustrates IBMs effort to address tough industry problems through partnerships.
In the last month, IBM and Sun have come together on their efforts to make Firefox accessible on Linux. Solid communication between Sun and IBM facilitates the separate teams working as one large extended team with a agreed upon schedule. The following are the team makeups:
- Aaron Leventhal, Firefox accessibility lead (Arlington, MA)
- Ming Gao, developer (Beijing, China)
- Eirikur Hallgrimsson, developer (Nashua, NH)
- Dan Kinnunen, tester (Austin, TX)
- Wayne Deangelo, tester (Austin, TX)
- Mark Pilgrim, Firefox UI accessibility (Raleigh, NC)
- Ginn Chen, Firefox ATK, Sun lead (Beijing)
- Evan Yan, developer (Beijing)
- Neo Liu, developer, (Beijing)
- Tim Miao, developer (Beijing)
Mozilla is also kicking in resources to address cross-platform issues such as keyboard navigation in and out of plugins as well as investigating cross-platform accessibility support which incudes Mac OS X and ATK.
- Mats Palmgren, developer (Sweden)
- Håkan Waara, developer (Sweden)
In additon, the Mozilla foundation is providing mini-grants (up to $10K) to developers for Mozilla accessibility projects. This list is not meant to be restrictive. If you are interested in putting together a proposal, you may contact Aaron Leventhal. Proposals are under consideration for completing the Accessible XUL Authoring Guidelines and creating automated checking tools for them.
What is important is this is a team effort between IBM, Sun, and Mozilla. The companies are setting aside corporate barriers to accelerate accessibility of an open source browser and operating system. This speaks volumes about the benefits of open source development.
I wanted to take a minute and point people to Frank's blog regarding Mozilla's presence at CSUN
. This is an indication of the accessibility ecosystem building around an open source project. Frank's enthusiasm is contagious.
I was pleased to see IBM's contribution, as part of the open source community, foster a new grassroots effort around accessibility and the Firefox browser. Students are getting involved with accessibility in college by simply being able to contribute to the open source effort. The result is innovation through being "open."
Like any good open source project, IBM is no longer the only contributor. Others can share the load while increasing the innovation by a lot of very energetic people.
I remember the first time I was able to make Screen Reader/2 speak the GUI and see people with disabilities be able to use it for gainful employment. The experience is adictive.
I want to thank Frank, Aaron Leventhal, and the Mozilla Foundation for pulling this energetic team together at CSUN.
I just completed a very hectic week at the California State University, Northridge Center on Disabilities' 21st Annual International Technology and Persons with Disabilities Conference
. For those not in the accessibility community this is the largest technical conference on accessibility in the United States.
The major theme at the conference seemed to be around the use of open standards and open source to advance accessible computing for persons with disabilities. Firefox
, recently endorsed by the National Federation of the Blind
, was probably the hottest topic at CSUN. Firefox sessions were overflowing and the Mozilla Foundation
had their own booth at the conference. Handouts at the Firefox booth evaporated withiin the first couple of days. What was most interesting is the accessibility ecosystem building around Firefox. Aside from the IBM announcement of its accessibility contribution to Firefox last year
, a plethora of young talent was showing their Firerfox extensions. One such person, Charles Chen, is working on Fire Vox, a self-voicing browser
The clear message being that through open source accessibility can be advanced without waiting for proprietary solutions.
An Open Document Format
Panel, led by Sun Micrososystems
, was held on Thursday which included myself, Peter Korn, Sun's Accessibility Architect; Janina Sajka, principal of Capital Accessibility and chair of the Free Standards Group
Accessibility Working Group; Myra Berloff, Director of the Massachusetts Office on Disability; Accessibility Architect & Strategist at IBM; Malte Timmermann, Technical Architect for OpenOffice.org
. TV Worldwide
and their AT 508 channel
videotaped thes ODF Panel Session
. The discussion covered:
- the definitions of open standards and open source
- Who uses ODF
- Who is working on its accessibility and the timeline
- Accessibility of ODF
- The history and future of ODF in the State of Mass.
Audience participation was excellent with a lot of very inciteful questions. What was clearly conveyed was that the events surrounding Massachussetts and ODF have been a positive transformation for both the commonwealth and the industry. Through a rapidly emerging open standard we are having very visible transformation around the awareness of the need for accessibility and the opportunity to "raise the bar" on accessibility through an open standard.
Becky Gibson led a presentation on AJAX
accessibility which made use of the Dynamic Web Accessibility
standards work in progress at the W3C. It showed how IBM's leadership helped is helping to drive new opens standards which will drive not only the accessibility of applications like AJAX but also improve the overall accessibility and usability of the web. While IBM initiated the work early adopters showed other early adopters, like Victor Tsaran at Yahoo
, who is developing new web componentry that will improve the overall usable access to the Yahoo site. Like the Firefox session, lead by Aaron Leventhal and Glen Gordon (Freedom Scientific
), the Yahoo
DHTML session was overflowing. Linux
accessibility was gaining momentum as well. Both Sun and IBM demonstrated early versions of their screen readers (Orca
on Linux. George Kraft (IBM) demonstrated IBM's pre-alpha open source screen magnifier
, called gScope. Myself and George Kraft gave a presentation on the IBM Linux Accessibility Project which covered how IBM was contributing code to the open source community to fill gaps in the Gnome Accessibility Project
; API extensions to the Free Standards Group; and enablement to Firefox. Sun continues to lead the Gnome Accessibility Project effort and IBM is joining the effort to accelerate its readiness for end user adoption.This would not be possible without open standards and open source contributions.
While the theme of "open" stole the show I was very pleased at some of the advancements on Windows Vista
. It appeared that many of the key AT vendors were running on Vista. Screen Reader access to Vista used, primarily, a combination of MSAA
and screen scraping to read the desktop. What was most impressive about Vista was its voice recognition support. It was the best demonstration I have ever seen on Windows
of voice recogniation navigation and dictation. Although this is a demo, if it is good as they showed, my hat is off to Microsoft
for doing a superb job of helping users with mobility impairments through quality voice recognition.[Read More
The HTML working group has been working on building accessibility into XHTML 2 from the ground up. Of these, there are two cross-cutting technologies
which will improve the accessibility of a number of existing W3C standards efforts through the use of modularization:
- Role attribute and Meta modules
- Access key replacement called the access element
The Role attribute is now being used to assist in the enablement of Dynamic Web Applications. The W3C WAI Protocols and Formats working group
is developing a new role taxonomy
to be used as common roles designed to support platform accessibility APIs across the Windows
Today's HTML access key is designed to be an attribute on an HTML element whereby the author specifies a key on a keyboard to either give the element focus or to activate the element. Access key has the following serious deficiencies:
- Not every device has a keyboard.
- The author has to figure out what keyboard mapping to use so that his/her selection does not overlap one consumed by the target browser or operating system
- There is no descrliption as to the purpose of the access key
The access element in XHTML 2 is like "semantic sugar" around XML events in that it provides a higher level semantic binding layer that is in-fact deterministic. It has the following advantages and features:
- Assigns navigatio by role or by a target id whereby the target id takes precendence
- Where there is more than one role matching the access element, focus tracking would sequence through each element having the same role in a circular fashion following document order
- By default, an access element sends a focus event to the target element
- The author may assign a tittle attribute which acts as a description of the access element
- The author may choose a particular event handler to be triggered such as an activate by making declarative reference to use of events
- The author may optionally provide a key binding suggestion for which it is up to the user agent and end user to accept or override
I hope to see these move into the XHTML 1.X namespace so that we can incorporate these features in today's markup without using a separate namespace. They are also applicable to other markup like SVG and thus solve a number of problems facing today's web content.
Today, IBM released a full screen magnifier to IBM's emerging technology alphaWorks site called gScope
. gScope is the first full screen magnifier solution on Linux to use of the new composite extension
to X. Composite allows for redirecting of drawing commands to an off-screen buffer and then uses a compositing manager to decide how the windows will be arranged on the screen. While this facility can be used to create things like translucent windows it also may be used to allow for fast magnification.
Screen magnifiers on Windows have used drivers to redirect drawing calls into free memory on the card and then perform direct transfers to the screen using memory transfers on the card. This makes screen magnification fast. gScope uses composite to capture drawing calls redirected the desktop to create a managed off-screen buffer of it. gScope then works with the composite manage to copy the end result to the desktop in a magnification operation using the video hardware.
Before composite, magnification was peformed using system memory and the results provided were slower. The new magnifier will allow for magnification levels from 2 to 16. It can operate in full-sceen, line, lens, or docked window modes. In the spirit of open source this will come with source code and documentation. While this is an alpha release it is robust enough to allow distros to pick up the work. Strategically, the best place for this is in the Window manager as there can only be one composite manager running at a time. By providing an open source solution, KDE
and other UNIX desktop providers may get magnification for low vision users sooner rather than later. This fills a critical gap in an accessible Linux desktop offering.[Read More
Open Document Accessibility subteam had its first meeting today. Technical Accessibility leads from industry and accessibility advocacy were present. Sun and IBM brought along leads from accessibility architecture, strategy, and research.
The first deliverables from the group will be to perform an ODF accessibility gap analysis of competing document solutions and produce use cases to improve the usable access to documents. We will use this analysis to take industry beyond the level of accessibility experienced today.
I have had opportunities to work with most of the members on various standards efforts and research projects such as for Java accessibility
, W3C WAI
efforts, and middleware transcoding for seniors - but never together as one team.
I expect a home run to be hit by this group. Together, with our assistive technology vendor relationships, we will make a difference and raise the bar. Having ODF as an open standard will result in the broadest industry impact.[Read More
The most visible accessibility battle since the threatened boycott of Microsoft products is now center stage in the state of Massachusetts. It is center stage because the state of Massachusetts wants to move to an Open Document Format (ODF)
for which accessibility has not yet been fully addressed. To prevent its adoption those who supply a claimed compliant accessible office suite are pushing to have it overturned. While accessibility issues exist with this new format and its deployment it is important to note that these problems can be fixed. I can, in fact, remember when the proprietary office formats the state currently uses were not accessible at all. With effort, the accessibility story will improve. So, the real questions that need to be asked are:
- Can an accessible solution be provided?
- If so, can the time needed to do this be warranted?
- Can an accessible solution be provided in the interim?
- Can work in this space produce more accessible solutions?
- Can the cost of an accessible solution targeted at open standards and open source solutions benefit the user?
On November 5th I attended an ODF summit sponsored by IBM and Sun at the IBM Learning center in Armonk. The event was clearly about history, preserving state sovereignty, and putting a roadmap together for an accessible solution. My presence here helps to answer these questions.
1. The answer to this is of course yes. IBM is in fact doing that now for Workplace.
2. To answer this question it is important to understand the motivation behind Peter Quinn's move to take the state from proprietary to open formats and from proprietary to open source. In other words how did the state get to where they are today. This was captured in his "Open Format Freedom Fighters Forum" keynote. The state has a $24.4B dollar budget: 90,000 employees and contractors, with an annual IT spend of $700M. In 2003 it's challenges were massive legacy applications, limited maintenance, lots of heterogeneity, few sustainable processes, and the need to preserve history in a format that is accessible by all. This created a "perfect storm" analogy that seldom comes around.
The state's path to open standards and open source is an effort to bring some "common sense" to the commonwealth where they can build solutions that everyone else can have. The CIO office wanted to share code across state boundaries but the lawyers prevented it. They also wanted to preserve history in their documents. Much of the states documents are in proprietary document formats. Newer proprietary formats are not always backward compatible. Over time the loss of state history becomes a serious concern. Peter gave the open standards analogy of a toilet for which I will try to summarize:
Today you buy a toilet and no matter how many features it has you may install it in your house without a lot of worry. The reason is that all houses have a standard drain pipe, standard wax seal, and standard water hook ups. Now if you follow the "Gates model" you go out and buy the new Microsoft toilet that requires a special sized drain pipe when you build your home. Twenty years later the toilet breaks and you need to go buy a new one. You find one you like and you bring it home for installation and discover that the new toilet does not fit the drain. You find that in order to install it you need to buy the special "Balmer adapter." This assumes someone is still selling the adapter. The state's concern is best captured in a recent David Berlind article
. Simon Phipps (Sun) summarized it in one of his witty one-liners: "ODF is about avoiding corporate Alzheimer's."
The concerns of the state go far beyond saving money on licensing costs for proprietary solutions. Preserving history and bringing sanity to the state are more than valid reasons for the state's moving toward an open document format. To do this, the state should take the time to produce an accessible solution. It was clear that Peter Quinn wanted to make that happen.
3. An interim solution can be defined; in fact they have an accessible solution now. The state should execute on a parallel track to work with industry to build an accessible solution.
4. There is definitely an opportunity to build a more accessible solution. The existing office products are considered accessible because assistive technology vendors support them. However, just because a company claims they have accessibility support does not always mean they have a usable solution. At IBM the accessibility and usability of PowerPoint documents is a real problem. We have an opportunity for the industry to build more accessible document formats and think solidly about how they can be delivered interoperably with assistive technologies to improve their usability. We have an opportunity to garner user involvement up front and use that to impact the design of the accessibility support. We can also do this on more than one operating system. Members of OASIS
at the meeting agreed to form a subcommittee to address the accessibility of ODF.
5. Today blind users of IT will go out and purchase a screen reader. The cost of that screen reader can run up to $1400. Some assistive technologies are customizable and others are not. If solutions were open source it gives an opportunity for users and industry to enhances the assistive technology solution without waiting for the latest update. Furthermore, users would not be required to purchase such solutions. The use of open standards for interoperability allows for commonality of the infrastructure. This is a real problem on Windows where platform evolution has resulted in a plethora of proprietary APIs
, used for accessibility, and is arguably one of the reasons for the high prices of Windows assistive technologies. Comprehensive open standards for accessibility, like those being developed for Gnome, reduce the cost of ensuring an interoperable solution as ell as the time to market for an assistive technology. When I worked on Screen Reader/2 it took us 3-4 years to build a screen reader. At this time, no comprehensive accessibility API existed. When we developed the Self Voicing Kit for Java it took us 6 months to build a working solution and with a greater level of accessibility. This was because we had developed a single, engineered, accessibility API.
Despite the obvious benefits for moving to open formats, Peter has an uphill battle. The senate oversight committee wants to remove control of how IT is specified away from the state's IT department. Peter Quinn had 3 bullets to describe this in his pitch:
- creates total gridloc
- defies logic
This debate most assuredly will rage on. Meanwhile, members at the ODF Summit are forging plans to meet the state's ITD accessibility goals. Some of these members include IBM and Sun with extensive accessibility skills and resources.
Like many in the industry I have been reviewing and helping to define what accessibility features appear in UI Automation (UIA)
. UIA addresses a number of gaps in Microsoft Active Accessibility (MSAA)
At a high level some of these gaps are:
- access to text
- access to tables
- role and state implementation restrictions due to integer sizes
- some reduction in enablement by the author
- use for automated testing
Microsoft's challenge will be to move people to it. Today, accessible Windows applications are based on the use of a plethora of API and reverse engineering mechanisms. These consist of: MSAA; Proprietary COM access to an applications Document Object Model (MS Office, Corel, IE, etc.); the Java Access Bridge; graphics engine hooking to access to text, carets, and selected information, and more.
In the near term Microsoft is working to map MSAA to a single UIA API layer but due to problems with MSAA's specification implementations may vary and the end result will be that this will be unrealistic. At the moment access to UIA by an assistive technology is through managed code. This requires AT vendors to rewrite from scratch or integrate a managed extension to their assistive technology. Access to legacy applications by an assistive technology will result in a performance hit. ATs will have to communicate from a managed application across boundaries to legacy applications resulting in slower access. A positive step forward would be for Microsoft to release an unmanaged client API version for assistive technologies. Like any mature company Microsoft will be forced to support their legacy infrastructure or risk breaking the accessibility of existing applications. In short, this will be a long process.
While a significant step forward for Microsoft, there are some rather significant gaps in UIA that need to be addressed:
- Performance: The performance problem will be a real barrier to implementation on large documents where large amounts of information must be cached and processed by screen readers. To address this for Linux, IBM is working with the Free Standards Group to extend the accessibility API to support large documents defined as the collection interfaces. These interfaces run in the ATK bridging layer without additional work by the application developer.
- Device Independence: Support for multiple actions for device independence. These are provided in the Java Accessibility API as far back as 1998 and are now in the Linux GAP architecture.
- Support for relationships: This also was provided in Java and now in GAP. These are essential for diagrams, flow charts, groupings, etc.
One of the things that would have given UIA more traction would have been to get UIA into the open source community to get more backing as a cross-platform accessibility API where we would focus on a Linux implementation. I had originally suggested this to their director earlier this year and he expressed interest resulting in this public commitment
. Unfortunately, industry has yet to see a license agreement to review after months of waiting and we were forced to move on to alternatives.[Read More
Well, I just got back from SCUBA diving in Fiji where my wife and I went diving on the Fiji Agressor II. Here is the captain's log
. The vis. was great at 125 feet. We had a great shark dive at Nagali Pass where I saw the biggest green moray. Initially I thought the reef moved but it turned out to be a moray with a diameter of about 18 inches and 8-10 feet long. It felt like flashbacks of The Deep
On Tuesday this week I was interviewed on the the Computer America Talk Show and spoke on DHTML accessibility. For those that are interested here is the link:
Craig Crossman was a great host.
IBM's AlphaWorks site recently launced an accessibility topic
to host technologies that aid in the production of accessible solutions and which themeselves are assistive. AlphaWorks is a great venue for this effort as developer's can take these for a trial run, provide feedback to the developer or researcher, and in some instance decide to license the technology. I used alphaWorks when we wanted user feedback on the Self Voicing Kit for Java. Often, researchers develop technologies in a vaccum due to a broad range of obstacles. AlphaWorks is a way to get over the hurdles.
A number of technologies are currently posted on the site. I will discuss three:
aDesigner: This is a disability simulator for people with vision impairments. What I like about aDesigner is it is the only tool I am aware of which can simulate some visual disorder such as the effects of aging on the cornea and how it distorts visions for our aging population. It also simulates issues with color blindness which are difficult to perceive for those that are not impaired.
KeyboardOptimizer: Operating systems have a number keyboard accessibility options to help users with motor disabilities to type more easily and accurately. They depend on the user configuring these settings manually. There are also numerous settings that may need configuring to address your needs. Your needs may also change over time. This technology adapts to the individual as they type. It monitors how you interact with your computer and adjusts the keyboard response to meet your needs. This technology, developed by Shari Trewin
and is an accumulation of years of research.
Web Adaptation Technology: This is a project led by Vicki Hanson
is a technology that adapts web content for Seniors. This project originally sarted as a Web transcoding server research project for which I was a technical lead, in 2001, called the Web Accessibility Gateway
. Today this is an add-on to Internet Explorer. We have a number of IBM customers using this and it is has a number of adaptions for seniors including: magnification, TTS of selected text, smart page linearization, varying color schemes, and the KeyboardOptimizer.
Should these technologies appear in IBM products or would you like to use them yourselves? You decide. I encourage developers to provide feedback to these researchers.[Read More
Well, accessibility awareness has hit the mainstream. The November 3, 2005 IBM Systems Journal
is dedicated to accessibility.
As an author I just received my early copy. The article I co-authored covered accessibility requirements for users with vision impairments
. Section 10, "Lessons learned - Microsoft Windows Today" covers the evolution of accessibility on Windows. Windows accessibility has evolved over time and it provides an excellent example of what can happen when a comprehensive accessibility architecture and strategy are not employed up front. Today, producing accessible solutions can be a very expensive proposition on Windows due to interoperability problems.
I look forward to reading the article entitled Semantic triage for increased Web accessibility
since we are using semantic web concepts to address the accessibility of Dynamic HTML.[Read More
Today, IBM announced one of its accessibility contributions to the open source community
to be realized in the release of Firefox 1.5
Let start with Internet banking. Banks need to support a broad range of customers, including seniors, blind, low vision, and mobility impaired users. All of these customers have difficulty using a mouse. Web authors can now create the keyboard functionality, look and feel, and accessibility of the GUI. Users, accustomed to the keyboard navigation of a GUI will appreciate this for two reasons.
- GUIs hide information until you need it (menus, scrollable spreadsheets, expandable, collapsible trees
- User can tab to significant areas of their document, including GUI like widgets and then use the arrow keys to navigate within the widget (spreadsheet, menu) rather than being forced to tab to every active and visible element, that could be hidden by these widgets, or worse being forced to access alternative content reducing the user productivity.
Another business opportunity is education. Imagine a college, who has to get their students registered for classes, manage their scholarships and loans, view the school calendar, or possibly manage their own dynamic calendar. My own daughter will be attending college for the first time this year and I am keenly aware of the opportunities for this technology. Students want to use Windows, the Mac, and Linux to access the same information. Site administrators have to address all of these issues and having to support a fat operating system GUI for all these operating systems that is accessible just is not in the cards. Like a GUI, RIAs can hide much of the information until it is needed without having to navigate through pages of static content. For users who are blind this is a huge productivity gain. Also, these UI can be spoken with rich information, as in a GUI. For example, a blind user can hear their screen reader announce they are on a menu and it as a popup. A user who is blind may also hear verbose contextual information such as: you are on a notebook tab x 1 of 2.This is clearly a paradigm shift.
As the article states, this is part of an ongoing effort in the W3C
which IBM is leading to make RIAs accessible. Like all W3C recommendations this will need to have industry implementation. Firefox is the driving factor in making this a reality. Furthermore, IBM is working with AT vendors to support the technology. Currently, GW Micro
and Freedom Scientific
have versions of their screen readers in private beta using Firefox and users are raving about it. With these efforts around Firefox in place, developers can now start to develop accessible RIAs today rather than wait.
Going forward, Firefox is uniquely positioned to deliver the business opportunities of RIAs. It runs on multiple operating systems. Authors can enable their web content once and render it Firefox on multiple operating systems. Going forward, Firefox is being geared to support the accessibility infrastructures on both Linux and Windows.
The accessibility standards targeted at supporting RIAs may be rendered on Internet Explorer as well as Firefox and in fact make use of the keyboard support and the ability to drive magnification like Firefox. Unfortunately, Internet Explorer currently does not support this new emerging standard with screen readers. Businesses and federal agencies evaluating their browser strategy should take another look at Firefox 1.5 when it's released with the benefits of RIAs in mind.
See the HTML Accessibility Preview
for more information on the Firefox accessibility effort on RIAs.[Read More
alpha. We were able to achieve the usability and accessibility of Windows desktop applications:
- keyboard access just like their GUI counterparts
- contextual information in line with their GUI counterparts. (Number of tabs in notebook announced. Tree depth of a focused tree element, etc.)
- Role and state information announced as you would find in a GUI
We showed this to technical leads at Yahoo and AOL and the opportunity for creating accessible, Rich Internet Applications and delivering desktop solutions on par with a rich desktop applicaions was apparent.
Completion of this project will accelerate the standards effort. As we speak a cross-cutting, self describing role taxonomy and accessibility property specficationa are getting close to working draft based on proven implementations. Industry involvement to the standards effort is now growing with the addition of Adobe. The work being developed is cross-cutting in that it has applicability to:
In the current Deer Park Alpha
of Firefox, XUL makes use of the same accessibility extensions for XHTML to enable some of the custom GUI widgets found in the chrome.
Another side-benefit of this work is the creation of a new role called "presentation." The use of the presentation role tells the browser that there should be no accessibility API support for a particular document element. This can be applied to table elements to indicate that the content is only presentational and for assistive technologies not to process the table elements as a table. This eliminates the need for authors to use a special style sheet to reproduce table formatting. DHTML often uses tables to produce the visible formatting needed for rich GUI-like elements. Indicating to the user agent and assistive technology that an element is only presentational removes the burden of guessing when to treat markup as presentational vs markup containing significant semantics which might impact the user experience.[Read More
Due to a large investment by IBM and the Mozilla community. Firefox is becoming as assessible as IE on Windows. The latest GW Micro private beta for Window-Eyes has support for Firefox, including support for the up-and-coming W3C accessibility effort to support scripted web content.
To find out more about Firefox accessibility check out the Accessible DHTML Preview
. Aaron Leventhal
is leading the Firefox enablement effort in Mozilla comunity.
Window-Eyes screen reader beta testers have indicated that they have faster access to the Web than IE.[Read More
Some readers may have been following the progress of the accessibility of Linux desktops. The two main desktops being targeted for accessibility in the industry are Gnome and KDE. Both desktops use on the accessibility architecture defined by the Gnome Accessibility Project
. The architecture builds off work IBM did with Sun on the Java Accessibility API back in 1998.
There are a number of, what we call, "gaps" in the total GAP solution. These are in the areas of assistive technologies and accessibility infrastructure performance. To date, the main screen reader on the platform, Gnopernicus
, and the provided magnification solutions are not what users come to expect on a Windows system. Gnopernicus, is not scriptable which allows developers and end users to customize the audio interface. Magnification, today, is also limited to a window rather than full screen.
A shining star on the platform is the Gnome Onscreen Keyboard
which benefits from GAP. GAP provides the list of named actions on accessible objects as well as a list of all named hypertext links in applications. The breadth of support on the Windows platform is lacking in these areas.
A more pressing issue which effects the quality of screen reader support is the provision for solid, performant document access for large applications. The problem areas are Open Office and Firefox. The accessibility architecture on GAP attempts to restrict people from gaining access to document structure. The existing API depends on numerous cross process calls to get access to information in large documents resulting in inadequate performance. Also, the use of the GAP ATK API
is inadequately documented making it difficult for application developers and assistive technologies, new to the platform, to discover how to enable their products or write new assistive technologies. The performance of Open Office accessibility is also impaired by using the Java Access Bridge to implemant an accessibility API bridge between Open Office and the ATSPI
. ATSPI is the CORBA-based communication layer through which assistive technologies acquire the accessibility information from the GAP architecture.
To address these issues, IBM has recently become active in the open source accessibility effort through its work in the Free Standards Group. IBM is in the process of proposing API extensions to ATK
and the ATSPI
to improve performance and improve access to large documents. Also, while being dormant on the screen reader front since Screen Reader/2 and the Self Voicing Kit for Java, IBM is developing plans for an open source Linux screen reader.
Also, last year IBM released Via Voice TTS for Linux through Wizzard Software
. It is available in Simplified Chinese, German, Spanish, Finnish, French, Italian, Japanese, Mexican Spanish, Brazillian Portuguese, Traditional Chinese, US English and UK English. We felt releasing Via Voice was essential for Linux due to its high quality at high speeds and the breadth of languages it supports.[Read More
DHTML Accessibility Accessibility is rapidly becoming a reality. A Technology Preview
may now be seen on the Mozilla site. The demonstrations should be viewed with the latest nightly build of Firefox. These examples will work with the latest version of the Window-Eyes beta.
CSUN has posted the HTML version of our CSUN pitch
. Which describes the technologies and implementation techniques. This presentation introduces the developer to the taxonomies being created which describe GUI componentry for DHTML accessibility. The taxonomies and their corresponding schemas will provide the framework for creating custom components and providing a mechanism for self-description. The plan will be to use these taxonomies to drive browser adaptation to support native platform accessibility APIs and tool validation in the future.
What is most exciting about this work is a fundamental paradigm shift whereby web pages can behave like a GUI while being fully accessible. The user agent can then map the meta data provided to the accessibility api on each platform without additional heavy lifting on the developer's behalf.
IBM is driving this effort through the W3C Web Accessibility Initiative with the plan that this be an open standard for all to use. Firefox is the leading implementation mechanism for this standard.[Read More
Last week I attended CSUN's 20th Annual International Conference "Technology and Persons with Disabilities."
The demonstration was rendered in a nightly build of Firefox while being spoken by the Window-Eyes screen reader
, from GW Micro and while being magnified by the Windows Magnifier.
When entering the menu, Window-Eyes announced "menu activated." It was able to read each of the menu items as well as the state of those that were disabled.
Spread sheet navigation announced changing row and column header inforamtion as well as whether the user were on a row header, column header, or spreadsheet cell. When an enter key was performed on a cell, Window-Eyes would announce the column header followed by the editable cell and its contents. It would echo text being entered. When cell editing was complete it announced the new contents.
The Window magnifer followed user focus as the spreadsheet cells and menu items were navigated.
This paradigm shift showed that it is now possible to deliver the kind of usability and accessibility that we can expect from an accessible GUI today in a web page. This allows for the delivery of accessible dynamic applications on multiple operating systems without the weight of a GUI.
The industry response was fantastic. We have seen interest from SAP, Google, AOL, Sun and others. Roundtable discussions included the construction of reusable open source DHTML widgets which could be incorporated into tooling for reuse by the industry.
It shows what you can do through open standards and industry cooperation.[Read More
In addition to device independent events, XForms also provides another powerful feature by its model-view-controller design. XForms separates content from presentation while embedding relevant meta data in user interface constructs.
XForms provides the following meta data: label
for the user interface controlhint
help text for the user interface controlhelp
help text for the user interface control
XForms also encourages intent-based authoring by introducing these constructs:group
to group a set of user interface controlsswitch
, and case
which can be used to hide or reveal logical groups of controlscase
includes a Boolean attribute called selected
that allows the group of controls within that case to become active. This is important to assistive technologies, such as a screen reader, which would monitor the document to determine when to speak selected elements. If none of the cases within the switch are selected, the first case in document order becomes active by default. How those elements are rendered visually is of no consequence. The semantics are preserved.
For an in-depth look at XForms a great book to read is:
XForms: XML Powered XForms by TV Raman
A reader commenting on my blog asked if I would mind blogging some time on the definition of accessibility and the scope of problems that are being addressed in the industry?
At the most basic level, accessibility is about people being able to access and use a product or solution. A primary focus of accessibility is access by people with disabilities. The larger scope of accessibility includes benefits to people who do not have a declared disability or for those who dont. I would like to first address the near-term work being done in the accessibility space.
Tremendous effort is being put into operating system and desktop solutions to accommodate users with disabilities. The biggest change, which began in the mid to late 90s has been a move toward engineered APIs that allow Assistive Technologies (ATs like screen readers) to access desktop application. Additionally we are seeing a move toward integrating these ATs into operating systems. For example, the Mac desktop, the Gnome desktop, and Windows are moving to incorporate more ATs. Furthermore, the move toward engineered APIs is improving access for what I would call declarative disabilities those where people declare they have a disability. Some of the considerations for bundling solutions are: security, lack of an AT solution provider, and the opportunity to have integrated solutions with which to test the accessibility of applications and accessibility infrastructure.
The second wave, which began only in the past five years, is a move to support persons with non-declared disabilities. The biggest focus in this space has been the senior population for which IBM has been a significant contributor. As we get older we begin to experience varying degrees of disabilities. This may include, but is not limited to, varying degrees of mobility impairment, site degradation, hearing loss, and cognitive impairments. This population often does not wish to admit they have a disability or may not in fact believe one exists. Therefore, their disability is not declared. I worked on a large middleware research transcoding project for seniors
which was designed to take any web page and transform it to meet specific access solutions such as magnification, increased white space between text and lines, linearized content to reduce horizontal scrolling, speech, magnification, varying color schemes to compensate for reading impairments, and other transformations. This was a precursor to an IBM service offering called the Web Adaptation Technology
. This technology goes well beyond enablement and enters the realm of solutions which are tailored to the end user for ease of use. This leads into the next wave which is just now starting to take hold.
Accessibility continutes to move into the mainstream. We are using accessibility technology to help with mainstream solutions that are not just for persons with disabilities. Meta data we are incorporating into web content to address DHTML accessibility is being considered for building knowledge into the web content transformation process. For example, web content which incorporates role meta data (what the object in a web page is such as a calendar or spreadsheet and its corresponding properties) can be used to adapt content to different devices phones, pdas, etc.
In the next few years I can imagine legislation going beyond enablement, like IBM, and focusing on ease-of-use. Enabling applications for accessibility does not necessarily make them usable.
We also need to focus on the broader population in the areas of learning disabilities. Not everyone uses the same process for learning. Our systems need to adapt to these different needs. When we can do this we should see a dramatic increase in user productivity.
While I have not addressed all accessibility issues, I hope this addresses this persons request.