Rich is a Distinguished Engineer in the IBM Emerging Technologies Group responsible for accessibility strategy and architecture for Software Group. Rich chairs the IBM Accessibility Architecture Review Board (AARB) and is an IBM Master Inventor. Rich has broad responsibilities spanning all business units withn IBM and is a working member in W3C WAI and HTML working groups as well as the OASIS ODF Accessibility sub team. Rich led Java accessibility development at IBM including the IBM/Sun accessibility collaboration. Rich is leading the DHTML accessibility effort in the W3C and runs an architecture team within IBM responsible for accessibility for the Web, Eclipse, UNIX, Windows, and Java platforms.

Personalized Access - the next step beyond WAI-ARIA

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.


Jul 27 2008, 11:15:58 PM EDT Permalink

IAccessible2 support being tried out for Acrobat Reader

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.


Jun 24 2008, 09:44:07 AM EDT Permalink

Cynthia Ice Remembered

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.

Categories : [   Ice  |  Lotus  |  accessibility  ]

Jun 02 2008, 02:26:00 PM EDT Permalink

WAI-ARIA Growth Cataloged

It is nice to see more players like Adobe join in.

Categories : [   ARIA  |  Firefox  |  W3C  |  WAI  ]

Mar 28 2008, 02:03:43 PM EDT Permalink

CSUN 2008: IBM's Long Term Accessibility Efforts Paying Off

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.

IAccessible2

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.

Categories : [   ARIA  |  CSUN  |  Fluid  |  IAccessible2  |  SecondLife  |  WAI-ARIA  ]

Mar 20 2008, 12:47:08 PM EDT Permalink

Microsoft announces support for WAI-ARIA in IE 8 beta

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.


Mar 05 2008, 06:30:01 PM EST Permalink

IBM Contributes new Accessibility Tools Framework to Eclipse

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!

Categories : [   ACTF  |  ARIA  |  IAccessible2  |  MSAA  |  Tools  |  Web2.0  |  accessibility  |  eclipse  ]

Dec 05 2007, 06:43:15 PM EST Permalink

Review: Open Document Format v1.1 Accessibility Guidelines Version 1.0

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.

Categories : [   ODF  |  OOXML  |  accessibility  |  documents  ]

Oct 30 2007, 05:43:04 PM EDT Permalink

IAccessible2 Growth - What have you done for me lately?

IAccessible2 is in or being implemented in these products today:

• Notes 8 Symphony Office Suite (today)
• Firefox 3 (being added as we speak)
• Open Office (IBM is just beginning the contribution effort)

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:

• JAWS
• Window-Eyes

It is being added to the NVDA screen reader. ZoomText has added support for a lot of IAccessible2. We, and the Open Accessibility IAccessible2 working group continue to work with other AT vendors. Open Office and Firefox are a big driver for ATVs. These are high impact consumer products to which developers can have access to the source and see how it is implemented.

New Tooling:

We are creating a new accessibility test tool that will be open source. It will be part of a new open source accessibility tools framework we are initiating. This tool will support Java, IAccessible2, MSAA, and Web 2.0 ARIA-enabled applications running in Firefox. It was designed with input directly from companies like Freedom Scientific. So, it will work with screen reader vendors products, and is designed to assist vision impaired as well non-vision impaired users. For example, a screen reader requirement was to process events in-process with applications to give the same response the AT would expect to receive from the application.

So, why is IAccessible2 so successful?

• We and the Mozilla Foundation provided assistance to ATVs to do the work
• A solid design with a gradual migration path to the new API. - Think why DOS users migrated to Windows over OS/2
• Regular architecture meetings with ATVs held separately with a strong focus in protecting their intellectual property
• Open standards
• Support by key, significant in terms of size, significant with respect to the needs of the consumer, open source products.
• Community building
• No hidden agendas
• Open source projects which generate business for the accessibility community (consultants, ISVs, ATvs, etc.)
• 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.

Categories : [   ARIA  |  Firefox  |  IAccessible2  |  MSAA  |  OpenOffice  |  Windows  ]

Sep 27 2007, 12:57:00 PM EDT Permalink

IBM's Accessibility Contribution to OpenOffice.org

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

Categories : [   Accessibility  |  IAccessible2  |  MSAA  |  ODF  ]

Sep 12 2007, 06:28:56 PM EDT Permalink

ATRC OOXML Accessibility Assessment

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.

Categories : [   ODF  |  OOXML  |  accessibility  ]

Jul 25 2007, 09:19:21 PM EDT Permalink

Change in Accessibility Focus on Linux

W3C WAI releases a new WCAG 2 Working Draft

Yesterday, the W3C announced publication of an updated working draft of the Web Content Accessibility Guidelines (WCAG) 2.0. Although not yet a recommendation, the need for WCAG 2.0 is long overdue. WCAG 1.0, which became a W3C Recommendation in 1999, is the standard by which many governments and individuals assess the accessibility of their web sites. But in 1999, the vast majority of Web sites consisted of static HTML content. Emerging technologies, such as CSS and JavaScript, were not well supported in browsers or assistive technologies used by people with disabilities. WCAG 1.0 therefore requires that websites be operable with technologies like CSS and JavaScript disabled in your browser and the focus of the guidelines is simply on how to make HTML content accessible.

A principle-based approach

The new W3C Accessible Rich Internet Applications (WAI-ARIA) specifications for Web 2.0, under development, is an example of such an emerging Web technology. It turns out that the lack of JavaScript support in assistive technologies was not the only accessibility problem for JavaScript implementations. The HTML specification itself was lacking some accessibility features. ARIA focuses on interoperability and usability by a broad range of users, and fills the accessibility gaps in the HTML specification. Browser and assistive technology support are being developed concurrently with the specification, therefore, the combination of JavaScript and ARIA technologies will be accessibility supported by the time WCAG 2.0 becomes a W3C Recommendation.

Two other key positive features of WCAG 2.0 are the supporting documentation and test criteria. Even though the volume of supporting documentation seems overwhelming at first, the Quick Reference is a convenient tool that most developers will want to use to quickly index into the information that is most relevant to them. Testers and evaluators will be pleased to have documented test criteria for each technique. In a parallel effort, the W3C WAI-ARIA work will produce test suites with lots of source code which may be included in the plethora of techniques already provided.

The broader perspective

IAccessible2 Increased Media Coverage

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:

• Venezuela: IBM Develops assisted technologies for people with disabilites
• Columia: Unlimted accessibility to know the web
• Peru: Searcher for Intraet and Webs

Here are a few of the many launched in China:

• Explore the Human Potential: IBM Explainse the Deep Meaning of Accessible Information
• Creative Technology Helps to Build an Internet Platform for the Blind - IBM Launched IAccessible2

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.

W3C ARIA Specifications Advance to Second Working Draft

The W3C Web Accessibility Initiative (WAI) Protocols and Formats (PF) working group announced the second working drafts of ARIA specifications this week. Accompanying these specifications is a new high level  ARIA Suite Overview of the effort that was created out of the WAI Education and Outreach Working Group.

There are a number of enhancements which developers and project managers should be aware of :

• The Roadmap Deliverables Timeline

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

Roles:

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