Browser Augmentation

Vicki L. Hanson,1 John T. Richards2 and Cal Swart3

1 IBM T. J. Watson Research Center, vlh@us.ibm.com2 IBM T. J. Watson Research Center, ajtr@us.ibm.com3 IBM T. J. Watson Research Center, cals@us.ibm.com

Abstract. In this chapter we examine ways of programmatically expanding the functionality of conventional browsers. We consider various mechanisms for creating extensions and add-ons in Internet Explorer and Firefox, and briefly review other browsers. We explore some ex -isting browser extensions. The focus is on accessibility extensions, but some prominent other examples of browser extensions are also mentioned. Information for using and creating vari-ous types of extensions is presented. Finally, the usefulness of browser extensions compared with other accessibility enablement options for the Web is considered.

1 Introduction

There are many ways to achieve the goal of an accessible Web, as discussed through-out this book. Directly authoring accessible Web pages is one way (see Part 2 - Evaluation and Methodologies). Transcoding, changing already created Web pages to make them more accessible, is another (see Part 3 Chapter 5). In addition, browsers themselves have built-in features to adjust some aspects of page presenta-tion to make the content more accessible (see Part 3 Chapter 2). Most browsers also provide extension mechanisms that allow developers to augment browser functional-ity. Such augmentation allows for the creation of a number of accessibility features.

Talking browsers are probably the best known form of browser augmentation for accessibility. These browsers allow blind, dyslexic, or otherwise print-disabled users to hear the content of a Web page read aloud. Early versions of this technology (Asakawa and Itoh 1998; Zajicek, Powell and Reeves 1998) have largely been sup-

2 Hanson, Richards, and Swart

planted by talking browser options included in conventional browsers (see Fire Vox1; Opera2) or by all purpose screen readers such as JAWS®3 or Window-Eyes4.

In this chapter we will examine the issue of browser augmentation for adding functionality to make Web pages more usable by people with limited sensory, motor, or cognitive abilities. We begin by giving some examples of enhanced accessibility features based on browser augmentation and then look at some of the augmentation techniques available in current browsers, focusing primarily on Internet Explorer™ (IE) and Mozilla Firefox.

2 Overview

The World Wide Web Consortium (W3C)5 is committed to an accessible Web. To accomplish this goal, the Web Accessibility Initiative6 was created. A three part ap-proach to Web accessibility has been taken by this group. The first, which arguably receives the most attention, is the Web Content Accessibility Guidelines (WCAG)7

for markup languages to be used for authoring accessible content. The second, the Authoring tool Accessibility Guidelines, addresses authoring tools for generating markup. The third, of most relevance to the present discussion, is the User Agent Accessibility Guidelines (UAAG)8 for Web browsers.

WCAG guidelines prescribe how websites can be authored so that the content on the site meets specific accessibility requirements. These guidelines alone, however, often fall short of providing the kinds of page renderings needed by many users. Specifically, they may not address the need to unclutter a page or provide for legible fonts -- particularly when the definition of ‘legible’ is very subjective. What the guidelines can do, however, is provide mechanisms for the type of flexibility needed by browsers to implement these individual choices (Hanson, Snow-Weaver and Trewin 2006).

The fact is, no one page rendering will be accessible to all users. While WCAG has been able to specify, for example, markup needed to make pages accessible to screen readers, it is not possible to specify one page rendering that will be able to be easily readable by everyone with vision impairments. Thus, there is the need for in-dividual users to be able to indicate the optimal rendering for themselves. In this

1 http://www.firevox.clcworld.net/2 http://www.opera.com/products/desktop/voice/3 http://www.freedomscientific.com/fs_products/JAWS_HQ.asp4 http://www.gwmicro.com/Window-Eyes/5 http://www.w3.org6 http://www.w3.org/WAI 7 http://www.w3.org/WAI/intro/wcag.php 8 http://www.w3.org/WAI/intro/uaag.php

Browser Augmentation 3

sense the UAAG and browser extensions / add-ons provide for flexible rendering of pages, customized to individual users.

