Download part-3-chapter-2 - School of Computer Science

Desktop Browser
Jon Gunderson. Ph.D.
University of Illinois at Urbana/Champaign, Disability Resources and Educational Resources,
[email protected]
Abstract. Web browsers play an important role in the accessibility of the Web by people with
disabilities. The features that Web browsers provide to control the rendering of content, navigate and orient to document structure, and control the automatic behaviors will determine the
types of accessibility techniques Web authors can use to make their resources more accessible
and the level of usability that will be available to people with disabilities in accessing Web
resources. Web browsers play a critical role in accessibility as Web 2.0 widgets created out of
HTML, CSS and Javascripting by supporting new W3C technologies to make Web applications more accessible.
1 Introduction
Browsers are the window to the world of Web resources and the accessibility features of browsers have a big impact on how people with disabilities can view and
access Web content, and how Web developers design Web resources to be accessible. For example, consider the U.S. Federal Government Section 508 requirement
1194.22 (o) “A method shall be provided that permits users to skip repetitive navigation links.” The purpose of this requirement is to allow screen reader users to easily
move the reading cursor to the main content of a Web resource without having to
listen to navigation links at the beginning of many Web resources. Most navigation
bars are at the beginning of the document forcing speech users and other keyboard
only users to tab through navigation, advertising and secondary side bar links as they
search for the main content of a Web page. The Section 508 1194.22 (o) requires
authors to provide a means for users to skip directly to the main content, although
there is no specific technique required. Most Web developers implement this feature
by using an internal “skip navigation” link at the beginning of the page, since popular Web browsers like Internet Explorer and Firefox do not have one simple feature
that would have made this approach unthinkable, would increase the support for Web
standards and lead to even higher levels of accessibility for people with disabilities.
2
Jon Gunderson
If Web browsers implement a keyboard shortcut to navigate headers (“h1-h6”) there
would have been a much better Section 508 requirement of “Use headers to indicate
document structure and the location of navigation bars”. Everybody including developers and people with disabilities would benefit from this requirement. Users
with disabilities benefit since they can easily skip over navigation bars to get to main
topics, but they can also easily find all the main, sub topics and navigation bars on
the page. Web developers benefit since it encourages them to use a Web standards
approach to Web design which reduces the resources needed to create and maintain
Web resources. All users benefit as Web developers use Web standards since this
naturally leads to Web resources with consistent graphical renderings making it
easier for users to find and locate information as they browse the Website. The features of Web browsers to support Web standards like structured navigation and user
style sheets play an important role in determining how people with disabilities can
access the Web and the techniques available to Web developers to implement accessibility standards.
1.1 Testing for Functional Web Accessibility
Authors have a responsibility to create accessible content, but it is not very well
understood the role browsers have in providing the options to Web developers to
make content more accessible. The W3C User Agent Accessibility Guidelines (Jacobs, Gunderson and Hansen 2002) provide a detailed list of requirements, including
header navigation, for browsers to support accessibility by people disabilities. The
United States Federal Section 508 Software Accessibility requirements apply to Web
browsers, but they do not have the specific requirements of the W3C User Agent
Accessibility Guidelines for software designed to render resources from the Web.
The introductory example in this chapter illustrates the impact browsers have on how
people with disabilities can access the Web and how they support Web developers in
creating accessible content through the use of Web standards. The following sections of this chapter will explore the ways browsers support accessibility and the
implications of these features for people with disabilities, people without disabilities
and Web developers.
One of the major roles browsers can play in the development of accessible Web
resources is to provide a way for Web developers to functionally test Web resources
for accessibility. The following test procedures are based on the iCITA Web Accessibility Best Practices (Gunderson 2007) to implement Section 508 and W3C Web
Content Accessibility Guidelines (Vanderheiden, Jacobs and Chisholm 1999). Numerous authors have published books on accessible Web design based on the limitations of current browser technology place on Web accessibility techniques, these
books include: Web Accessibility for People with Disabilities (Pacillo 2000), Accessibility for Everybody (Mueller 2003) and Web Accessibility: Web Standards and
Regulatory Compliance (Thatcher et. al. 2006). Ideally if browsers had more builtin support for Web accessibility there would really be no difference between Web
standards based design and accessible design, which would make Web accessibility
principles much more understandable and reasonable to most Web developers. But
the lack of built-in accessibility features in popular browsers force Web developers
Desktop Browser
3
to use special markup techniques that are unique to disability access and are usually
unfamiliar to most Web developers which leads to accessibility features that are
incomplete and ineffective. Special accessibility techniques sustain the myths that
accessibility features only benefit people with disabilities and the idea that “text
only” Web pages are the preferred means of people with disabilities accessing Web
resources. I hope that this chapter will help dispel some of these myths and how
browser extensions and assistive technologies are helping to transform accessibility
techniques to the ideal of the use of Web standards.
1.2 Keyboard Testing
Many people with disabilities can only use the keyboard to navigate links, form
controls and other elements that respond to user interaction on a Web resource. The
ability to use the interface with only the keyboard is becoming even more important
as dynamic user interface controls are introduced in Web 2.0 Web applications (van
der Vlist 2006).
Links:
Check to make sure users can navigate to all links using
only keyboard commands. Check to make sure link text
is unique and that the link text indicates the target of the
link.
Headings:
Check to make sure that headers are used to indicate all
major and minor topics using only keyboard commands.
Event Handlers:
Make sure all interactive features implemented through
scripting can be achieved using the keyboard alone.
1.3 Styling
Interoperability is at the heart of Web standards (Berners-Lee et al, 1994) and is a
major reason why Web standard based designs are more accessible to people with
disabilities. Web standards (Zeldman 2003) based designs provide all users with the
capabilities to restyle Web content to meet their own perceptual needs or supports
the rendering capabilities of a wide range of range of Web browsing technology,
including desktop graphical browsers, speech browsers, refreshable Braille renderings, personal digital assistants (PDAs) and cell phone technologies. People with
disabilities use a wider range of Web browsing technologies than the able-bodied
population and they have much more specific rendering requirements. For example,
a person with a visual impairment may want a high contrast rendering of white characters on a black background. This can be accomplished through assistive technologies though screen magnifiers like Zoom Text from AISquared or Magic from Freedom Scientific, but it can also be done with Web standards when authors use CSS to
style their Web resources and browsers support overriding author styles and allowing
users to supply their own stylesheet.
The original premise of the Web was for Web developers to write a Web resource once and have a wide variety of people and technologies be able to access and
4
Jon Gunderson
use the resource. Using Cascading Style Sheet (CSS) technology (Lie and Bos 2005)
to style content is an important part of supporting interoperability. People with disabilities often need to change font sizes, font families, and/or the foreground and
background colors used in rendering text to make information more perceivable to
them. In the same way the resolutions of graphic displays are becoming more diverse and becoming less predictable to Web developers. Web developers commonly
design Web pages to particular resolutions (i.e. 800x600, 1024x800, 1280x1024, ..)
so resources will “look the same” to all users. But as resolutions of monitors change
this design technique results in renderings that are too small on some monitors and
too large on other monitors. Using CSS relative size values allows Web resources to
automatically adjust to the resolution of a monitor, maximizing the use of the available graphical real estate from 180px wide PDAs to 4000px high definition monitors.
The same techniques to allow Web resources to automatically adapt to varying resolutions of graphical monitors are the same techniques to make Web pages easier for
people with disabilities to restyle content to meet their own perceptual needs. People
with visual acuity problems like farsightedness may need to increase the font size of
a rendered resource to be able to read the text on the screen. Using relative CSS
units allows Web pages to reflow when people use browser text zoom features to
increase the default font size.
Browser features play an important role in allowing developers to test their Web
resources to adapt to the styling needs of users and supporting different resolution
monitors. If web resources support interoperability they should reflow to fill the
resolution of the graphical window and not require the user to use the horizontal
scroll bar to view content or have wide areas of empty white space. Many browsers
do not make it easy for authors to make these adjustments or do not support the adjustments at all. When popular browsers do not make it easy for users and developers to adjust the rendering of Web content it reinforces developers design model of
using fixed width pixel based designs which are less usable to people with disabilities. The following are browser features which support testing for functional accessibility:
Font size:
Increasing and decreasing the font size should result in
content reflowing to fit the current window width without
the user having to use horizontal scrolling to view
content.
Window width:
As the width of the graphical window is increased and
decreased content should reflow to fit the current window
width without the user having to use horizontal scrolling
to view content.
Author Styling:
When author defined style sheets and in-line styling are
disabled, content should still be usable. This is the
ultimate test for interoperability with speech and Braille
technologies since all author supplied graphical
formatting is removed. If the author was using any
graphical formatting or spatial layout to indicate
Desktop Browser
5
relationships this would become evident when author
style information is removed.
User Styling:
A little known part of W3C CSS specifications (Bos et. al.
2007) is the concept of user style sheets, which provides a
means for users to apply their own styling preferences to
Web resources. Even when browsers support user style
sheets they usually hide this feature from users by making
it difficult for them to define and associate the user style
sheet with the rendering of the content. Browsers like
Opera have a number of built-in author style sheets for
high contrast styling and styling renderings to emulate
text browsers. The built-in user style sheets in Opera
make it easy for the developer to test the interoperability
of their design with a wide variety of device rendering
capabilities and user preferences, including the
preferences of people with disabilities.
1.4 Text Descriptions and Conditional Content
Images and other embedded objects need text equivalents to allow people with disabilities to access the content of the image or at least to understand the purpose of the
image in the Web resource. Text equivalents are just one type of content that is
referred to in the W3C User Agent Accessibility Guidelines (Jacobs et. al. 2002) as
conditional content, since browsers may render this content given a certain set of
conditions including user action and settings (i.e. hover mouse over element with a
TITLE attribute to create a tooltip) or configuration of the browser (i.e. substitute
ALT text rendering instead of image rendering). The W3C HTML 4.01 specification
conditional content includes the TITLE attribute which can be used to provide information on the purpose of frames or additional information about a link or form
control. The following are examples of conditional content in HTML 4.01.
ALT attribute:
Configure the browser to turn off images and enable the
rendering of ALT attribute content in place of the image
and check to make sure the alt content represents the
content of the image.
OBJECT element:
Configure browser to turn off embedded objects and
enable the rendering of text content of the OBJECT and
check to make sure the equivalent acurately indicates the
purpose of the object.
TITLE attribute:
Check the content of the title attributes to see if they
provide useful supplemental information about the link,
form control or frame element.
LABEL element:
Labels for form controls are important for speech
renderings to be able to prompt users when a form control
6
Jon Gunderson
gets keyboard focus. Proper labeling of form controls are
difficult for developers to verify since the use of labels in
graphical browsers results in no change in rendering and
only subtle changes in behavior for checkbox and radio
button form controls.
LANG attribute:
HTML 4.01 allows authors to define the default language
and changes in language of a Web resouce. Using this
markup in graphical browsers does little to change the
rendering of content since the language is represented by
a character and character set information. But like labels
this information is critical for speech renderings since
speech needs this information to change the language
spoken by the speech synthesizer.
1.5 Browser Impact on Accessibility
Browsers have a tremendous impact on the techniques used by Web developers to
create Web resources and the expectations of users on how content will be provided
to them. Developers will not use features if browsers don't support the markup by
providing access to additional content, styling or navigation features. A classic example is the LONGDESC attribute in HTML 4.01. Access to the LONGDESC content was not implemented for many years by many browsers and is still not available
in major browsers like Microsoft Internet Explorer through the graphical user interface. The lack of support reduced authors resulted in both a lower awareness of the
potential capabilities of the LONGDESC attribute and a lack of interest in including
content that cannot be accessed by popular browsers. Another example is font scaling or zooming, developers won't support and users will not explore the possibilities
of liquid Web design if browsers don't support scaling text content. The view of
most Web developers is that current popular accessibility techniques only benefit
users with disabilities (i.e. skip navigation link, alt text for images and labels for
form controls). This is for two primary reasons, the first is the limitation in browser
features to support Web standards forcing many Web developers to work around and
away from a Web standards based approach to Web design. If accessibility techniques seem to only benefit users with disabilities, this will reinforce the negative
stereotypes of accessibility techniques being obscure, a burden to implement and not
a benefit to all users. The second is developers often cannot test an accessibility
technique like using headers (h1-h6) to indicate major and minor sections with in a
Web resource with the built-in features of browser, so they often don't use them or
apply them incorrectly. Many developers use headings for styling purposes (big or
small font) rather than for indicating the structure of a web resource. The next section of this chapter will look at the implementation of browser features that support
accessibility and how these features can enhance the browsing experience of all
users.
Desktop Browser
7
2 Built-in Features for Accessibility
The built-in features for accessibility are important to promote accessible design
techniques based on Web standards. Web developers, able-bodied users and users
with disabilities all need to benefit from using Web standards based approaches to
accessible Web design and in large part this will only be possible through the functionality provided by the Web browser.
2.1 Keyboard Overview
Keyboard support is the most basic accessibility feature of any software application
and is the first checkpoint in the W3C User Agent Accessibility Guidelines 1.0 and
part of the Section 508 Software requirements. Keyboard support is needed by people with disabilities who cannot use pointing devices like the mouse and other people
with disabilities who use alternative input devices (Anson 1997) need keyboard
support to map there alternative input device to activate the functions of an application. For example, someone using voice recognition can say “Next Link” and the
voice recognition program can emulate the TAB key press to move to the next link in
a Web resource.
Windows
Macintosh
Unix
IE 7.0
Firefox
2.0
Opera
9.1
Safari 2.0
Ctrl+O
Ctrl+L
F2
Cmd+L
Ctrl+L
History Back
Alt+Left
Arrow
Alt+Left
Arrow
Alt+Left
Arrow
Cmd+[
Cmd+Left
Arrow
History Forward
Alt+Right Alt+Right Alt+Right
Arrow
Arrow
Arrow
Cmd+]
Cmd+Right Cmd+Right Alt+Right Alt+Right
Arrow
Arrow
Arrow
Arrow
Open Location
Firefox 2.0 Opera 9.1
Firefox
2.0
Opera
9.1
F2
Ctrl+L
F2
Cmd+Left
Arrow
Alt+Left
Arrow
Alt+Left
Arrow
History List
Ctrl+H
Ctrl+H
Alt+Z,
Alt+X
-
Cmd+H
Cmd+H
Ctrl+H
Ctrl+H
Bookmarks/Favorites
Ctrl+I
Ctrl+I
Ctrl+F2
-
Cmd+I
Cmd+F2
Ctrl+I
Ctrl+F2
Add
Bookmark/Favorite
Ctrl+D
Ctrl+D
Ctrl+D
Cmd+Shift+D
Cmd+D
Cmd+D
Ctrl+D
Ctrl+D
Table 1: Selected Built-in Keyboard Shortcuts for Browser Page Navigation
2.2 Keyboard Shortcuts
Table 1 shows keyboard support for selected browser functions that allow users to
move between Web pages and support for the common inter-page navigation in
graphical desktop browsers. One of the the main features is to support the built-in
8
Jon Gunderson
keyboard accessibility features of the operating system, all the major operating system have features to support keyboard access. Table 2 shows keyboard support for
navigation of content within a Web page and there are significant differences between desktop browsers. The Opera browser clearly has many more built-in keyboard functions to navigate page content, including headernavigation, directional
link navigation. Header navigation provides an important feature to navigate the
structural content for keyboard only users and makes it easier for people with visual
impairments to find the main content of a Web resource. Header navigation can
significantly reduce the number of keystrokes for a user to select a link or form control. Consider Web resources with a large number of links, the basic sequential link
navigation most browsers support using the TAB key is a tedious and time consuming process. But if headers are used and the browser supports header navigation the
user can turn a 40-50 key sequence into 4-5 keys. Directional navigation supported
by Opera (Shift+arrow keys) provides another means to use the keyboard to move
more directly to a link of interest if you can see the spatial relationships between
links. Firefox has a type ahead feature to make it easier for keyboard users to navigate to links by moving keyboard focus to the links that start with the letters the user
is typing. This is very useful for a page the user is familiar with, since the user may
know the text of the link they want to select.
Desktop Browser
Windows
Next
Link
Macintosh
IE 7.0
Firefox 2.0
Opera
9.0
Tab
Tab
A
Tab
Shift+Tab
Q
Previous Shift+Tab
Link
Safari 2.0 Firefox 2.0
9
Unix
Opera
9.0
Firefox 2.0
Opera
9.0
Tab
A
Tab
A
Shift+Tab
Shift+Tab
Q
Shift+Tab
Q
Yes
-
Yes
-
Cmd+J
-
Ctrl+J
Link
type
ahead
-
Yes
-
-
List of
Links
-
-
Ctrl+J
-
Link Up
-
-
Shift+ ↑
-
-
Shift+ ↑
-
Shift+ ↑
Link
Down
-
-
Shift+↓
-
-
Shift+↓
-
Shift+↓
Link
Left
-
-
Shift+←
-
-
Shift+←
-
Shift+←
Link
Right
-
-
Shift+→
-
-
Shift+→
-
Shift+→
Next
Form
Tab
Tab
Tab
Tab
Tab
Tab
Tab
Tab
Previous Shift+Tab
Form
Shift+Tab Shift+Tab Shift+Tab
Shift+Tab Shift+Tab Shift+Tab Shift+Tab
Next
Heading
-
-
W
-
-
W
-
W
Previous
Heading
-
-
S
-
-
S
-
S
Find
Ctrl+F
Ctrl+F
Ctrl+F
Cmd+F
Ctrl+F
Ctrl+F
Ctrl+F
Ctrl+F
Find
Next
-
Ctrl+G
Ctrl+G
Cmd+G
Ctrl+G
Ctrl+G
Ctrl+G
Ctrl+G
Toggle
Images
-
-
Shift+I
-
-
Shift+I
-
Shift+I
User
Style
Sheets
-
-
Shift+G
-
-
Shift+G
-
Shift+G
Ctrl+Plus
Ctrl+Plus
Plus
Cmd+Plus
Ctrl+Plus
Plus
Ctrl+Plus
Plus
Minus
Cmd+
Minus
Ctrl+Minus
Minus
Ctrl+Minus
Minus
Zoom In
Zoom
Out
Ctrl+Minus Ctrl+Minus
Table 2: Keyboard Shortcuts for Web Content Navigation and Stylin2.3 Accesskeys
10
Jon Gunderson
The discussion of browser keyboard accessibility would not be complete with out a
discussion of accesskeys. The HTML 4.01 specification defines an accesskey attribute for links and form controls using a character to identify the shortcut key. The
purpose is to allow authors to create their own keyboard shortcuts for users to activate links or move focus to a form control. One of the goals of accesskeys is to help
people with disabilities by providing them with additional keyboard shortcuts to
frequently used links and form controls on a web resource. For example,
ACCESSKEY=“S” could be used to move keyboard focus to the text search box
within a Website of ACCESSKEY=”M” could move focus to the main content.
There a number of issues that impeded the widespread use of accesskeys. Internet
Explorer 4.0 was the first browser to implement the accesskey feature and implemented moveing focus to links and form controls using the ALT modifier key +
character. Unfortunately the ALT modifier is also used for shortcuts within the
windows operating system, so this lead to conflicts between Web page accesskeys
and operating system shortcut keys. For example ALT+F opens the file menu in
most windows applications, so if a author used accesskey=”F” in a Web resource the
accesskey would either be ignored or override the operating system shortcut. The
ALT key is also used by many assistive technologies for keyboard shortcuts, including screen readers, compounding the confusion even more. Other issues include
notifying the user which access keys are defined in a Web resource. There is little
guidance in the HTML 4.01 specification about how users should learn about the
availability of accesskeys or the keyboard combinations to implement the feature.
Therefore it is up to the author to provide the user with information about the available accesskeys. But even providing this information is problematic since accesskeys
are not implemented the same on all major browsers (see table 3). Firefox implements accesskeys but will follow a link rather than just moving focus to the link like
Internet Explorer 4.0+ does. Opera requires a 2 key sequence to activate accesskeys,
first press key combination of control+ESCape and then the accesskey character.
The Opera technique eliminated the keyboard conflicts of using the ALT key, but
again it is different than Internt Explorer and Firefox confusing both developers and
users on implementing accesskeys. Opera was late to implement accesskeys on the
grounds that it did not internationalize very well, since the author could define a
character that is not on a users keyboard. So there are many issues with including
accesskeys on Web resources to improve accessibility and with the current eclectic
implementation most Web developers avoid their use. There are some situations
where accesskeys can be useful for example if someone needed to fill out or modify
a Web form on a regular basis, accesskeys on frequently used or strategically placed
form fields can be very useful to all users and people with disabilities.
Desktop Browser
Activation Key Link Behavior
Internet
Explorer 4.0+
11
Form Control
Behavior
ALT+Character Move keyboard Move keyboard
focus to link, no focus to form
activation of
control
link
Mozilla/Firefox ALT+Character Activate link
associated with
1.0+
accesskey
Move keyboard
focus to form
control
Shift+ESCape,
Character
Activate link
associated with
accesskey
Move keyboard
focus to form
control
-
-
-
Opera 7.0+
Safari 1.0
Table 3: Accesskey implementation on popular browsers
2.4 Styling Content
People with visual impairments and some types of learning disabilities often need to
restyle content to meet their visual perception and processing needs. This includes
changing font size, font family and colors used to render text, and the ability to linearize content (remove table markup) to make it easier to for people with visual impairments and visual processing learning disabilities to read the content of Web
resources. For users to easily restyle content requires authors to use Web standards
based relative CSS values for styling content and browser to support user style sheets
for users to modify the rendering to meet their own perceptual needs. Users need to
be able to configure browsers to ignore author supplied styling information and apply their own style sheet or direct the browser to use operating system settings for
text color and font characteristics. Illustration 2 shows configuring Internet Explorer
to ignore some author supplied styling. Internet Explorer requires configuration of
several dialog boxes for the user to set their own style preferences and then going
through the same set of dialog boxes to restore authoring styling. Opera on the other
hand makes it very simple for user to switch between author styling and user styling
preferences. Menu options and keyboard shortcuts (Illustration 3) make it easy for
user to switch between author and user styling modes. The Opera approach is very
useful to Web developers since they can easy check how their Web resources will
render with when the authors styling is removed and the styling of the user or device
is applied (i.e. PDA, cell phone and text browser). The same techniques to make
content adaptable to the needs of people with disabilities are the same techniques
needed to make content adaptable to a wide variety of portable and desktop
12
Jon Gunderson
Illustration 1: Internet Explorer configured for high contrast through accessibility dialog box
settings
Illustration 2: Opera browser in high contrast mode through menu options
Desktop Browser
13
technologies. With the release of Internet Explorer 7.0 all of the popular desktop
graphical browsers support scaling of text (see Table 2). Yet even here there are
differences. Opera and Firefox zoom features support content reflow to fit the window width and Internet Explorer zoom feature maintains the layout forcing horizontal scrolling when the layout exceeds the width of the window. Horizontal scrolling
to read content is an annoyance to most users and can make reading web resources
by people with disabilities a very difficult process.
2.5 Images
The IMG and AREA elements are the primary techniques to include images in Web
resources. Both elements include the ALT attribute and the IMG element includes
an additional LONGDESC attribute. There are many issues with browsers providing
access to the text equivalents for images and Table 4 provides a summary of the text
description rendering capabilities of major browsers. The typical way browsers
provide access to text equivalents for IMG elements is to replace the rendered image
with the ALT text content. One of the issues with the rendering of ALT text is the
ability of the user to access all of the ALT attribute content and the ability to style
the text rendering of the ALT content. Many browsers clip the text to the size of the
original image which results in most of the ALT content being cut off from rendering. The other issue is styling of the ALT attribute content when it is rendered.
Most browsers offer only limited styling capability, so even if the user is able to
view all of the ALT attribute content they may not be able to make the text large
enough to read. The only major browser to support access to the LONGDESC attribute URL for the IMG element is Mozilla/Firefox browser. Users must move the
pointing device to the image and open the context sensitive menu using the right
click feature of the mouse in Microsoft Windows. None of the major browsers provide access to the ALT attribute for content for AREA element, essentially requiring
the author to provide redundant text links for any links associated with server or
client side image maps.
14
Jon Gunderson
ALT attribute
for IMG
element
LONGDESC
attribute
ALT attribute Style ALT text
for AREA
rendering
Internet
Explorer 7.0
Render in place
of image
-
-
Limited ability
to scale size
Firefox 2.0
Render in place
of image
Context menu
-
Full
Opera 9.1
Render in place
of image
-
-
Full
Safari
Render in place
of image
-
-
Table 4: Summary of Text Description rendering for major browsers
Illustration 3: Internet Explorer 7 turning off display of images requires going through a series
of dialog boxes
Desktop Browser
15
Illustration 4: Opera Browser toggling between images on and off through a menu option
2.6 Conditional Content
There are a number of other types of conditional content that are useful for accessibility like the TITLE attribute, which can be used on almost all HTML elements. The
TITLE attribute is used as a “tool tip” in Internet Explorer and Firefox for elements.
A tool tip displays the TITLE attribute content in little window near the mouse
pointer when the user hovers the mouse pointer over the element with a TITLE attribute defined. Other types of conditional content are not rendered by graphical
browsers at all. For example the TITLE element can be used to indicate the purpose
of a FRAME within a FRAMESET, but graphical browsers currently do not provide
a mechanism to render the TITLE attribute content of the FRAME. Without this
feature Web authors cannot easily check to see if their FRAME titles are meaningful.
2.7 Scripting
In the early years of the Web scripting was difficult for Web developers to integrate
into Web resources due to the inconsistencies and changes in the scripting languages
and document object models used by Netscape Navigator and Internet Explorer.
Scripting was typically used for decorative purposes like image roll over effects for
links that are styled using images. The W3C Web Content Accessibility Guidelines
1.0 reflected the relative unimportance of scripting at the time the recommendations
were published in 1999 by requiring Web pages to be functional when scripting is
disabled or the browser does not support scripting. The Web is much different to-
16
Jon Gunderson
day, the standardization of javascript, the widespread implementation of the W3C
Document Object Model (Champion et. al. 2000) and XMLHttpRequest have created
an environment where developers are creating Web widgets with the same capabilities as those found in Graphical User Interfaces (GUIs) on desktop operating systems. Scripting accessibility is no longer an option but a necessity and browsers
have a significant role in making dynamic content accessible. The following sections deal with simpler scripting accessibility issues found on static Web resources
and the accessibility issues of Web applications will be discussed in a later section.
2.8 Device Independence and Event Handlers
One of the most important features of script based interaction within Web pages is
the ability to support the keyboard. HTML specifications have separate event handlers for mouse and keyboard events.
Event Handlers Triggered by Mouse Events:
 onClick
 onMouseDown
 onMouseUp
 onMouseOver
 onMouseMove
 onMouseOut
