The Accessibility Rules Format 1.0 Specification [1] has been approved by the OpenAjax Alliance Steering Committee as an official Specification of OpenAjax Alliance, and unanimous recommendation of approval by the OpenAjax Alliance membership.

The Rule Format 1.0 spec has been under development within the Accessibility Working Group [2] for a couple of years (with early work done in task force stage before an official Working Group was formed last year).

Here is a description of the Rules Format 1.0 Specification:

This document describes the requirements for the structure of OpenAjax Accessibility (OAA) Web validation rules and rule sets used by accessibility test tools. Version 1.0 of this rules format will be used to create validation rules for W3C Web Content Accessibility Guidelines 2.0 targeted at HTML 4.X and WAI-ARIA. These rules are targeted at dynamic content and may be applied to a specific Document Object Model (DOM) node or to a set of DOM nodes or the entire document. Rules are to be written in JavaScirpt and rely on the W3C DOM with common browser extensions. Test tools can trigger the evaluation of these rules based on user interaction and external events. To see rule samples, in development, please see [3] or find the sources in the OAA repository on Source Forge [4].

Multiple companies/products that have stated publicly that they are implementing parts of this Specification:

* AInspector – the accessibility inspector for Firefox [5]
* Deque
* Illinois Functional accessibility evaluator 2.0 [6]
* Accessibility extensions for Firefox [7]
* IBM Rational Policy Tester
* OpQuast Reporting Tool [8]
* Parasoft

The co-chairs of the Accessibility Working Group (Rich Schwerdtfeger of IBM and Jon Gunderson of University of Illinois) expect that work will continue towards an updated version 2 of this Specification.

[1] /member/wiki/Accessibility_Rules_Format_1.0
[2] /member/wiki/Accessibility
[3] http://www.oaa-accessibility.org/rules/
[4] http://sourceforge.net/projects/openajaxallianc
[5] http://code.google.com/p/ainspector/
[6] http://fae.cita.uiuc.edu/
[7] http://firefox.cita.uiuc.edu/
[8] http://www.alexa.com/siteinfo/mon.opquast.com

On April 11, IBM and Dojo Foundation announced Maqetta, an HTML5 authoring tool for building desktop and mobile user interfaces. The announcement includes a new Maqetta.org Web site that hosts the Maqetta application [1], and the contribution by IBM of the underlying source code as a new open source project at Dojo Foundation [2].  An eWeek article on the announcement is at [3].

Maqetta uses “OpenAjax Widgets” (the widget metadata part of the OpenAjax Metadata 1.0 specification [4]) .

[1] http://maqetta.org/
[2] http://dojofoundation.org/
[3] http://www.eweek.com/c/a/Application-Development/IBM-Launches-Maqetta-HTML5-Tool-as-OpenSource-Answer-to-Flash-Silverlight-669762/
[4] /member/wiki/OpenAjax_Metadata_1.0_Specification_Widget_Overview

Recent Microsoft updates patched some code that was used by the RPC layer (from the Shindig project) to do messaging on Internet Explorer 6 and 7. OpenAjax Hub 2.0.7 fixes this by disabling the broken transport layer (NIX) and falling back to the fragment identifier transport (IFPC). Some further details can be found at [1] and [2].

[1] http://openajax.org/pipermail/interop/2011q2/001261.html
[2] http://openajax.org/pipermail/interop/2011q2/001262.html

It is likely that yet another update to the OpenAjax Hub open source project will happen sometime soon to include an alternate and faster cross-iframe transport technology for IE6 and IE7 (using Flash under the hood). This alternate transport approach is in the latest Apache Shindig open source trunk. An initial security assessment was done on this new transport approach and so far no security problems have been found.

An exciting new open source project is the Eclipse Orion project. The Eclipse Orion project [1] (developer tools for the Web, on the Web) was announced in Jan 2011 and held planning meeting in March [2], where the Orion team showed the secure and extensible Web plugin technology approach that they are using, using OpenAjax Hub under the hood. Each “JavaScript plugin” gets isolated into its own iframe sandbox, and all communications across plugins are done with pub/sub messaging.

[1] http://www.eclipse.org/orion/
[2] http://wiki.eclipse.org/Orion/Planning_Meeting

After more than a year’s worth of collaboration between OpenSocial Foundation and various members of OpenAjax Alliance, yesterday OpenSocial Foundation announced the release of the OpenSocial 1.1 specification. One of the major new features in version 1.1 of OpenSocial Gadgets is the inclusion of OpenAjax Hub as the mechanism for inter-gadget communication.