Modern browsers have incorporated several useful accessibility features (see Part 3 Chapter 2 - Desktop Browsers). These features generally include font enlarge-ment (at least over a small range of sizes), text, link and background color modifica-tions to enhance contrast or suit the preferences typical of users with some forms of dyslexia, and whole page magnification (zooming).

These features, while having the advantage of being built-in, do not include the full complement of adaptations that a disabled user might want or need. To satisfy these more diverse requirements, developers can create new functions and integrate these extensions within the browser. While all major browsers support extensions, they do so in very different ways. In this section, we will examine current browser extension mechanisms and specific accessibility uses of these extensions.

3 Browser Extension Mechanisms

Each of the modern browsers has their own mechanism for extending functionality. We will begin by discussing extension mechanisms provided by Internet Explorer (IE), and will then continue to Firefox, Safari, and Opera.

3.1 Internet Explorer

A number of mechanisms exist for augmenting the functionality of IE (Roberts 1999). They include custom style sheets and various program objects that are bound to the browser. The mechanisms to be discussed here work for IE 5 and above.

Style Sheets

A potentially simple mechanism to modify all Web pages rendered in IE is to use a custom style sheet. Style sheets can become quite complex, modifying many aspects of a browser’s rendering. In general, though, style sheets provide a simpler means of making changes than creating new program objects; style sheets can be cre-ated with nothing but a text editor and require no compilation or build procedure. Once created, a style sheet can be loaded by using the Accessibility dialog, available on the Tools menu, under Internet Options.

A more sophisticated use of the IE style sheet mechanism is to create style sheets under program control and inject them into IE. This technique is used by our Web Adaptation Technology software to combine several separately specified prefer-ences into a single style sheet (Richards and Hanson 2004). Style sheets in this soft-ware allow for combinations of page magnification, line spacing, and letter spacing.

4 Hanson, Richards, and Swart

Browser Objects

More sophisticated techniques for adding functionality to IE involve the creation of additional program objects that are bound to the browser, effectively adding new programmed behaviors. Examples of these program objects include Browser Helper Objects (BHOs), Band Objects, and ActiveX controls.

Many BHOs can be found for IE. An example of a commonly available BHO that enhances IE for purposes other than accessibility is provided by Adobe. Their BHO adds the ability to convert a Web page to a PDF document with a single click. This BHO is added to IE when Adobe Acrobattm is installed.

In general, bands package a set of new features with an associated user interface. Like BHOs, band objects can listen to browser events if they register themselves to do so (an example of this is given below). Bands generally have a richer user inter -face than BHOs although a BHO may occasionally pop up dialogs to interact with the user.

Our Web Adaptation Technology software uses a band to provide the control in-terface for selecting accessibility preferences (Richards and Hanson 2004). The band, shown in Figure 1, features large buttons allowing for easy viewing and click-ing. Preferences are organized by type and grouped within simple panels. The full functionality of this band is revealed in a series of panels that allow users to control a number of options for page rendering and mouse and keyboard operation. Users can select the panels by clicking the large left and right arrows on the left hand side. Help for the current panel can be obtained by clicking the large ? button. This band and a BHO together provide the new accessibility features in our software; the band allows the user to set their preferences and the BHO modifies the content based on those preferences as pages are loaded. In this software, examples of its use include reading text aloud via IBM’s ViaVoice™, enlarging text, changing colors of page el-ements, and reformatting the page layout to one column.

This software uses a Browser Helper Object (BHO), written in Visual J++, to make various modifications to the browser’s Document Object Model (DOM) after it is built by the browser but before the content is displayed on the screen. Unlike the user style sheet mechanism reviewed above, this BHO has the ability to make a wider range of modifications (e.g., modifying element attributes based on a poten-tially complex analysis of nearby elements). In addition to programmatic access to the DOM, a BHO has the ability to respond to user events (such as user mouse movements over a document). This ability allows the Web Adaptation Technology BHO to respond to mouse hover events to read the underlying text aloud (a hover be-ing defined as the user moving the mouse over a non-empty region of the page and then pausing). A BHO can also respond to general browser events (such as the events related to fetching a new page).

Browser Augmentation 5

Figure 1. A screenshot from the Web Adaptation Technology showing the band with one of its panels, speak text, visible.

