The move to Web-2.0 coincides with the move from a web of documents to a web of applications — where Web Applications are in turn built out of web parts see Toward 2^W — Beyond Web-2.0. Web Applications were now significantly easier to build — one no longer needed to build such applications as browser plugins
Leveraging The Web Browser For Accessibility
At the end of 2002, I attended a Mozilla Developer Day where I saw what would could be done within the browser using HTML, XUL, CSS and XBL. Alphabet soup aside, the combination of these technologies created the potential for writing powerful Web applications without resorting to custom plugins and platform-specific C or C++ code. I spent a few weeks at the end of that year on building TalkZilla — speech extension for Mozilla, but gave up after failing to successfully implement Text-To-Speech within the platform using XPCom in the 2 weeks I had alloted myself. But in the process, it became evident that sooner or later, it would become possible to build the next generation of access technologies purely within the browser.
Fire Vox — A Talking Extension for Firefox
In fall of 2005, I moved on from my work on W3C XForms and revisited the possibility of building access technology in to the browser when I started at Google. This time around, I decided to expose the Text-To-Speech layer as a local HTTP server, and accessed the service using XML HTTP Request in Firefox — the layer that had been hard to build in 2002 was now implementable in under a day. I began seriously exploring the browser-based accessibility solution route once again, and coincidentally discovered Charles Chen's work on Fire Vox. As it turned out, he had done the rest of the work — using platform-specific speech services such as SAPI, he had created a Firefox extension that not only provided spoken access to the document-oriented Web-1.0 — his work demonstrated the power of browser-based access technologies by delivering the first implementation of W3C ARIA within Firefox 1.5.
Web Applications And Spoken Access
In fall of 2007, Charles joined Google, and we began exploring the next phase in browser-based access. One thing that became apparent from the Fire Vox experience, as well as what we had all learnt from different screenreaders was that at the end of the day, one needed application-specific scripts to enhance the base-level spoken access provided by the screenreader. Traditionally, screenreaders implement such application-specific extensions in a screenreader specific scripting language — as we investigated implementing access technologies out of Web Technologies, we created a framework for application-specific scripting in JavaScript. This led to the AxsJAX project, where we implemented a framework for scripting Web Applications within Firefox to produce context-specific spoken feedback via the user's screenreader.
From Greasemonkey To Chrome Extensions
By the end of 2008, we felt we had learnt all we could from the AxsJAX project. The AxsJAX project leveraged the Greasemonkey extension in Firefox to add application-specific scripting implemented in JavaScript. The creator of Greasemonkey by then had started implementing the Chrome extension framework — Chrome extensions draw heavily from the Greasemonkey experience. With Chrome beginning to provide an increasingly viable platform for creating Web Applications out of pure Web technologies (HTML, Javascript and CSS), we started leveraging this platform for building a complete access solution authored using Web technologies.
Exposing Platform Services To Web Applications
Chrome extensions are written in HTML, CSS and Javascript. These extensions get full access to the Document Object Model (DOM) of the pages being viewed. This meant that we could implement a large portion of the access solution in pure JavaScript. What's more, as a Web Application, implementing access to dynamic Web pages proves no harder than providing access to static content — thus, we were able to implement ARIA support from the very beginning of the project.
However, not everything on a platform can be implemented via JavaScript (at least not yet). Today, Text-To-Speech is still implemented in native code, but see speech synthesis in your browser from Mozilla for the shape of things to come. In addition, in the case of ChromeOS, some parts of the user interface were being implemented using the underlying windowing toolkit. For our ChromeVox solution on Chrome OS, we exposed these to the Javascript layer via extension APIs — with those APIs in place, we could then implement ChromeVox entirely in JavaScript.
Conclusion: And The Best Is Yet To Come!
As the Web platform continues to evolve, with the Web browser able to access an ever-increasing of platform-specific services that are in turn exposed to Web Applications via JavaScript, we are only beginning to scratch the surface with respect to what can be built in the space of web-based access technologies.