The announcement talks about the use of OpenAjax Hub:

Version 1.1 officially support an inter-gadget eventing system based upon the OpenAjax Hub. “The OpenAjax Hub is a set of standard JavaScript functionality defined by the OpenAjax Alliance that addresses key interoperability and security issues that arise when multiple Ajax libraries and/or components are used within the same web page.” By incorporating this technology into OpenSocial, gadgets are now able to declare, as part of the module definition, events to which they are able to publish and subscribe. In addition, this specification has reserved several topic namespaces for use by OpenSocial. Please refer to the Inter-Gadget Eventing in the Core-Gadget specification for more information.

OpenAjax Hub is included in the Gadgets spec mostly via reference to the OpenAjax Hub 2.0 Specification. The Apache Shindig open source implementation (version 2.0.x) includes the OAHub source code within its distribution.

Congratulations to everyone! It isn’t often that major parts of the industry get on the same technology page.

The OpenAjax Alliance members and Steering Committee have formally approved the creation of a new Accessibility Working Group. The WG will be co-chaired by Richard Schwerdtfeger of IBM and Jon Gunderson of the University of Illinois.

The new Working Group will publish materials centered on ARIA compliance checking and best practices within web applications that provide rich user experiences in the browser using “Ajax techniques“. The Working Group’s charter provides details on the deliverables. The WG is already far along in completing its work because several companies have been collaborating for over a year within an OpenAjax Alliance “task force”. The committee’s home page provides links to the various work activities.

In late October, OpenAjax Alliance held its annual Steering Committee election. The winners were the four incumbents: Aptana, Dojo Foundation, Eclipse Foundation and IBM. Congratulation to the winners. They will all serve until October 2012.

(1) Press coverage of OpenAjax’s accessibility activities

On August 4, the OAA sent out a recent press release on recent accessibility activities. You can find pointers to that press release and pointers to some of the press coverage (there was actually a large amount of coverage) at the following location:

• /press.php

(2) Vote coming soon on creating a formal Accessibility Working Group

The Accessibility Task Force has been very active in the past several year and continues to be active. There is a likelihood of one or two major companies joining this effort in the coming weeks.

The task force is in the middle of promoting themselves from Task Force to a formal Working Group because they want their main specification to become an official OpenAjax Alliance Specification. They have already posted a charter and held the Creation Review phone call:

• Main wiki page: /member/wiki/Accessibility
• Proposed WG charter: /member/wiki/Accessibility_Charter
• Creation Review phone call: /member/wiki/20100811_Accessibility_Working_Group_Creation_Review_Minutes

(3) OpenAjax Hub integration into OpenSocial Gadgets

Some members of the OpenAjax Alliance Interoperability Working Group have been very active in coordination efforts with OpenSocial Foundation to add OpenAjax Hub 2.0 into the OpenSocial Gadgets specification so that Gadgets will use the OAHub for inter-gadget publish/subscribe communications. That coordination effort has been going on for almost a year now and is coming to the finish line. The results of this coordination effort:

• The Gadgets 1.1 specification will reference the OAHub 2.0 specification as the definition of the pubsub APIs
• The Shindig open source project will include a copy of major pieces of the OAHub 2.0 open source code
• We have merged the low-level message transport layer between the Shindig open source project and the OpenAjax Hub open source project so that both open source efforts are using the exact same code. (This was mostly a case of OAHub merging in the gadgets.rpc code as a replacement for the “SMash” code that IBM Research contributed to IBM to OAA in 2007)

The Gadgets 1.1 spec (with the reference to OAHub 20) is scheduled for approval and completion this fall and the updated Shindig open source code (with OAHub inside) is scheduled for completion early in 2011.

(4) OpenAjax Hub enhancements for persisting data

There has been recent discussion in the Interoperability WG about enhancing the OAHub specification and/or open source to add a feature where it will be possible to persist the most recently transmitted data associated with a particular event so that clients can retrieve those values. This is mostly targeted at the case where a new widget is added to a mashup after an event has been published and therefore the new widget will not have noticed the event. No decisions have been made yet about whether to add this feature to an updated OAHub spec.

(5) OpenAjax Metadata 1.0 Approval in spring 2010

The OpenAjax Metadata 1.0 spec was approved in spring 2010 and had some nice coverage in Ajaxian:

• OpenAjax Metadata 1.0 and the Adobe Dreamweaver Widget Browser

(6) OpenAjax Metadata – using JSON as an alternative to XML