The interactions between the browser and the band can get rather elaborate. Again, consider our Web Adaptation Technology. The help content for this software is provided by a collection of Web pages. An example of the help for speak text is shown in Figure 2. Links to the other software functions (such as magnify, text size, banner text, etc) are shown on the help links on the left hand navigation bar. Click-ing on one of these links causes the associated page to be loaded. Because the band has registered an interest in browser navigation events it gets control each time a page is loaded. It examines the url for the new page and, if it is for one of the help pages, switches its panel so that it corresponds to that page. In this way we can keep the band’s interface and the help content in synchronization allowing the help to reli-ably refer to visible band elements. Similarly, if help is being viewed, a click on the left or right band buttons causes the corresponding help page to be loaded by the browser.

6 Hanson, Richards, and Swart

Figure 2. Help content and band panels synchronized in the Web Adaptation Technology Help system through the handling of browser navigation events.

ActiveX objects are arguably the most complex of the objects that can be bound to the IE browser. A rather large example of an ActiveX object is the Java runtime support. ActiveX objects in general are COM applications that are registered with the browser and loaded with each instance. They are distributed as Windows Dy-namic Link Libraries (DLLs). These DLLs can be created by programming in C++, Visual Basic, ATL, and C# using the Microsoft Visual Studio development environ-ment9. Other frequently used ActiveX objects include Quicktime and Flash objects.

9 Unfortunately, although many add-ons are harmless, malware writers have used these techniques to spread spyware and monitor browser activity. Users need to be

Browser Augmentation 7

For accessibility, Muta, Ohko and Yoshinaga (2005) created an ActiveX component that can be utilized by website owners to provide features for visitors to their website who have vision limitations.

3.2 Mozilla Firefox

The Firefox browser was designed to be easily extended. Indeed the browser it-self is largely written using the same mechanisms an extension developer would use. As an open source browser, this extensibility provides obvious advantages. In this section we review some of the ways to add new capabilities to Firefox.

Extensions

The Firefox Accessibility Extension10 is one well known extension. It provides for a number of features that allow for easier navigation of elements of a Web page as well as changing some elements of page presentation for users with vision impair-ments. It also provides validation tools for developers to check their pages for ac-cessibility best practices.

Consistent with the general extensibility of Firefox, Mozilla (the underlying platform) provides a fairly self-contained application development and deployment platform.  Applications written for this platform, including browser extensions, run on all the systems on which Mozilla runs (including Windows, Linux, and Mac).  This means that most of the code an application extension developer would create only needs to be written once.

Extensions are created in the XML User Interface Language (XUL), JavaScript, HTML, and CSS. A simple text editor can be used to create these extensions. Alter-natively a sophisticated development environment like Eclipse can be used. There are many tutorials on the Web for learning how to start programming an extension. Searching for “developing Firefox extensions” will return many hits.

The XUL feature of this platform permits the runtime assembly of complex user interfaces. From XUL, one can call JavaScript functions to accomplish other tasks, such as initialization, event handling, and DOM manipulation. The overlay feature of XUL also permits changes to the browser UI, such as menus and toolbars (elements called the chrome in Mozilla terminology).

Our Firefox accessibility software, accessibilityWorks (Hanson et al. 2005), uses XUL as the means of building the panels corresponding to the IE band discussed pre-viously. Several features of XUL made this task particularly easy. XUL supports

aware of the add-ons that are installed. These can be managed from IE by selecting Manage Add-Ons on the Tools menu.10 http://firefox.cita.uiuc.edu/index.php

8 Hanson, Richards, and Swart

rapid, iterative development of GUIs. Since there is no compilation and build step, changes can be immediately tested. And since we can register for Firefox events we can trigger such things as DOM manipulation at page load time.

The Cross-Platform Component Object Model (XPCOM) is another feature of the Mozilla environment that allows developers to perform lower-level tasks that cannot be done in XUL or JavaScript. Mozilla has a large variety of XPCOM objects that can be instantiated from JavaScript. These objects allow preferences to be re-trieved and set, and files to be read and written. Developers can also write their own XPCOM objects. In accessibilityWorks, we created an XPCOM to connect our soft-ware to text-to-speech engines such as IBM’s ViaVoicetm.

