I don’t agree with any of those statements, but if you have specific concerns about the draft and send them in during the last call response period, the working group is required to address the issues formally. We have several issues deferred until a later version of ARIA, so they may already be addressed, but all constructive feedback is welcome.

Although most ARIA controls require interaction with JavaScript, many of the ARIA roles are static semantic roles that require no JavaScript, for example, the landmark roles can provide additional navigation for user agents and assistive technology.

Web applications are always defined by the DOM, because you can’t have a script that executes outside the context of a document. Likewise SVG, or any other implementing host language will have a DOM and may or may not be accessed via JavaScript, another programming language, or directly by the user agent or assistive technology. The DOM is still the lowest common denominator.

If it’s never perceivable to WAI-ARIA compliant browsers, how is it perceivable to sighted users?

Yes, JavaScript can have arbitrary data structures but users don’t have any direct access to any of that data and, with the exception of a few specialized dialogs (alert, confirm, prompt) JavaScript cannot display anything to a user without inserting it into the DOM. Accessibility, is about the user, not about the API.

SVG is nothing but a DOM structure, and ARIA markup can be used inside SVG, completely hack-free. Although, I am unaware of an SVG viewer implementation that supports ARIA at this time.

Before going into how Bespin could be made accessible via ARIA, I feel compelled to state that the canvas element is/was intended for drawing graphics. Using a drawing tool for a document goes against the WCAG 2 Principle that “content must be robust” and the HTML 5 spec even states, “Authors should not use the canvas element in a document when a more suitable element is available.” That said, I am aware of the drawbacks to using “more suitable elements” for something like a text editor, and applaud the Bespin creators for their experimentation and continued attempts to make a project like Bespin more accessible.

Since you seem very familiar with Apple technologies, using canvas here is sort of like using a Quartz composition. Quartz compositions are most often useful in the context of an application, which can be made accessible, although it will take significantly more work since the application author is using a custom UI layer instead of using standard Cocoa controls. Likewise, the canvas element is always used in the context of a larger DOM that can be made accessible, although it will take significantly more work since the web application author is using a custom UI layer instead of using standard HTML elements and controls.

Bespin could be made accessible in a number of ways, but one way that comes to mind is by managing focus of the entire application via the “roaming tabindex” technique, and dynamically inserting DOM elements for ARIA roles as needed. Todd Kloots (from YUI) has some blog posts discussing the “roaming tabindex” technique for specific widgets, but there is nothing to stop you from using the technique for an entire application. Although it is not the ideal solution because it would not allow for additional UI shortcuts that most AT has into the rest of the DOM (via methods like an item chooser or navigation by header), the Bespin editor could be made accessible by only allowing access to a single element at a time: whatever text is currently selected, or whatever menu item is currently focused. For example, updating a DOM element that represented the current line of the text editor would not cause a substantial performance hit.

ARIA 1.0 is intended to allow existing web applications to be made accessible using today’s technologies, and the DOM is the lowest common denominator for web applications. You can have a document without CSS or without JavaScript, but you can’t have a script that executes outside the context of a document. The programming interfaces for ARIA are standard DOM methods.

But it’s not the job of the group specifying ARIA to make that accessible, it’s (now) the job of the HTML5 spec. So far, I’m not aware that work has even begun. I agree it needs to be done, but take it up with the HTML WG.

I would still like to see what you’re doing that you can’t do with ARIA and the DOM, specifically.

The DOM doesn’t “aggregate JavaScript”. It provides hooks into the document for JavaScript. Sure, event handlers have references stored in the DOM, but the rest of the code does not sit in the DOM at all.

Ultimately, the DOM is about pages, about static documents. Applications are more than that — they are, almost by definition, anything you can dream up. By making ARIA specifically limited to the DOM, you’re limiting its scope, which is unfortunate.

As far as digging into browsers to implement the API I think we really need (this is relevant to @lloyd as well), that’s far beyond what my job should be. We’re just three people, trying to make great products, and sharing a lot of what we learn with the community. If we had to fix every browser shortcoming we deal with, our company would fail. All the browsers have full time employees available to work on this problem, but it doesn’t seem like anyone is pushing them to do so.

then to the extent that this api can be faked, we have a zero plugin, works everywhere subset. some sorta plugin (uh, browserplus?) could implement the api for real, and when present could provide the full functionality… all theoretical, of course — but a path to filling the hole for real.