One complaint from the community about OpenAjax Metadata was that it uses XML instead of JSON. (“XML metadata. Oh yeah, another commitee with a knowledge set of the previous century?”) A few weeks ago, I sent email to the IDE WG about work that IBM is doing with OpenAjax Widgets where we are using a JSON version of OAM instead of XML:

• JSON serialization of OAM

This might develop into a OpenAjax Metadata spec update.

OpenAjax Alliance has published a press release outlining the progress within our Accessibility committee at helping the disabled and aging take full advantage of Web 2.0. The press release can be found here and a sample of follow-on press articles can be found here.

This announcement reflects the fact that the Accessibility committee is far along in their development of their accessible RIA validation testing rules and accessibility reporting best practices. In the next month, the members of OAA and Steering Committee will decide whether to promote this committee to a properly chartered Working Group.

This post provides some background information to supplement the announcement of formal approval of the OpenAjax Metadata 1.0 Specification.

OpenAjax Alliance started its IDE Working Group back in 2007, with participation over the years from Abiss, Adobe (Dreamweaver), Aplix, Aptana, Dojo Foundation, Eclipse Foundation, GDE Solutions, IBM, Marcos Caceres (now employed by Opera), Microsoft, RadWebTech, SAP, Sun Microsystems, TIBCO, and WebTide. The  objective was to promote better Ajax tools, both widget-centric designer tools and code-centric developer tools. To meet this objective, the IDE Working Group produced the OpenAjax Metadata 1.0 Specification, which defines a set of industry-standard metadata defined by the OpenAjax Alliance that enhances interoperability across Ajax toolkits and Ajax products.

OpenAjax Metadata 1.0 defines metadata for the following:

• Ajax widgets (“OpenAjax Widgets”), which include:
  • UI controls – The user interface components — such as combo boxes, menu bars, charts, and calendars — that some Ajax libraries provide.
  • Mashup components – Pre-packaged mini-applications (sometimes called “widgets” or “gadgets”) that can be combined together within a composite application (the “mashup”), where the mashup components react to each other intelligently, such as when the user selects an address in one component, and a different component displays an updated map for that address.
• Ajax APIs – The runtime JavaScript APIs (e.g., classes and methods) that are available for an Ajax library.

The primary target consumers of OpenAjax Metadata 1.0 are Web page developer tools targeting Ajax developers. These software products consume and use the metadata to provide an enhanced experience for users building Ajax-powered solutions. In particular:

• Ajax IDEs use OpenAjax Metadata to provide developers with API documentation, intelligent code-assist, widget palettes, and widget property editors.
• Mashup assembly applications use OpenAjax Widget Metadata (“OpenAjax Widgets”) for definitions of widget user interface, widget APIs, identification of pub/sub messages to which the widget publishes or subscribes, and identification of shared properties.

The widget parts of OpenAjax Metadata, “OpenAjax Widgets,” grew out of a file format submission from the Adobe Dreamweaver team. The IDE Working Group concluded that Adobe’s submission represented solid technology, but made various detailed changes to the original proposal. The Dreamweaver team tracked the spec changes, and now Dreamweaver CS4 and CS5  support OpenAjax Widgets as defined by the the OpenAjax Metadata 1.0 Specification as its standard format for 3rd party widget extensibility. Various OpenAjax Widgets are available on the Dreamweaver Exchange (where Dreamweaver users can find 3rd party widgets).

The Dreamweaver widget submission was focused on user interface components — such as combo boxes, menu bars, charts, and calendars — that some Ajax libraries provide. Some members of OpenAjax Alliance pushed to extend the OpenAjax Widget spec to address mashup requirements. This resulted in a handful of additional features that are optional for IDE but required for mashup tools. The mashup-oriented features found in OpenAjax Widgets are summarized in this section of the spec. The “mashable widgets” feature in OpenAjax Widgets overlaps largely with the OpenSocial Gadgets format developed by OpenSocial Foundation, but not completely. There are various features critical to mashup scenarios that are not yet supported by OpenSocial Gadgets. Various members of OpenAjax Alliance are now working with members of OpenSocial Foundation to mirgrate mashup-oriented features from OpenAjax with OpenSocial, although this process will likely take some time.

The other major piece in the OpenAjax Metadata spec is an XML format for representing JavaScript APIs (“OpenAjax API Metadata”). The starting point for these features was the ScriptDoc XML format supported by Aptana Studio. The OpenAjax API Metadata spec is generally close to ScriptDoc XML. Aptana implemented support reading the OpenAjax API Metadata format (which provides information to help with code assist) and worked with leading Ajax toolkits to generate OpenAjax API Metadata. Eclipse Foundation also includes support for OpenAjax API Metadata within its JSDT component.