In general, Firefox extensions have access to all of the Firefox user interface and components. Extensions can modify the user interface by adding buttons, toolbars, and menus. They can modify fonts and colors, capture events, and change Web pages before the user sees them. Extensions have access to the Firefox XPCOM li-brary for low-level functionality. Extensions are only limited by the developer’s imagination.

Style Sheets

Unlike IE, there has not been a way for users to add a style sheet to Firefox via a simple browser option. However, users can edit userContent.css and userChrome.css which reside in the user’s Firefox profile chrome directory (see User CSS11). Exten-sions can register stylesheet URIs as additional user and UA style sheets using the style sheet service available in Firefox 1.5 and later (see Using the Stylesheet Ser-vice12). A relatively simple extension could be built with this mechanism to allow users to easily create and inject style sheets.

Themes

Firefox also provides a mechanism for users to customize the look and feel of the browser – a mechanism not available in IE. Many existing themes and informa-tion about how to develop new themes are available on the Mozilla website (see Firefox Themes13; Developing Themes14).

Plugins

11 http://www.mozilla.org/unix/customizing.html#usercss12 http://developer.mozilla.org/en/docs/Using_the_Stylesheet_Service13 https://addons.mozilla.org/firefox/themes/14 http://developer.mozilla.org/en/docs/Themes

Browser Augmentation 9

Firefox also provides a mechanism for users to embed content in a page. Typical examples of this are Quicktime and Macromedia Flash. These are developed using the Netscape plugin SDK and an environment that supports C/C++ and Makefiles. Microsoft Visual Studio would be one such environment. See http://www.mozil-la.org/projects/plugins/

3.3 Other Browsers

Safaritm

Apple’s Safari browser is primarily extended by way of plug-ins. There are many plug-ins currently available. Pimp my Safari15 is a particularly good source of Safari plug-ins.

Apple provides the Web Kit framework for developing plug-ins. This frame-work supports two types of plug-ins: Web Kit-based architecture and the Netscape plug-in architecture. Your choice of framework would depend on your target plat-form(s). Netscape style plug-ins support a standard API and can be supported in mul-tiple browsers and can be deployed on cross-platform systems such as Windows and Linux. The Web Kit-based framework plugins can only be deployed on Mac OS-X applications that support the Web Kit framework. Netscape style plugins are written in a cross-platform C API while Web Kit plugins are written using an Objective-C API. Web Kit-based plugins can also take advantage of Cocoa classes (see About Plugins16).

Apple provides two excellent resources for developing Safari plug-ins. These are available in the Apple developer area (see WebKit Plug-in Programming Topcs17; WebKit Objective-C Programming Guide18). There are samples of both in the Web Kit developer section. Developers would most likely use Apple’s XCode Tool suite to develop extensions.

Safari also supports custom style sheets to modify web pages. Just specify the style sheet to load in the Safari->Preferences->Advanced dialog.

15 http://pimpmysafari.com/16http://developer.apple.com/documentation/InternetWeb/Conceptual/WebKit_Plug - inProgTopic/Concepts/AboutPlugins.html#//apple_ref/doc/uid/30001248-20651817http://devworld.apple.com/documentation/InternetWeb/Conceptual/WebKit_Plug - inProgTopic/WebKit_PluginProgTopic.pdf18http://devworld.apple.com/documentation/Cocoa/Conceptual/ DisplayWebContent/WebKit_DisplayWebContent.pdf

10 Hanson, Richards, and Swart

Operatm

The Opera browser provides a number of extension mechanisms. Style sheets and/or JavaScript files can be invoked on every page load. A style sheet can be se-lected for the browser by using the Style option available from Tools menu, Prefer-ences->Advanced->Content->Style. Style sheets operate in a similar manner to IE discussed above (see Opera Style Sheets19).

User JavaScript allows the full range of JavaScript functionality. For example, events can be handled, and cookies can be read. In addition, scripts on a loaded page can be rewritten, overriding a page’s event handlers, and changing variables and functions used by the page (see User JavaScript20). A JavaScript file can be selected for the browser by using the JavaScript available from the Tools menu, Prefer-ences->Advanced->Content->JavaScript.

