Desktop Browser
Jon Gunderson. Ph.D.
University of Illinois at Urbana/Champaign, Disability Resources and Educational Resources,
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.
1Introduction
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 usingan 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 supportfor Web standards and lead to even higher levels of accessibility for people with disabilities. 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 optionstoWeb 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 WebAccessibility 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 built-in 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 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.3Styling
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 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 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.4Text 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 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.5Browser 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 authorsresulted 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 useheadings 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.
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.