Event Handlers Triggered by Keyboard Events
 onClick
 onFocus
 onBlur
 onKeypress
 onKeydown
 onKeyup
For developers to support both the keyboard and the mouse they must use multiple event handlers. Some event handlers like the onClick event already support
device independence by responding to both mouse pointer events (left click) and
keyboard events (Enter key press when element has focus). Other types of user
event handling require pairing of mouse and keyboard event handlers, for example
onMouseOver and onMouseOut event handlers must also have corresponding onFocus and onBlur event handlers. Many developers do not understand accessibility
requirements of supporting the keyboard and therefore do not include the onFocus
and onBlur event handlers. Other types of event handlers cause keyboard accessibility problems just by using them, notably the use of the onChange event handler with
the SELECT form input element to move to a new web page identified by the options in the select box. The onChange event is triggered when the user moves keyboard focus to a select element using the TAB key and then tries to use the Up and
Down arrow keys to view the options in the select box. The use of the arrow keys
Desktop Browser
17
triggers the onChange event handler and the user is then moved to a new Web page.
This abrupt change in Web page is very disorienting to visually impaired users who
thought they were just going to explore the options associated with the SELECT
control and physically impaired users who cannot actually get to the other options in
the select control. Some browsers have fixed this problem by adding additional
keyboard commands like Control+Up and Control+Down arrow to allow keyboard
users to view the options without triggering the onChange event scripts, but most
users do not know this obscure command. The more users need to know these arcane keyboard commands the less usable the browser is for users with disabilities.
A change is needed in the next generation of event handlers to be more device
independent. Both to improve accessibility to people with disabilities and also to
make it easier for developers to improve the interoperability of the Web resources
they create. Generic event handlers would allow browsers to map keyboard, mouse
or other input devices to the generic event handlers reducing the burden on Web
developers to define event handler lists for a wide range of technologies and every
conceivable device that might be used to interact with Web content. Consider an
example of a web author wanting to provide a context sensitive help system for a set
form controls on a Web resource they are developing. The author wants to provide a
system that allows users to get additional information on each form control through a
“balloon” help system. The information in the balloon changes as the user either
moves keyboard focus to each control or hovers the mouse over a control. This
currently requires two separate sets of event handlers: onMouseOver/onMouseOut
and onFocus/onBlur. If the onFocus and onBlur events were also triggered by
mouse hover events, then the developer could just use the onFocus and onBlur
events to implement the balloon help system.
2.9 Popup Windows
Popup windows have become an annoyance for all users and recent browsers have
added features to block new windows automatically open through javascripts. The
accessibility issues of new windows though are more severe than simple annoyance
for people with disabilities, especially for speech users. Before pop up blocking was
available users would select a link and expect to go to the page described by the link
and end up with focus on an advertising popup window. This is very disorienting to
the speech user since the content is unexpected and the user needs to explore the
page to determine that it is not the target link they were expecting and then they must
navigate through the other opened windows of the browser to find the window with
the primary content, a time consuming and tedious process. Another issue with
popup windows is that authors usually remove the menus and tool bars from the
window and many people with disabilities rely on features in the menu and tool bars
to help them navigate and access content. Users need the ability to override author
preferences to exclude menu bars, just like with author styling information, and
allow users to have menu and tool bars available to them if they want them. Currently no browser supports this type of user configuration. Another aspect of popup
windows is the loss of browsing history. When the user ends up in a pop up window
and become disoriented a natural response is to use the back page feature to go to the
18
Jon Gunderson
previous page. But since the popup is a new window it has no browsing history the
user is stuck on the popup resource. The user should have the ability to include
browser history in any new open window overriding author preferences, so if they
get disoriented they can at least go back to a page they are familiar with. Currently
no browser provides this configuration option to users.
2.10 Embedded Objects
The main problem with any embedded media players, java applets or other objects
with a HTML user interface is the support for keyboard focus. Illustration 5 shows
an image of an embedded media player and currently there is no way to move keyboard focus into and out of embedded player using the browser keyboard commands.
The lack of keyboard support for embedded objects breaks a fundamental accessibility requirement of supporting the keyboard for all operations. There are some techniques that allow keyboard focus to be moved from the HTML content to the embedded object, but once keyboard focus is in the embedded object there is no way for
the object to give the focus back to the HTML content. This places the burden on
the Web developer to find ways to work around this problem. For media players one
technique is to place a link on the page to open the media file in an external media
player which gives the user full access to the media player’s accessibility features
and standard menu controls. The user can move between the media player and the
browser using the operating systems keyboard commands to move between applications, for example ALT-TAB in Microsoft Windows moves users between programs
running.
The other aspect of embedded applications is there lack of accessibility features.
Many do not support keyboard operation even if keyboard focus is give to them, and
users cannot restyle content like they can the HTML part of the page.
Desktop Browser
19
Illustration 5: Imbedded multmedia player in a popup Web page
2.11 Configuration
Configuration by the user of browser rendering and automation options is important
for people with disabilities to configure the browser to meet their interaction preferences. Illustration 6 shows the Presentation Mode options in the Opera browser to
allow the user to choose which styling will be used in author and user rendering
modes. One of the biggest issues in user preferences is portability of user browser
configuration options, especially to public access computer systems in schools, libraries and government offices. The W3C User Agent Accessibility Guidelines has
a requirement for portable user profiles to make it easy for users to apply their preferences to browsers they have not used before. Currently no browser has fully implements the profiles feature.
20
Jon Gunderson
Illustration 6: Opera user and author styling preferences dialog box
3 Extending Browser Functions
There are many features important for accessibility defined in the W3C User
Agent Accessibility Guidelines that are not implemented on popular desktop browsers. Some desktop browsers can be extended to include additional accessibility features. Two of these extensions include the Firefox Accessibility Extension from the
University of Illinois (Illustration 7), AIS Web Accessibility Toolbar for Internet
Explorer from Vision Australia (Illustration 8) and Firevox developed by HCarles
Chen at the University of Texas in Austin. These tool bars provide browser enhancements for testing Web sites for accessibility and providing additional accessibility features for people with disabilities to access Web content.
Desktop Browser
Illustration 7: Firefox Accessibility Extension
Illustration 8: Web Accessibility Toolbar for Internet Explorer
21
22
Jon Gunderson
3.1 Making Conditional Visible
One of the most important features of extensions is to make conditional content and
structural markup that is invisible in the default browser visible to users with disabilities and developers who want to check the functional accessibility features of
their web resources. Conditional content is information that describes relationships
between elements or provides additional information about an element. A common
example of conditional content is the TITLE attribute. Internet explorer displays
TITLE content as a “tooltip”, but many other browsers simply do not provide access
to the TITLE attribute content at all. There are many sources of conditional content
that are important for accessibility, including navigational elements like headings
(H1-h6), LABELs for form controls, text equivalents for images, embedded objects,
frames and scripting information. Extensions can help developers do functional
testing for accessibility much more efficiently and users can access content that
otherwise might be hidden from them to more easily view and navigate Web resources.
3.2 Enhancing Keyboard Support
Browser extensions can provide keyboard shortcut enhancements. For example
heading navigation (h1-h6) is implemented in Opera browser as a built-in keyboard
shortcut, but Internet Explorer, Firefox and Safari do not implement a built-in keyboard shortcut for header navigation. The Firefox Accessibility Extension (Gunderson and Schwerdtfeger 2006) and Firevox provide keyboard enhancements and add a
keyboard shortcut for header navigation to the Firefox browser. Other keyboard
enhancements include shortcuts to toggle between user and author styling preferences or allow users to access and navigate a list of links similar to the keyboard
features built-in to the Opera browser.
3.3 Styling
The Opera browser provides a number of built-in user style sheets and makes it very
easy to switch between user and author styling preferences. This is very important
for people with disabilities to be able to use color and font settings that are most
useful to them and for Web developers to functionally test the ability of their Web
resources to be usable without the authors style sheets enabled and with common
device and user style sheets applied to the content. Desktop browsers like Internet
Explorer, Firefox and Safari have user restyling features but they are incomplete and
difficult for users and developers to find and use. Extensions can simplify this process by making to user style sheets and disabling author styling information easier
for users and developers to apply and restore.
3.4 Other Features
Browser extensions can provide many other features to help Web developers and
people with disabilities access Web content.
Desktop Browser
23
1. Visual impairment simulation
2. Show language markup
3. Show structural content
4. Color contrast tests
5. Speech renderings (firevox)
4 Compatibility with Assistive Technologies
One of the most important features of desktop graphical browsers is their ability to
communicate Web content information and user inputs to assistive technologies.
There are many types of assistive technologies that provide screen enhancements
(larger text and graphics and/or color transformations) for people with low vision or
learning disabilities that affect visual processing, alternative inputs for people with
physical impairments, supplemental speech for people with learning disabilities and
screen readers used by people who are blind. Screen readers provide auditory or
refreshable Braille alternatives to the graphical rendering desktop applications for
people who blind and cannot see the display. Web browsers are just one of many
applications used by screen reader user’s, although browser access is becoming more
important as Web applications displace their desktop counterparts. Microsoft Windows is the dominate operating system used in western countries and starting with
the release of Windows 1995 windows included a technology called Microsoft Active Accessibility (MSAA), which was designed to provide a means for desktop
applications and operating system to communicate with assistive technologies. Until
the release of MSAA developers had to reverse engineer graphical operating system
data structures to figure out what was being drawn on the screen. While MSAA
provides information about what is being drawn on the screen it does not directly
provide information about the html content that generated the graphical rendering.
Information about the Web content is available from the Document Object Model
(DOM) of the browser. The W3C User Agent Accessibility Guidelines requires that
browsers support accessibility APIs and access to the DOM to gather information
about the content rendered for use by alternative speech and refreshable Braille renderings.
4.1 Document Object Model
Document Object Model (DOM) is designed for scripting languages like javascript.
Javascript is used to manipulate the content of a Web resources based on user actions
and other types of events. The DOM has important information that can be used by
assistive technologies to improve navigation, orientation and usability of the alternative user interface by people with disabilities. The DOM provides a standard way for
browsers to improve interoperability and provide a way for assistive technologies to
access the content of Web resources. The main problem with assistive technologies
24
Jon Gunderson
relying solely on the DOM for information is that there are often differences between
the content in the DOM and the content rendered graphically on the screen. The
difference is due to the ability of graphical browsers to repair invalid HTML to provide some type of graphical rendering. Invalid HTML may not have a clean representation in the DOM, making it difficult for assistive technologies to provide a
consistent alternative rendering with the graphical display. For example some information may be displayed graphically, but not read by a screen reader. The parsing within the browser to generate the graphical rendering and for creating the DOM
is usually handled separately. This leads to potential differences between what is
rendered and what is in the DOM. Sometimes content rendered is not represented in
the DOM and other times information in the DOM is not rendered. Therefore assistive technologies need to look at both the DOM and the MSAA information on what
is rendered on the screen, further complicating the job of assistive technologies.
4.2 Accessibility APIs
Microsoft Active Accessibility (MSAA) is the accessibility API for Microsoft windows and is supported by Internet Explorer and Firefox browsers. MSAA provides
the means for browsers (and other windows applications) to communicate information on the rendering of content, user interface controls and user events (mouse
and keyboard) with assistive technologies like screen readers and magnifiers.
MSAA provides information on what is actually rendered by a browser and in combination with information from the DOM assistive technologies can provide a more
robust and usable alternative user interface to the browser for people using assistive
technologies. There are limitations in the current implementation of Microsoft Active Accessibility to represent widgets that commonly appear in Web applications.
IAccesible2 (The Linux Foundation) extends the current MSAA implementation
provided by Microsoft to include support for Web widgets. Microsoft has developed
a new accessibility API to represent a much richer and extendable accessibility API
as part of their .NET technology called UI Automation to represent widgets, although at the time of this writing of this chapter neither assistive technology vendors
or windows application developers have embraced the use of UI Automation to make
applications more accessible. Other operating systems and programming environments have their own accessibility APIs including Sun Java, Apple Macintosh and
Unix GTK/GNOME, see additional resources for more information on these accessibility APIs.
5 Accessible Rich Internet Applications (ARIA)
Browser support for AJAX technologies (Javascripting, Document Object Model
(DOM) and XMLHttpRequest for asynchronous communication) to create desktop
widgets and to asynchronously update the widget on desktop graphical browsers has
raised a new set of accessibility issues for people with disabilities. Web application
developers are using these capabilities to create user interface experiences that mimic
Graphical User Interfaces (GUI) found in desktop operating systems like Microsoft
Windows, Apple Macintosh, Sun Java JRE and Unix GNOME/TDK user interfaces.
Desktop Browser
25
The accessibility issues raised by Web applications include keyboard support and the
ability to provide assistive technologies information on the function and relationships
of Web widgets created out of HTML markup, javascript and CSS. The W3C Web
Accessibility Initiative is developing a set of specifications that allow authors to
provide keyboard support, identify the types of widgets and the states and properties
of widgets.
5.1 TABINDEX and Keyboard Focus
One of the fundamental features of making Web 2.0 widgets accessible is keyboard
support and browsers play the key role in supporting keyboard access to Web 2.0
applications. Traditionally Web browsers have only supported the concept of keyboard focus for anchors and form control elements as defined in the W3C HTML
4.01 Specification. The TAB key (or other keystrokes in the case of the Opera
Browser) is used to move keyboard focus sequentially between anchors and form
control elements and this behavior is implemented in browsers like Opera, Internet
Explorer, Mozilla Firefox and Apple Safari. Web widgets are typically built from
DIV and SPAN elements with javascript event handlers to support user interaction
with the widget features. The DIV and SPAN elements with event handlers are not
included in the default tabbing order like HTML form controls and anchors. When
browsers support the ARIA recommendations Web 2.0 widgets receive keyboard
focus when the author defines a TABINDEX attribute for the element. Setting the
TABINDEX=”0” will allow an element to become part of the default tabbing order
of the resource and setting TABINDEX=”-1” allows an element to receive keyboard
focus but the element is not included in the tabbing order of the Web resource. For
elements with TABINDEX=”-1” receive focus through author defined keyboard
event handlers implemented as a part of the widget scripting and the author can give
these elements focus using the DOM focus property.
5.2 Roles, Properties and States
The ROLE attribute is an important part of the xhtml 2.0 specification and provides a
means to describe the types of Web 2.0 widget that are part of a Web application.
The author can communicate information about widget relationships, properties and
the status by programmatically setting attributes on the html elements. Changes in
the values of the attributes trigger accessibility API events which communicate information about the widget to assistive technologies like screen readers and magnifiers. The following example shows the xhtml 2.0 markup for a simple checkbox control made out of a DIV element and javascript event handlers. The example uses the
“checked” attribute to change the CSS rendering and provide information to assistive
technologies on the current state of the checkbox.
xhtml markup for checkbox example:
<div
class="checkbox"
role="wairole:checkbox"
aaa:checked="false"
26
Jon Gunderson
tabindex="0"
onclick="checkboxOnClickEvent(event)"
onkeypress="checkboxOnKeyPressEvent(event)">
My Checkbox Label
</div>
Javascipt for checkbox example:
/**
* toggleCheckbox is called by event handlers to
* toggle the state of the checkbox
*
* @param ( Checkbox object ) checkbox Checkbox to
*
toggle state
* @return nothing
*/
toggleCheckbox = function( checkbox ) {
if (checkbox.node.getAttributeNS(NS_STATE,"checked") == "true") {
// If the checkbox is currently checked set the state to unchecked
checkbox.node.setAttributeNS(NS_STATE,"checked", "false");
} else {
// If the checkbox is currently unchecked set the state to checked
checkbox.node.setAttributeNS(NS_STATE,"checked", "true");
}
// endif
}
/**
* handleCheckboxGroupKeyDownEvent processes keys associated with
* a radio button group
* @param ( event ) event is the event handler for the event
* @param ( Checkbox object ) checkbox is the Checkbox object that is
the target of the keyboard event
* @return false if keyboard event was used by radio group, else true
*/
handleCheckboxKeyDownEvent = function(event, checkbox) {
switch( event.keyCode ) {
case KEY_SPACE:
toggleCheckbox( checkbox );
event.stopPropagation();
event.preventDefault();
return false;
break;
} // end switch
return true;
}
/**
Desktop Browser
27
* handleCheckboxClickEvent processes pointer click events with in
* the radio group
* @param ( event ) event is the event handler for the event
* @param ( Checkbox object ) checkbox is the Checkbox object that is
the target of the pointer event
* @return false if poiner event was used by radio group, else true
*/
function handleCheckboxClickEvent( event, checkbox ) {
if( checkbox.node == event.target ) {
toggleCheckbox( checkbox );
} // endif
}
CSS for checkbox example:
div.checkbox[*|checked="true"] {
background-repeat: no-repeat;
background-position: left center;
background-image: url('checked.gif');
}
div.checkbox,
div.checkbox[*|checked="false"] {
background-repeat: no-repeat;
background-position: left center;
background-image: url('unchecked.gif');
}
5.3 Accessibility API Support
One of the limitations placed upon the roles and states is the mapping between them
and accessibility APIs. Table 5 is taken from the States and Properties Module for
Accessible Rich Internet Applications and shows the relationship between ARIA
properties and MSAA/ATK accessibility API event messages. Most of the ARIA
properties have corresponding MSAA or ATK mapping, but some do not have direct
mapping like “required” properties. To provide mappings for these properties and
roles the Free Standards Group (FSG) has developed extension to MSAA called
Iaccessible2. IAccessible2 extends the features of MSAA without assistive technology and browser developers needing to implement an entirely new accessibility API
like UI Automation to provide additional information on widgets.
28
Jon Gunderson
States and
Properties
module
User Agent mapping via MSAA
User Agent mapping via ATK
Disabled
MSAA:STATE_SYSTEM_UNAVAI
ATK:ATK_STATE_DISABLED
LABLE
Checked
MSAA:
STATE_SYSTEM_CHECKED
ATK: ATK_STATE_CHECKED
If the hidden property is set to true :
If the hidden property is set to true :
MSAA:STATE_SYSTEM_COLLAP ATK:
SED
ATK_STATE_EXPANDABLE
expanded
If the hidden property is set to false:
If the hidden property is set to
MSAA:STATE_SYSTEM_EXPAND false:
ED
ATK:ATK_STATE_EXPANDED
haspopup
This state should be mapped to true on
Windows systems when an event
ATK: not necessary in ATK
handler has a role of pop-up menu.
because it has multiple actions with
description
MSAA: haspopup
multiselectable
MSAA:STATE_SYSTEM_EXTSEL
ECTABLE
pressed
MSAA:
ATK: ATK_STATE_PRESSED is
STATE_SYSTEM_PRESSED is true
true when checked
when checked.
readonly
MSAA:STATE_SYSTEM_READON ATK:ATK_STATE_READONLY
LY
=inverse of readonly
ATK:ATK_STATE_MULTISELE
CTABLE
MSAA: There is no mapping.
required
User agent must make available
through the [DOM] or a specialized
ATK: There is no mapping.
API.
Note: While optional could be
combined with required this is kept to
be consistent with CSS3 pseudo
classes and [XForms].
selected
MSAA:STATE_SYSTEM_SELECTE
ATK:ATK_STATE_SELECTED
D
unknown
MSAA:mixed
ATK:indeterminate
Value
MSAA: should return the value for
getValue().
ATK: should return this as part of
the AccessibleValue structure.
Table 5: Mapping ARIA Properties to Accessibility API's from Roadmap for Accessible Rich Internet Applications
Desktop Browser
29
6 Conclusions
There is no best or perfect browser that meets the accessibility needs of all people
with disabilities. Each Web browser has it own built-in accessibility features and
compatibility with assistive technology. The more Web browsers that become available the more choices all users will have in finding a browser that will meet their
accessibility needs. I hope that this chapter has helped you learn more about the
importance of browser features in making Web resources more accessible and how
browser features impact the way authors create accessible content. One of the most
important aspects of making the Web more accessible to people with disabilities is
the support of W3C recommendations. The heart of W3C recommendations is the
support for interoperability and interoperability makes it easier for Web developers
to create resources that can be used on a wide range of technologies, including the
technologies used by people with disabilities. Since people with disabilities use a
wider range of Web browsing technologies than the general population to access the
Web resources, the support of Web standards gives them more options and makes it
easier for them to use browser features to adapt Web resources to meet their needs.
It is important for all of us to ask developers of browser and multimedia players to
support web standards and implement features that benefit people with disabilities.
Through our combined voice companies building web browsing technologies will
need to pay more attention to improving accessibility features.
7 Additional Resources
The following section provides links to additional resources to further explore the
technologies and features needed to make Desktop Browsers more accessible to
people with disabilities.
7.1 W3C Recommendations and other Standards
Section 508 Information Technology Accessibility Standards
http://www.access-board.gov/508.htm
W3C User Agent Accessibility Guidelines 1.0
http://www.w3.org/TR/UAAG
iCITA HTML Accessibility Best Practices
http://html.cita.uiuc.edu
W3C Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WCAG
Cascading Style Sheets, level 2 revision 1
http://www.w3.org/TR/CSS21/
HTML 4.01 Specification
http://www.w3.org/TR/HTML4/
30
Jon Gunderson
W3C Document Object Model
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/
Roles for Accessible Rich Internet Applications (ARIA Roles)
http://www.w3.org/TR/aria-role/
States and Properties Module for Accessible Rich Internet Applications (ARIA
States and Properties)
http://www.w3.org/TR/aria-state/
7.2 Accessibility Extensions
Firefox Accessibility Extension
http://firefox.cita.uiuc.edu
AIS Web Accessibility Toolbar
http://www.visionaustralia.org.au/ais/toolbar/
Firevox Speech Browser
http://firevox.clcworld.net/
7.3 Accessibility APIs
Microsoft Active Accessibility for Microsoft Windows
http://www.microsoft.com/enable
IAccessible2 Accessibility API
http://accessibility.freestandards.org/a11yspecs/ia2/docs/html/
UI Automation for Microsoft Windows
http://www.microsoft.com/enable
http://msdn2.microsoft.com/en-us/library/aa286482.aspx
Java Accessibility API and Resources
http://java.sun.com/products/jfc/accessibility/index.jsp
Apple Accessibility API and Resources
http://developer.apple.com/referencelibrary/GettingStarted/GS_Accessibility/
GNOME Accessibility API
http://developer.gnome.org/projects/gap/
Desktop Browser
31
References
Anson, D. (1997) Alternative Computer Access: A Guide to Selection, F. A. Davis
Company, Philadelphia, PA.
Berners-Lee T., Cailliau, R., Luotonen, A., Nielsen, H. F., Secret, A. (1994) "The
World Wide Web", Communications of the ACM, August, pp76 - 82.
Bos, B., Çelik, T., Hickson, I., Lie, H. W. (2007) W3C Cascading Style Sheets Level
2 Revision 1 (CSS 2.1) Specification, http://www.w3.org/TR/CSS21.
Gunderson, J. (Ed) (2007) iCITA Web Accessibility Best Practices,
http://html.cita.uiuc.edu.
Gunderson, J. And Schwerdtfeger, R. (2006) Mozilla/Firefox Accessibility
Extension, Proceedings of the 2006 International Technnology and Persons
with Disabilities Conference.
Jacobs, I., Gunderson, J. and Hansen, E. (Eds.) (2002) W3C User Agent
Accessibility Guidelines, http://www.w3.org/TR/UAAG.
Hakon Wium Lie and Bert Bos (2005) Cascading Style Sheets: Designing for the
Web (3rd Edition), Addison-Wesley Professional, Indianapolis, IN.
Mueller, John P. (2003) Accessibility for Everbody: Understanding the Section 508
Accessibility Requirements, Springer-Verlag, New York.
Pacillo, M. (2000) Web Accessibility for People with Disabilities. CMP Books R&D
Developer Series, Lawrence, KS.
Thatcher, J., Burks, M., Heilmann, C., Hnery, S., Kirkpatrick, A., Lauke, P., Lawson,
B., Regan, B., Rutter, R., Urban, M. And Waddell, C. (2006) Web
Accessibility: Web Standards and Regulatory Compliance, Apress, Berkley,
CA.
van der Vlist, E., Ayers, D., Bruchez, E. and Fawcett, J. (2006) Professional Web
2.0 Programming, Wrox Professional Guides, Wiley, Indianapolis, IN.
Vanderheiden, G., Jacobs, I., Chisholm, W. (Eds.) (1999) W3C Web Content
Accessibility Guidelines, http://www.w3.org/TR/WCAG/.
Zeldman, J. (2003) Designing with Web Standards, New Riders, Berkley, CA.
Champion, M., Nicol, G., Byrne, S., Le Hors, A., Le Hégaret, P., Robie, J., Wood, L.
(2000) Document Object Model (DOM) Level 2 Core Specification, .
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113