Opera also supports add-ons through plug-ins. Plug-ins add additional capability to the browser. Opera has standard plugins for objects such as Adobe Acrobat, Flash, Quicktime and Java applets (see Opera plugins21). Opera supports the Net-scape4 plugin API. This means that Opera may support any Netscape compatible plug-in. Developers can use the standard Netscape Software Development Kit. By developing to a standard API, the plugin can run in multiple browsers. Developers can use a variety of environments to develop Opera plugins, such as MS Windows Visual Studio, and essentially any environment that supports C/C++ and Makefiles.

3.4 Impact of Browser Implementation Details

Seemingly trivial differences in browser implementations can result in surpris-ingly large differences in the ease of creating efficient browser extensions. Consider, for example, one of the DOM transformations we have created for both IE and Fire-fox as part of our Web Adaptation Technology and accessibilityWorks software men-tioned earlier. In our page layout transformation, we radically restructure the DOM so that multicolumn content is ‘linearized’ to be a single column. From the user’s point of view this has the advantage of eliminating the need for horizontal scrolling when very large text enlargements are applied to the page. In Figure 3 we show a Web page with text enlargement using accessibilityWorks. In Figure 4 we show that same page with the same text enlargement after the one column transformation has been applied.

19 http://www.opera.com/support/tutorials/stylesheets/ 20 http://www.opera.com/support/tutorials/userjs/21 http://www.opera.com/docs/plugins/

Browser Augmentation 11

In IE we coded a relatively efficient BHO in Java to perform this DOM-based linearization. In Firefox we created a comparable function using JavaScript. One might guess that the Java implementation would be considerably faster given that Java will typically run much faster than interpreted JavaScript. However, the Java implementation needed to invoke API calls to traverse and modify the DOM and those APIs were invoked by way of a COM interface. The JavaScript implementa-tion on the other hand was interpreted within the same computational context as the

Figure 3. A page with substantial text enlargement prior to linearization.

12 Hanson, Richards, and Swart

Figure 4. The same page as in Figure 3, but with page linearization.

rest of the Firefox browser (an attribute that results from the fact that extensions to Firefox are comparable in nearly all respects to native browser functions), leading to faster overall performance for the linearization.

Another example of the impact of browser implementation choices on extension feasibility is provided by a comparison of the ease of implementing the event han-dling underlying text-to-speech triggering. Our user interaction model for speaking text aloud involves, among other things, the ability for the user to simply move the mouse to an area of interest and then pause. This hover starts the playback of text from a reasonable starting point in the underlying block of text. Moving the mouse outside this area of text is a way to stop the speech playback and, perhaps, start play-back on another area of text.

Browser Augmentation 13

In order to implement this interaction model we need to augment the DOM by adding SPANs to break up large blocks of text into sensible chunks for possible playback. Without SPANs we would always start from the top of the current text node (which could be quite far from the user’s point of interest). Having inserted SPANs, we then need to attach event handlers to deal with mouse events of interest.

In Firefox we attach an event handler to the top level BODY element and any FRAME or IFRAME elements. In IE we were forced to attach event handlers to ev-ery node that supports them and in which we have an interest, typically most nodes in the DOM. This more costly DOM augmentation is required because the IE event object does not contain a pointer to the DOM element that initially received the event. Firefox’s event object does contain such a pointer so we can deal with the event at the high level node that has our handler attached. Specifically, we can initi-ate speech playback for just the text in that node.

4 Future Directions

It should be clear by now that browsers are not merely stand-alone applications but platforms for the creation of new functionality through browser extensions. As noted previously, no single browser, unmodified, provides all the features desired by every user. The types of browser augmentations described in this chapter enable new features to be added to browsers.

While we have focused on browser technology, Web content and applications no longer need to be tied to the browser. Browser engines are being used in standalone applications that can run on the desktop. For example, XULRunner uses the Gecko engine to build standalone desktop applications that have all the richness of the Web. Widgets, such as those of Opera and Yahoo, provide another option. Opera, for ex-ample, uses their rendering engine in their widget technology to provide desktop widget applications.

