Summary
The accessibility community is understandably concerned about the accessibility of client-side scripting, in particular using Asynchronous JavaScript and XML (Ajax) to produce Rich Internet Applications. Steve Faulkner of Vision Australia and founder member of the Web Accessibility Tools Consortium (WAT-C) and myself on behalf of The Paciello Group (TPG) have collaborated in an effort to come up with techniques to make Ajax and other client-side scripting techniques accessible to assistive technology.
The Web Accessibility Initiative's Protocols and Formats working group directly address the issue of making rich Internet applications accessible, and we borrow some of their concepts to investigate methods of ensuring that Ajax applications work with leading assistive technology products. The bad news is that it isn't possible to make Ajax work in every known assistive technology, in the same way that it isn't possible to get Ajax to work with older browsers, but we explain the fundamental issues; how to inform users of assistive technology that a change has taken place, and how they can interact with the content. To illustrate our findings, we summarise the behaviour of popular screen readers.
Author: Gez Lemon and Steve Faulkner
Contents
- Screen Reader Modes
- Informing a Screen Reader that Content has Changed
- Structuring Content for Ajax Applications
- Examples of Screen-Reader Friendly Ajax
- Further Reading
- Translations
Screen Reader Modes
To understand the issues behind ensuring that Ajax is accessible to screen readers, it's essential to have an understanding of how screen readers work. To allow screen reader users to read and interact with web content, screen readers take a snapshot of the web page, and place this content in a virtual buffer. The screen reader uses the virtual buffer to allow the user to navigate the content. Without the virtual buffer, the screen reader only has access to the parts of the page that are focusable by non-assistive user agents, such as anchors and interface elements. Without the virtual buffer, the user cannot interact with other elements and their child nodes in the content, such as images, lists, tables, and so on. Screen readers have their own specific name for the virtual buffer, such as Virtual Focus mode in Supernova, but they essentially do the same job. The following section describes how the virtual buffer is implemented in JAWS and Window-Eyes.
JAWS Virtual PC Cursor Mode
The virtual buffer is referred to as Virtual PC Cursor mode in JAWS. Virtual PC Cursor mode is enabled by default when viewing HTML documents in supported applications (such as Internet Explorer and Firefox with JAWS 7.0), and can be toggled on and off using the keystroke combination Insert + Z. In this mode, the user has access to HTML elements and their attributes, such as the th element for table headings.
When in Virtual PC Cursor mode, JAWS responds inconsistently to client-side scripting events. JAWS is able to respond to basic events in Virtual PC Cursor mode, such as click and keypress, and will refresh the Virtual PC Cursor snapshot to reflect any changes made to the content. The problem when using Ajax is that new content isn't usually added directly in response to these events; instead, the content is usually added through the onreadystatechange event of the XMLHttpRequest object. Interestingly, JAWS 7.0 responds to the onreadystatechange event with Firefox, but not with Internet Explorer. The lack of response to the onreadystatechange event along with authors failing to focus on the parts of the document that has changed is essentially why most Ajax applications are reported to either not work at all, or behave inconsistently. For changes to be reported successfully to JAWS in Virtual PC Mode (the default mode and the mode that allows the user to interact with the content), the only reliable method of adding new content in Virtual PC Cursor mode is as a direct result of a click, keypress, or mouseover event, which obviously isn't good enough for an Ajax solution.
From version 6, JAWS introduced a command to refresh the Virtual PC Cursor using the keystroke combination Insert + Esc. This means that a JAWS user can use this keystroke combination to gain access to content that has been added dynamically. The problem is letting the user know that the content has changed. A solution we considered was to add content that prompts the user to refresh the virtual buffer as a direct response to a click/keypress event, and replace that content when the onreadystatechange event is raised in the XMLHttpRequest object. The thinking behind this approach was that users of JAWS 6 and later could use the Refresh Virtual PC Cursor command, and users of earlier versions of JAWS and other screen readers that use a virtual buffer would be able to respond to this by toggling virtual mode on and off — for example, using the keyboard combination Insert + Z twice would toggle the Virtual PC Cursor mode on and off in JAWS, refreshing the virtual buffer.
When testing this technique with Internet Explorer, the prompt to refresh the virtual buffer is announced by JAWS, but refreshing the buffer using the keystroke combination Insert + Esc only announces that the screen has been updated, and doesn't start to read the updated content. Toggling the Virtual PC Cursor mode off and on again only results in JAWS announcing that it is changing modes in Internet Explorer. As JAWS with Firefox responds to the onreadystatechange event, the content from the click event is overridden by the content from the onreadystatechange event, and announced to the user. As Firefox can respond directly to the onreadystatechange event, and toggling modes doesn't announce new content, this technique isn't worth pursuing further.
JAWS PC Cursor Mode
PC Cursor mode is the opposite of Virtual PC Cursor mode in that it doesn't use a virtual buffer. In this mode, the user interacts directly with the application, and can only focus on elements that a non-assistive user agent can focus on, such as anchors and interface elements. If Ajax is used in response to an event, then it can be made to work in this mode, as the scripting capabilities are limited by the browser that JAWS is "reading" rather than restricting the events to the few that JAWS responds to in order to update its virtual buffer when in Virtual PC Cursor mode. Although the user has very limited ability in PC Cursor mode, they can activate links and command buttons. If the content generated by the onreadystatechange event can receive focus, then the user will be notified and can access the content generated in this mode. The HTML specification only allows certain elements to receive focus, so unless the generated content is in an element that can receive focus, extra work is required to make this approach workable. For more information, see the section on informing a screen reader that content has changed.
JAWS Forms Mode
Forms mode is identical to the PC Cursor mode. JAWS associates text prompts for form controls that have been marked up and explicitly associated to a form control with the label element, or guesses by looking for text immediately to the left or above form controls (or to the right for checkboxes and radio buttons). Users enter Forms Mode by Pressing Enter when an edit box has focus.
As Ajax is used to build applications, it makes sense to use forms for their interface elements. This approach means that the user's interaction with form controls will work correctly with Ajax when the user is operating JAWS in Forms Mode or PC Cursor mode, but would need to switch to Virtual PC Cursor mode when interacting with non-form content.
Window-Eyes Browse Mode
Browse Mode is the name given to the virtual buffer in Window-Eyes, and is toggled on and off using the keystrokes Control + Shift + A. As with JAWS' virtual buffer mode, when Window-Eyes is in Browse Mode, it does not have access to content that is dynamically generated with the onreadystatechange event of the XMLHttpRequest object in Internet Explorer. Window-Eyes does respond to basic events such as click and keypress, and like JAWS, updates the virtual buffer when Browse Mode is toggled on and off.
When Browse Mode is off, Window-Eyes is only able to focus on anchors and interface elements, and is unable to interact with other HTML elements. For the user to be able to interact with form controls, Browse Mode must be off. If Ajax is activated in response to events raised by anchors or interface elements, then the user can be informed that the content has changed in Window-Eyes, in the same way they can with JAWS. Both JAWS and Window-Eyes are able to read the updated content when not in Browse/Virtual PC mode, but the content is only available as part of a reading "screen scrape" of all text currently available on the screen.
Informing a Screen Reader that Content has Changed
If content is changed with scripting, then this needs to be relayed to the screen reader. Without a mechanism to discover what has changed, a screen reader user might not be notified that the content has changed at all, or only be notified that the content has been changed, but will be required to read the whole document to discover exactly what has changed. For example, when content is inserted into the document with scripting, Window-Eyes responds with the following.
Loading Page. Load Done. Looking for visible line.
The last visible line is the line containing the element the user activated to produce the new content, so the user has no idea how to find what has changed. To get around this, the ECMAScript focus method can be used to place focus to the part of the page that has changed. For this to work, the target element needs to be an element that can receive focus. In HTML (and XHTML) the only elements that can receive focus are the a, area, button, input, object, select, and textarea elements.
In XHTML 2, all elements will be able to receive focus, but the problem we have with the current specifications for HTML 4.01 and XHTML 1.x is that they do not allow elements other than anchors and interface elements to receive focus. To get around this problem, The Web Accessibility Initiative's Protocols and Formats working group propose a Dynamic Accessible Web Content Roadmap that suggests using a tabindex value of -1 on elements that cannot receive focus according to the specification, and will formalise this with the States and Adaptable Properties Module. A need for making all elements focusable is also recognised by Web Applications 1.0.
The tabindex attribute accepts a value between 0 and 32767. A positive value determines the order that the element will be visited when navigating using the keyboard. A value of 0 means that the element will be visited where it naturally occurs in the document source. Assigning a tabindex attribute value of 0 to an element that is neither an anchor nor an interface element means the element will be able to receive focus with ECMAScript, but might be confusing to visitors as they will be able to navigate to the element using the keyboard. Assigning a tabindex attribute value of -1 means that the element will be able to receive focus with ECMAScript, but will not be placed in the tab order. Internet Explorer and Firefox both support a tabindex attribute value of -1, but this may not work with other browsers. For example, a tabindex attribute value of -1 is ignored by Safari, and the element will not receive focus with the ECMAScript focus method.
When focus is given to an element that has a negative tabindex value that wouldn't normally receive focus, such as a paragraph element, the behaviour is different depending on the mode — in virtual buffer mode, the screen reader focuses on the element, but it won't automatically announce the content of the element; if virtual buffer mode is off, the screen reader announces the content of the element. In virtual buffer mode, the user needs to request the screen reader to read the current line after an element receives focus (Insert + Down arrow in JAWS and Down arrow in Window-Eyes and Supernova). If focus is given to an anchor in virtual buffer mode, then the content of the anchor element is automatically announced.
When a non-interface element is given a tabindex attribute value of -1 so that it can receive focus in Window-Eyes when Browse Mode is off, it is mistakenly reported as being an edit box, as that is what it has interpreted from Microsoft Active Accessibility (MSAA), but announces the content to the user. The following is an extract of what MSAA reports for a paragraph with a tabindex attribute value of -1.
| Name | "Content for paragraph." |
|---|---|
| Value | none [null] |
| Role | editable text |
| State | focused, focusable |
JAWS merely announces the text that has focus to the user, and doesn't report the element as being an edit box. Unfortunately, it is impossible to get Home Page Reader (HPR) to work at all, even though it supports scripting, because it doesn't support the focus method.
Structuring Content for Ajax Applications
There are several approaches that can be used to structure content for an Ajax application so that it works with screen readers. The simplest, and probably the best fit for an application, is to make the parts of the application that are to be activated by the user interface elements in a form. With this approach, the user can be informed of the change by focusing on the part of the document where the change took place. This requires the user to change in and out of virtual buffer mode, but this is what the user expects anyway when interacting with forms.
If the changed part of the content is in the form itself, then this presents a problem; although the user can get at the text, they won't be able to interact with the content as they would if they were in virtual buffer mode. As an example, consider a data table that is embedded in a form (in itself, this is indicative that the structure could be improved, but worth considering, as it's a plausible scenario). If a data cell in a table that is embedded in a form element is updated in response to the onreadystatechange event, focus can be given to the table cell, and the screen reader will successfully announce it. The problem is that the table containing the text will not be recognised, which means the user won't be able to determine headers, or be able to navigate the rest of the table. In order to do that, the user will need to change the mode back to the screen reader's virtual buffer mode. As screen readers always announce the title attribute for form controls that don't have explicitly associated labels for elements that can receive focus in a form (including non-interface elements with an explicit tabindex attribute), regardless of the verbosity settings, this could be prompted through the title attribute, and then removed when the element loses focus. For example, the following might be used to update a table cell in response to the onreadystatechange event being fired.
var objCurrent = document.getElementById('update');
var objReplacement = document.createElement('td');
// Set the title attribute to prompt the user to change mode
// This should use simpler language than used here, as the user
// isn't likely to understand the concept of a virtual buffer
objReplacement.setAttribute('title', 'Switch to virtual buffer');
// When the element loses focus, remove the attribute for other
// user agents
objReplacement.onblur = function(){this.removeAttribute('title');};
// Set a negative tabindex attribute value so the element
// can receive focus
objReplacement.tabIndex = -1;
objReplacement.setAttribute('id', 'update');
objReplacement.appendChild(document.createTextNode(strResult));
// Replace the existing node with the new node
objCurrent.parentNode.replaceChild(objReplacement, objCurrent);
// Set focus to the element
objReplacement.focus();If interaction with the application isn't in a form, the most important thing is to inform the user that they must have virtual buffer mode switched off (as they would in order to use a form). This isn't as simple as it sounds, as it will need to be worded so that is easily understood by screen reader users that don't necessarily understand the technicalities of the software they are using — in the same way that users of visual browsers don't necessarily know how to resize text. A simple solution would be to have a help page that is easily discoverable from the application that explains virtual buffers, with a table containing the commands to toggle the virtual buffer in all of the popular screen readers. The following table shows how to toggle the virtual buffer in the screen readers we used for testing.
| Screen Reader | Keystroke |
|---|---|
| JAWS | Insert + Z |
| Window-Eyes | Control + Shift + A |
| Supernova | Left Control + 4 |
Examples of Screen-Reader Friendly Ajax
To help illustrate the concepts presented in this article, we have put together three very contrived examples of an Ajax application. All of the examples should run as expected when the virtual buffer is off with Internet Explorer. Examples 1 and 2 work with Firefox and JAWS 7 in virtual mode.
Further Reading
Translations
- Brazilian Portuguese, kindly provided by Mauricio Samy Silva. (2006-05-26)
- Belorussian, kindly provided by Patricia Clausnitzer. (2010-05-13)
Category: Accessibility.
[making-ajax-work-with-screen-readers.php#comment1]
I can't tell you how much I appreciate your research and your timing of this article...just what I needed as Sharron Rush and I head to NetSquared in San Jose next week.
Posted by goodwitch on
[making-ajax-work-with-screen-readers.php#comment2]
The simple examples demonstrate the big usability problem with dynamic content for screen reader users, which is that objects on the screen can change, be added or removed, and the user may not know. To add to this, the user also doesn't know where that change occurred on the page.
It is not sufficient to say that users can hit ins+esc to refresh the jaws buffer if they don't have a reason to believe that anything has changed.
As you indicate, this issue is somewhat resolved when in forms mode in that there is no off-screen model so the user doesn't need to refresh the off-screen model to access the content, provided that he knows where to find it or runs into it (perhaps due to good application design).
We've been dealing with the issues around rich internet applications at Adobe for quite a while now, and I'd like to encourage people to take a look at Flex (http://www.adobe.com/macromedia/accessibility/features/flex/). I'll be showcasing a series of accessible Flex application components on the new Adobe accessibility blog (http://blogs.adobe.com/accessibility) soon.
Posted by AWK on
[making-ajax-work-with-screen-readers.php#comment3]
Thank you for the feedback, Andrew.
I totally agree. We investigated methods whereby the user was informed that content was updated in response to a direct action (rather than the onreadystatechange event), but it couldn't have been considered equivalent access, as the user would have to perform several keystrokes after that to get to the changed content, so we abandoned the idea.
Absolutely, but providing the user knows where to find the content is a big obstacle, but fortunately, solvable using the focus method.
Thank you for the information on Flex.
Best regards,
Posted by Gez on
[making-ajax-work-with-screen-readers.php#comment4]
Thanks Gez and Steve for this excellent article. You do a fantastic job motivating the discussion by explaining the "virtual buffer" concept.
I'd like to use this in an article I'm writing on this very topic. I want to try and summarize where we are now, what an ideal interaction mode might be, and then how we might get there. Obviously, "getting there" is going to involve helping the screen reader vendors figure out the best way of making their software respond correctly to dom events and provide the correct info from the DOM to the user. However, this will take a while, and also its not exactly clear how the screen reader can help, especially when multiple asynchronous events occur simultaneously (or nearly coincident).
Aaron Leventhal is working on this very problem. He is one of the principle authors of Firefox, and also works for IBM research. He is involved with the W3C protocols and formats working group who are working on these very issues. I have heard comments to the effect that "yes, IBM and the w3c are working on this, but their solution encourages invalid code, uses namespaces which are cumbersome and sometimes misunderstood, and this stuff is better left for XForms. In fact, this solution was never meant to be "a real solution"; it's a work around. XForms, XHTML2, declarative markup, etc (i.e. a much smarter user agent) is the correct solution, but that isn't going to help us now!
Here are some interesting comments from Aaron on the whole issue of asynchronous alerting:
Another thought is to take a "real world" application (something complex enough to be difficult, simple enough to be fairly easily modifiable), and experiment with different work-arounds to help today's screen readers deal with at least some of the most common RIA paradigms. If anyone has suggestions on such a freely available, open source ajax application which we could experiment with, please let us know.
Thanks again Gez and Steve for an excellent article.
-- Rich
Posted by Rich Caloggero on
[making-ajax-work-with-screen-readers.php#comment5]
Thank you for your kind words, Rich.
Yes, the fundamental problem is that we're trying to build rich Internet applications using technology that just wasn't designed for that. Innovative developers have come up with ways of building applications that appear to work in modern visual browsers, but as usual, accessibility hasn't been considered in the process.
I've been following the discussions about the liveregion role, and think it will be a great addition to the protocols and formats roadmap.
That's an excellent idea, Rich - and realistically, the only way of knowing for sure that a rich Internet application can be made accessible.
Posted by Gez on
[making-ajax-work-with-screen-readers.php#comment6]
Oh, and I forgot to say that I am blind and a screen reader user.
I'd be glad to test any applications people want to suggest, again keeping in mind that they should be simple enough to be "hackable" (understandable + modifiable fairly easily), but complex enough to be meaningful.
-- Rich
Posted by Rich Caloggero on
[making-ajax-work-with-screen-readers.php#comment7]
Are you using a different screen reader to the ones we tested with - JAWS, Window-Eyes, and Supernova? If so, it would be great to know which one you use, and whether you tried any of the examples with the virtual buffer off.
A hurdle is that people are likely to think you will perform a public evaluation of the accessibility of their application, and it's unlikely anyone would want that unless they were already confident the application is accessible. It's worth pointing out that that isn't the case. This is a win/win situation - the application could be made accessible as a result, and we as developers learn important lessons about how to structure rich Internet applications from the process.
Email addresses aren't published by default, so anyone wanting to get in touch with Rich directly, please contact me and I'll pass on your contact details.
Posted by Gez on
[making-ajax-work-with-screen-readers.php#comment8]
I came accross some interesting behaviour when testing the third example (form based) using JAWS 6.1 and IE6.
When using the "f" shortcut key to find the form and locate the button the content of the randomly generated text changed but the content spoken by JAWs did not match the screen content. However if I simply used the up arrow or the "b" to return to the button after listening to the content the content spoken by jaws matched that on the visual display.
Care to speculate on the discrepancy?
Mike
Posted by Mike Moore on
[making-ajax-work-with-screen-readers.php#comment9]
In a nutshell - Ajax doesn't work reliably with Internet Explorer in virtual buffer mode, but does in either Forms Mode or PC Cursor mode (they're the same thing). If you switch to PC Cursor mode (Insert + Z), it will work as expected.
Posted by Gez on
[making-ajax-work-with-screen-readers.php#comment10]
Mike wrote:
Mike, I tested this in Virtual PC cursor mode and did not get the results you found: No new content was announced by JAWS.
Posted by steve faulkner on
[making-ajax-work-with-screen-readers.php#comment11]
Hi Steve,
I understand the point you are making, however you overlooked the role type of document and application in the role taxonomy specification. Setting it to application is the equivalent of telling JAWS to treat the page like a GUI application. This means all the browser mode functions get disable in the context of this role. Window-Eyes supports this now. It just has not been implmented in JAWS yet.
Aaron indicated some other states and properties we are including to support AJAX and live regions. Be patient, the specification is not done yet. We will fill the holes. The Firefox 1.5 release did not address all the AJAX use cases for live regions but it does support rich widgets. If you have use case/requirements that the PF group has not yet addressed please email myself or Aaron and we will address them in the PF working group.
Cheers,
Rich
Posted by Richard Schwerdtfeger on
[making-ajax-work-with-screen-readers.php#comment12]
Gez asked:
I use Jaws, and tried the examples with the virtual buffer on and off. I've pretty much come up with the results you've stated.
Posted by Rich Caloggero on
[making-ajax-work-with-screen-readers.php#comment13]
Reading parts of this article again, there seems to be lots of space given to the question of how to inform the user about switching modes (virtual buffer on/off). I believe this is the crux of Rich Schwerdtfeger's comment above; there is a role of "application" which effectively turns off the virtual buffer for that element, so when focus moves to that element, then forms mode is enabled and the screen reader responds like any other application to the keyboard and focus changes, etc.
The question I have is that if this is done automatically, there seems as if there will still be times when one will need to manually enable virtual buffer again to read the page. As in the example given in the article:
If the user tabs into the form and thus the virtual buffer is disabled automatically, then the user does something which causes the table cell to change, how would the system know if/when to re-enable the virtual buffer again so the user can read the table properly? Now, in Firefox we have "caret browsing mode", where the browser actually moves the keyboard focus in response to the arrow keys as well as the tab and shift + tab keys. I've tried this somewhat, but JAWS gets confused by it, or maybe its me being confused by it! -smile- If Aaron or Rich are reading this, then maybe they can comment on how this is supposed to work?
Thanx...
-- Rich
Posted by Rich Caloggero on
[making-ajax-work-with-screen-readers.php#comment14]
We haven't overlooked the role of the document and application in the role taxonomy specification. The work you're doing is great, and we both acknowledge and fully support what you're doing. We're just providing techniques that can be used now (and for the immediate future while you finish your work and user agents catch up) so that users of assistive technology aren't disadvantaged to the extent they currently are when they encounter web applications. We appreciate the problems this causes, and have highlighted them in this article.
Posted by Gez on
[making-ajax-work-with-screen-readers.php#comment15]
Hi Rich, thanks for your comments.
Firstly I concur with what Gez said in his response.
Furthermore I would like to emphasise that one of the main aims of the article is to provide techniques that work with current and earlier versions of screen reading software.
i.e. "techniques for the here and now"
Today I canvassed about a dozen people here at work on what screen readers and versions they use at work and at home. All used JAWS (although I am aware of some window eyes users and a supernova user here at work). The versions ranged from 4.5 to 7. The reasons for this range were varied:
*current work SOE supports version 6.2, but the SOE has not yet been rolled out to all users.
*version 5 for a number of people who use JAWS , because the later version(s) are currently incompatible with the Braille device they use.
*for some users at home they had not upgraded due to cost.
This adhoc survey indicates that there is a range of constraints on people having access to the latest version of screen reading software. So techniques that provide improved accessibility for current screen reader users are going to be useful for some time.
Best regards
Steve
Posted by Steve Faulkner on
[making-ajax-work-with-screen-readers.php#comment16]
>one of the main aims of
the article is to provide techniques that work with current and earlier versions of screen reading software. i.e. "techniques for the here and now" Today
Yes. However, I've been playing around a bit more with Jaws and both IE and Firefox, and I'm not sure there are ways of making older versions of Jaws do the right thing when dealing with many of these Ajax "use cases".
PPK has a nice article on his blog at quirkmode.org which summarizes the most common user-centric Ajax use cases. The brief summary is as follows:
<blockquote>
1. Sending data to the server; note that a response is not really necessary.
2. Automatically refreshing data; note that from an interaction perspective there is no request since the user doesn't take action.
3. Moving around tiny bits of text.
4. Fetching "new pages" from the server; fundamentally there is no difference with an old-fashioned Web 1.0 site, although Ajax conveys a few subtle benefits.
</blockquote>
Let's consider 2 and 3 above. Use case 2 is more or less akin to a ticker, or some sort of dynamic feed which is updated at random (at least with respect to the client). Data is grabbed whenever it is ready and pushed into the page. There is no way that I can find to make this reliably "show up" on the page without doing a jaws refresh (i.e. actively polling for it).
Note: I need to test this, but there might be a total kludge possible if we ensure that the element being added to the DOM is an anchor. If we make our data show up on the page wrapped inside an anchor tag, then Jaws may dynamically announce it. You could wrap the data in an anchor tag, attach it to the page, set focus to the anchor, then after a certain amount of time, change the element to whatever you really wish it to be (this might simply mean unwrapping the anchor tag and reattaching the node. However, this is kind of rediculous, and I'm sure won't be very visually appealing. Plus, I'm not sure it'll work; I'll try it and comment here again on my findings.
The only way I know of for sure to present the Jaws user with truly dynamic asynchronous data is to use alert(), which is clearly not the right thing in most cases. However, if we are willing to have an option setting somewhere in the aplication which says something like: "enable alert() - useful for screen reader users", then perhaps this might be acceptable?
I believe case 3 above is very similar to case 2. I believe he was thinking about apps like Google suggest and chats. I don't see reliable ways of doing this stuff using today's screen reader technology; you really got to know when the DOM changes. IE doesn't fire this event, and the screen readers don't listen to this event in Firefox.
-- Rich Caloggero
Posted by Rich Caloggero on
[making-ajax-work-with-screen-readers.php#comment17]
Check out 508 compliant Ajax framework Bindows.
Posted by Johan Lund on