Browser Augmentation
Vicki L. Hanson,1 John T. Richards2 and Cal Swart3
1
2
3
IBM T. J. Watson Research Center, vlh@us.ibm.com
IBM T. J. Watson Research Center, ajtr@us.ibm.com
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 addons in Internet Explorer and Firefox, and briefly review other browsers. We explore some
existing browser extensions. The focus is on accessibility extensions, but some prominent
other examples of browser extensions are also mentioned. Information for using and creating
various 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
throughout 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 presentation to make the content more accessible (see Part 3 Chapter 2). Most browsers also
provide extension mechanisms that allow developers to augment browser functionality. 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 Initiative 6 was created. A three part
approach 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
1
http://www.firevox.clcworld.net/
http://www.opera.com/products/desktop/voice/
3
http://www.freedomscientific.com/fs_products/JAWS_HQ.asp
4
http://www.gwmicro.com/Window-Eyes/
5
http://www.w3.org
6
http://www.w3.org/WAI
7
http://www.w3.org/WAI/intro/wcag.php
8
http://www.w3.org/WAI/intro/uaag.php
2
Browser Augmentation
3
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
individual users to be able to indicate the optimal rendering for themselves. In this
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 enlargement (at least over a small range of sizes), text, link and background color modifications 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
created with nothing but a text editor and require no compilation or build procedure.
4
Hanson, Richards, and Swart
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 preferences into a single style sheet (Richards and Hanson 2004). Style sheets in this
software allow for combinations of page magnification, line spacing, and letter spacing.
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 interface 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 interface for selecting accessibility preferences (Richards and Hanson 2004). The
band, shown in Figure 1, features large buttons allowing for easy viewing and clicking. 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
elements, 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 wid-
Browser Augmentation
5
er range of modifications (e.g., modifying element attributes based on a potentially
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 being
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).
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,
6
Hanson, Richards, and Swart
banner text, etc) are shown on the help links on the left hand navigation bar. Clicking 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
reliably 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.
Figure 2. Help content and band panels synchronized in the Web Adaptation Technology Help
system through the handling of browser navigation events.
Browser Augmentation
7
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 Dynamic Link Libraries (DLLs). These DLLs can be created by programming in C++,
Visual Basic, ATL, and C# using the Microsoft Visual Studio development environment9. Other frequently used ActiveX objects include Quicktime and Flash objects.
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 itself 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 impairments. It also provides validation tools for developers to check their pages for
accessibility best practices.
Consistent with the general extensibility of Firefox, Mozilla (the underlying
platform) provides a fairly self-contained application development and deployment
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
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
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. Alternatively 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
previously. Several features of XUL made this task particularly easy. XUL supports
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 retrieved 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
software 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 library
for low-level functionality. Extensions are only limited by the developer’s imagination.
Browser Augmentation
9
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). Extensions 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 Service12). 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 information about how to develop new themes are available on the Mozilla website (see
Firefox Themes13; Developing Themes14).
Plugins
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.mozilla.org/projects/plugins/
11
http://www.mozilla.org/unix/customizing.html#usercss
http://developer.mozilla.org/en/docs/Using_the_Stylesheet_Service
13
https://addons.mozilla.org/firefox/themes/
14
http://developer.mozilla.org/en/docs/Themes
12
10
Hanson, Richards, and Swart
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 framework 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 platform(s). Netscape style plug-ins support a standard API and can be supported in
multiple 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/
http://developer.apple.com/documentation/InternetWeb/Conceptual/WebKit_Plugi
nProgTopic/Concepts/AboutPlugins.html#//apple_ref/doc/uid/30001248-206518
17
http://devworld.apple.com/documentation/InternetWeb/Conceptual/WebKit_Plugin
ProgTopic/WebKit_PluginProgTopic.pdf
18
http://devworld.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/
WebKit_DisplayWebContent.pdf
16
Browser Augmentation
11
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
selected for the browser by using the Style option available from Tools menu, Preferences->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, Preferences->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 plugins 21 ). Opera supports the
Netscape4 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 surprisingly 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 Firefox as part of our Web Adaptation Technology and accessibilityWorks software mentioned 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
19
http://www.opera.com/support/tutorials/stylesheets/
http://www.opera.com/support/tutorials/userjs/
21
http://www.opera.com/docs/plugins/
20
12
Hanson, Richards, and Swart
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.
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 implementation on the other hand was interpreted within the same computational context as the
Figure 3. A page with substantial text enlargement prior to linearization .
Browser Augmentation
13
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 handling 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
14
Hanson, Richards, and Swart
outside this area of text is a way to stop the speech playback and, perhaps, start playback on another area of text.
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
every 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 initiate 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
example, 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
itself, 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 inevitable complexity of browser interfaces tends to hide features, making accessibility
features available only to experienced users or users supported by sophisticated support personnel. Many older and disabled users, however, are neither experienced
nor well supported. They are not likely to discover accessibility features buried in
Browser Augmentation
15
complex browser interfaces. Sa-nga-ngam and Kurniawan (2007) found, for example, 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
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 consequences 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 expose them in a manner easily used by those who need them (see Trewin 2000). For
that reason, various accessibility browser augmentations necessarily repackage functionality, such as color changes, already included in the browser itself (see, for example, 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 continue 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 accessibility will not translate into large financial gains. The W3C and others have pointed to
22
http://firefox.cita.uiuc.edu/index.php
16
Hanson, Richards, and Swart
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
server is another method of re-writing Web pages to be accessible (see Part 3 Chapter 5). In our earlier work with proxy servers, however, we found that we were unable to meet our users’ requirements using this approach. Three specific areas of
difficulty 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
content on the proxy. Performing such an operation, however, violates the end to end
security 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
always possible since proxies cannot be cascaded. Thus, users who had a proxy already set, such as for some corporate firewalls and some ISPs (e.g., AOL), are prevented from connecting to a remote proxy. In addition to these three overarching
issues, proxies also pose potential copyright problems since they transform and serve
content not owned by the proxy’s owners. Also, transcoding poses the general problem of scalability in production systems as so much content needs to not only flow
through them be non-trivially transformed as it flows.
23
http://www.w3.org/WAI/EO/Drafts/bcase/Overview
Browser Augmentation
17
Of course, browser extensions are not without their downsides. The largest of
these is the requirement that users download and install some software. For experienced computer users, this may not be a problem. For inexperienced users, however, 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 accomplishing a
task will depend on the project goals.
We’ve covered here some of the accessibility extensions that have been developed. Given the open computing environment currently enjoyed, it can be anticipated that many other such extensions will be developed and made available to the
accessibility community.
References
Asakawa, C. and Itoh, T. (1998). User interface of a Home Page Reader.
In Proceedings of the Third International ACM Conference on Assistive Technologies (Marina 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 enhanced 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 Assistive 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 solution for senior citizens. Proceedings of the Center On Disabilities Technology
And Persons With Disabilities Conference 2005. Available at
http://www.csun.edu/cod/conf/2005/proceedings/2227.htm
Roberts, S. (1999) Exploring Microsoft Internet Explorer 5. Microsoft Press: Redmond, WA.
Richards, J. T & Hanson, V. L. (2004). Web accessibility: A broader view. In Proceedings of the Thirteenth International ACM World Wide Web Conference,
WWW2004. Pp. 72 – 79.
18
Hanson, Richards, and Swart
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
(Arlington, 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 Technologies (Marina del Rey, California, United States, April 15 - 17, 1998). Assets
'98. ACM Press, New York, NY, 204-206.
Browser Augmentation
Index
ActiveX, 4, 7
add-ons, 1, 3, 7, 10
Band, 4
BHO, 4, 5, 11
Browser extensions, 1–15
DOM, 5, 8, 11, 12, 13
Linux, 8, 9
proxy, 15
Style Sheets, 3, 8, 10
Talking browsers, 1
Transcoding, 1, 15
User Agent Accessibility Guidelines, 2, 15
WCAG, 2, 3
XPCOM, 8
XUL, 8
19