Given the need for an accessible Web, one might think that browsers would evolve over time to incorporate all needed accessibility options into the browser it-self, thus obviating the need for accessibility extensions. While it is true that many of the options needed by users are available in modern browsers, the needed options are not completely available in existing browsers. Moreover, the seemingly in-evitable complexity of browser interfaces tends to hide features, making accessibility features available only to experienced users or users supported by sophisticated sup-port personnel. Many older and disabled users, however, are neither experienced nor well supported. They are not likely to discover accessibility features buried in complex browser interfaces. Sa-nga-ngam and Kurniawan (2007) found, for exam-ple, that items hidden in menus were extremely difficult for older adults to find. In comparing users performing tasks with IE7 and Firefox 2.0, they found longer times

14 Hanson, Richards, and Swart

and fewer successful task completions for these users when features were hidden in menus. The streamlined default IE7 install that hides much function, therefore, was more difficult to use than Firefox 2.0 for these older adults. Although not tested with younger users, it is likely that the results obtained by Sa-nga-ngam and Kurniawan for older adults would generalize to many other users as well, whether disabled or not.

We suspect that even if found on toolbars or within menus, some accessibility features are simply too complex to either understand or set (e.g., having to manually configure a suitably contrasting combination of text foreground, text background, link, visited link, and hover colors). For users with disabilities, moreover, the con-sequences of not knowing what to do can be significant, ranging from inefficient browser use to just giving up on using the resources of the Web. The point here is that even when browsers include all needed accessibility features they may not ex-pose them in a manner easily used by those who need them (see Trewin 2000). For that reason, various accessibility browser augmentations necessarily repackage func-tionality, such as color changes, already included in the browser itself (see, for exam-ple, Firefox Accessibility Extension22; Hanson et al. 2005; Muta et al. 2005).

5 Our Opinion of the Field

We have argued previously that the economics of content development will con-tinue to favor an approach based on automatic content transformation (generally browser-based transformations) rather than an approach which presumes that new more accessible content will be created (Richards and Hanson 2004). This is based on consideration of a few facts. The cost of creating accessible Web content can be substantial, especially so if developers have to go back and re-work legacy content. Moreover, the economic incentive to address the needs of what is perceived to be a small segment of the market has suggested to website owners that website accessibil-ity will not translate into large financial gains. The W3C and others have pointed to the benefits of accessible websites23, but it is only recently that some website owners have reported financial benefits of such development that outweigh the costs (Sloan 2006). As we’ve discussed here, however, an ‘accessible’ website, as defined by meeting these guidelines, may not be accessible to the many users whose needs fall outside those encompassed in content guidelines. In these cases, other approaches must be used. Some of this is handled by the User Agent Accessibility Guidelines. In other cases, browser augmentation is important.

Depending on specific requirements, browser extensions can have advantages for accessibility transformations over other technologies. Transcoding using a proxy

22 http://firefox.cita.uiuc.edu/index.php23 http://www.w3.org/WAI/EO/Drafts/bcase/Overview

Browser Augmentation 15

server is another method of re-writing Web pages to be accessible (see Part 3 Chap-ter 5). In our earlier work with proxy servers, however, we found that we were un-able to meet our users’ requirements using this approach. Three specific areas of dif-ficulty were identified (Hanson and Richards 2004). First, the proxy server often made transcoding errors or omissions – hardly surprising given the complexity of the task that browsers face (rendering complex and often malformed HTML, JavaScript, cascading style sheets, and a large and growing number of third-party plug-ins). Also different browsers would render things differently which was hard to anticipate on the server. Second, secure sites transmitted content to the browser in an encrypted form. A proxy cannot see and modify the content flowing through a Secure Sockets Layer (SSL) connection unless that connection is mediated by a pair of SSL sockets at the proxy itself. Through this mechanism it is possible to see and modify the con-tent on the proxy. Performing such an operation, however, violates the end to end se-curity expected of secure connections and can only occur if the user proceeds after being warned of a serious security violation. Third, there was often a problem in simply enabling a connection to the proxy server. In order to set a browser to go through a proxy, the HTTP proxy must be set on the browser itself. This is not al-ways possible since proxies cannot be cascaded. Thus, users who had a proxy al-ready set, such as for some corporate firewalls and some ISPs (e.g., AOL), are pre-vented from connecting to a remote proxy. In addition to these three overarching is-sues, proxies also pose potential copyright problems since they transform and serve content not owned by the proxy’s owners. Also, transcoding poses the general prob-lem of scalability in production systems as so much content needs to not only flow through them be non-trivially transformed as it flows.

Of course, browser extensions are not without their downsides. The largest of these is the requirement that users download and install some software. For experi-enced computer users, this may not be a problem. For inexperienced users, how-ever, even seemingly simple downloads and installations can be daunting.

6 Conclusions

Browser extensions can provide important added functionality for browsers. Whether this mechanism or another option will provide the best means of accom-plishing a task will depend on the project goals.

We’ve covered here some of the accessibility extensions that have been devel-oped. Given the open computing environment currently enjoyed, it can be antici-pated that many other such extensions will be developed and made available to the accessibility community.

16 Hanson, Richards, and Swart

References

Asakawa, C. and Itoh, T. (1998). User interface of a Home Page Reader. In Proceed-ings of the Third International ACM Conference on Assistive Technologies (Ma-rina del Rey, California, United States, April 15 - 17, 1998). Assets '98. ACM Press, New York, NY, 149-156.

Hanson, V. L., Brezin, J., Crayne, S., Keates, S., Kjeldsen, R., Richards, J. T., Swart, C., & Trewin, S. (2005). Improving Web accessibility through an en-hanced open-source browser. IBM Systems Journal, 44 (3), 573 - 588.

Hanson, V. L., & Richards, J. T. (2004). A Web Accessibility Service: An Update and Findings. Proceedings of the Sixth International ACM Conference on Assis-tive Technologies, ASSETS 2004. New York, NY: ACM. Pp 169-176.

Hanson, V. L., Snow-Weaver, A., & Trewin, S. (2006). Software personalization to meet the needs of older adults. Gerontechnology, 5 (3), 160-169

Muta, H., Ohko, T., & Yoshinaga, H. (2005). An activeX-based accessibility solu-tion for senior citizens. Proceedings of the Center On Disabilities Technology And Persons With Disabilities Conference 2005. Available at http://www.c-sun.edu/cod/conf/2005/proceedings/2227.htm

Roberts, S. (1999) Exploring Microsoft Internet Explorer 5. Microsoft Press: Red-mond, WA.

Richards, J. T & Hanson, V. L. (2004). Web accessibility: A broader view. In Pro-ceedings of the Thirteenth International ACM World Wide Web Conference, WWW2004. Pp. 72 – 79.

Sa-nga-ngam, P. & Kurniawan, S. (2007). An investigation of older persons' browser usage. Proceedings of HCI International - Universal Access in HCI, Volume 5. Beijing, China. July 22 – 27, 2007. Springer.

Sloan, D. (2006). The Effectiveness of the Web Accessibility Audit as a Motivational and Educational Tool in Inclusive Web Design. Ph.D. Thesis, University of Dundee, Scotland. June, 2006.

Trewin, S. Configuration agents, control and privacy, in Proceedings of CUU'00 (Ar-lington, VA, November, 2000), ACM Press, 9-16.

Zajicek, M., Powell, C., and Reeves, C. (1998). A Web navigation tool for the blind. In Proceedings of the Third international ACM Conference on Assistive Tech-nologies (Marina del Rey, California, United States, April 15 - 17, 1998). Assets '98. ACM Press, New York, NY, 204-206.

Browser Augmentation 17

Index

ActiveX, 4, 7add-ons, 1, 3, 7, 10Band, 4BHO, 4, 5, 11Browser extensions, 1–15DOM, 5, 8, 11, 12, 13Linux, 8, 9proxy, 15Style Sheets, 3, 8, 10Talking browsers, 1Transcoding, 1, 15User Agent Accessibility Guidelines, 2, 15WCAG, 2, 3XPCOM, 8XUL, 8