Sun Web Application Guidelines - Version 4.0
Sun Web Application Guidelines - Version 4.0
|
|
 Search Guidelines |
 Send Feedback |
 Developers.sun.com
|
How To Use These Guidelines - An Introduction
Appendices > Appendix D
Accessible design allows users with disabilities to use your product. In general, people with visual and motor limitations experience significant barriers with graphical user interfaces (GUIs) because they cannot see the content on the screen, or they cannot manipulate the mouse. Products collectively known as assistive technologies provide alternative control or presentation of the information (or both) with which users interact. For example, a screen reader presents the content of the user interface (UI) to blind users through speech synthesis, a refreshable Braille display, or both.
Broadly speaking, an application is accessible if its UI allows users to customize fonts and colors, and the UI can be controlled or presented (or both) by assistive technologies and a keyboard. For example, applications written with the Swing UI Toolkit are highly accessible because support for the JavaTM Accessibility API (JAAPI) is built into its user interface elements. Swing's UI elements have built-in hooks that allow a screen reader to query them through the JAAPI, and then "read" each element's attributes to the blind user. For example, the hooks make it possible for the user to determine what the name and state of the element with focus is. Similarly to Swing, Web-based applications can utilize HTML's programmatic support for accessibility to enable their content to be accessibly presented through use of the user's browser and assistive technology.
Many users, both with and without disabilities, benefit from accessible design even in the absence of assistive technology. For example, applications that can be operated efficiently from the keyboard (using mnemonics, accelerators, and a logical tab sequence) benefit users who cannot manipulate a mouse. However, they also benefit any users who prefer to use the keyboard for speed. Furthermore, "having a disability" versus "not having a disability" is not a clear distinction. Many people have some temporary or permanent disability, such as repetitive stress injuries, suboptimal near vision, color blindness, and hearing deficits. All of these conditions are present in Sun's user population.
Additional information can be found in 1.4 Resources for Application Designers.
Section 508 of the Federal Rehabilitation Act mandates that all products used by U.S. government agencies must provide "comparable access" for people with disabilities. Virtually all Sun products are sold to the government, so all Sun products must meet Section 508 requirements to maintain and expand sales to this market. In addition to federal agencies, which are required to comply with Section 508 requirements, many state governments and large educational systems are complying voluntarily.
Because Section 508 requirements were designed to allow for progress in technology, the Final Rule listing of the requirements is not an unequivocal functional specification. There is no clear, complete, a priori definition of a GUI that meets the Section 508 standard. In addition to "comparable access," the Final Rule listing includes phrases such as "equivalent facilitation," "fundamental alteration," and "a range of contrast levels," all of which are subject to interpretation. Challenges to particular products, raised by affected individuals, will lead to clarification of the requirements, but only through the lengthy process of addressing such challenges and, potentially, through litigation.
The level of accessibility provided by a product is determined by its development team, as long as the final product meets the requirements of Section 508. In most cases, product support for accessibility can be fit into one of three levels.
Obeying the letter of Section 508 is required, but does not necessarily provide a satisfactory experience for the user. For example, an application with an inaccessible GUI can meet the requirements by providing a command-line interface (CLI) with equivalent or greater functionality. While a CLI may meet the letter of the law, it may be more difficult and time-consuming than the GUI. After all, efficiency of the user is the driving force behind graphical interfaces.
This effort normally results in a better experience for users with disabilities. The improvement largely comes from all users having a common, sharable learning process and working experience. User Friendlier 508 (URL follows) identifies and discusses requirements for a web application to achieve this level, along with helpful external references, including coding guidance. While a Section 508-ready GUI is a better level to aim for, it still doesn't guarantee an interface that is truly usable by people with disabilities.
Whenever feasible, Sun's products should strive to maximize the efficiency of all users. This appendix is a companion piece to User Friendlier 508 and provides additional direction on how to make some common GUI elements delivered by a browser more accessible and usable to the user with a disability.
The World Wide Web Consortium (W3C) has spent many years devising a set of web content accessibility guidelines (WCAG) as part of its Web Accessibility Initiative (WAI). They are available at http://www.w3.org/TR/WCAG10/full-checklist.html.
The WCAG provides guidelines that are separated into three different priority levels. For the most part, Section 508 is a subset of WCAG's set of Priority 1 accessibility guidelines. The WCAG is generally useful to turn to when the application provides a design challenge that isn't covered by this appendix or the User Friendlier 508 web site. Both the WAI guidelines and the guidelines presented here are compatible with Section 508 requirements.
Here are some accessibility tips provided by the World Wide Web Consortium:
It is important to use the HTML tags that most closely represent the desired structure of the page and that the tag structure be consistently used throughout the application. Assistive technologies use this information to determine how the web page should be presented to users. For example:
Screen readers understand the purpose of this markup and know how to present the heading text in a way that notifies the users that a new section has begun. By contrast, section headings could be encoded with the HTML <FONT> and <BR> elements to visually represent the start of a new section however, because improper heading markup is used, the screen reader (and user) won't know if the text presented is regular text or heading text.
Screen readers know how to present list content properly when it sees these HTML elements. In contrast, the HTML <IMG>, <DIV>, and other elements could be used to visually present what looks like a list. However, as with the heading example, the screen reader won't have a programmatically obvious way of knowing when the content being viewed is part of a list.
These are just two possible examples highlighting the importance of using the proper HTML elements when presenting structured content.
Examples of nontext elements include graphics, glyphs, illustrations, and pictures. Regardless of the type of nontext element, always assign an alternate description to it (HTML "ALT" text). Every nontext element needs some sort of alternate description so that the vision-impaired user is able to tell if the information it conveys is important to understanding. Image elements that don't have an alternative description are particularly problematic for vision-impaired users. Their assistive technology, a screen reader, sees the image but can only announce that an unknown image exists. This does not help the user understand the content of the document.
Other guidance to follow for nontext elements is:
A nonessential nontext element, if removed from the content, has no negative impact on the understandability of the rest of the content. One common example of a nonessential element is a bullet graphic that is used in conjunction with a list constructed using the HTML <UL>, <OL>, and <LI> elements.
When a nonsighted or low vision user encounters a form element, he or she must be able to determine the purpose of the element. Form elements that don't include their own visual label attribute should provide a label by adding an HTML <LABEL> element. This visually ties the form element to its label but doesn't do the same programmatically. The result is that the sight-impaired user's assistive technology is unable to accurately determine which label is associated with a specific element. The following guidelines demonstrate how to programmatically associate a label with a form element.
More guidance and examples on how to accessibly code HTML form elements can be found at http://www.access-board.gov/sec508/guide/1194.22.htm#(n). This guidance is compatible with that provided by the W3C.
A common guideline has been to place labels to the left of or above the element it is labeling. This guideline came about to help older screen magnifiers and screen readers that don't recognize the HTML "FOR" attribute on the HTML <LABEL> element. This layout helped the older technologies make more intelligent guesses on which label was naming a given form element. If this label orientation guideline doesn't fit with the desired look and feel of the application, ensure that the design requirement for the look and feel always calls for labels on element classes to be placed consistently in all views of the application.
Content developers frequently group similar page elements together in visual groups. HTML 4.0 provides the elements that allow developers to do so in a programmatically accessible way. Follow these guidelines for grouping these elements together:
Note that the default visual presentation of this element is to draw a box around all the elements in the the group. A style sheet can be used to prevent the drawing of the box.
For usage examples for both these elements, go to http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.10.
Tables can perform two functions in an HTML document: presenting data and specifying page layout. Both are encoded using the same HTML tags, but they have different purposes. Data tables (discussed here) define relationships between the elements they contain. In contrast, layout tables are used solely to arrange items on the screen. For information on layout tables, see D-3.2 Make it Easy to Discern Layout Tables From Data Tables.
Follow these guidelines:
The layout in a web application must be as consistent as possible from page to page. All users have a much easier time learning and using an application that has a consistent presentation, regardless of their experience or disability.
For information on the differences between data tables and layout tables, see D-2.4 How to Encode Data Tables. Follow these guidelines when layout tables are used in an application.
To see the effects of layout tables, set their borders to 10 pixels. This useful test makes the layout tables visible, which simulates how they might appear to users of screen readers.
Application views with multiple frames are defined using <FRAMESET> and related tags. Frames can successfully be used in a manner that meets the requirements of Section 508, but some guidelines must be followed:
The HTML "TITLE" of a frame should denote its purpose, and good examples of frame HTML "TITLE"s include "Table of Contents," "Main Content," and "Masthead Navigation."
Invisible frames are used for various reasons, such as polling a server without causing the entire browser to refresh. HTML "TITLE"s on these frames are important because users working with assistive technologies are likely to "see" each and every frame defined in the <FRAMESET>.
Generally, this guideline means allowing the scrolling or resizing of the frame using the HTML "SCROLLING" attribute, and avoiding the use of the HTML "NORESIZE" attribute. Other issues to address with large text size are discussed in more detail in D-4.3 Accommodate the Use of Larger Font Sizes.
The <NOFRAMES> element and approach was originally introduced to ensure users with browsers or assistive technologies that couldn't parse frames still had access to the content of all frames. Sun products don't need to provide the <NOFRAMES> approach. This is because the user audience for our products has browsers and assistive technologies that can parse frames.
Pop-up windows contain dialog pages and alert messages that appear in addition to the main browser window. In several places in these guidelines, pop-up windows are specified as part of a correct interface. The most notable example is application help.
An example of text that might be entered in the HTML "TITLE" attribute is: "Help Viewer (Opens a New Window)."
All accessibility guidelines, including Section 508, require that web applications respect or inherit the font and color selection that users have set in both their browser and desktop.
This allows users with color sensitivities to change, in a central location, the application's default page colors to color values they can better discern.
This makes it possible for users with limited vision to choose a larger or different font so that they can use the product without needing a separate screen magnifier.
Choose a representative set of pages from the application on which to run this test. Adjust all of the font- and color-related options provided by the browser and desktop. Browsers and desktops place the control panel in a variety of locations, and here are examples of where to look:
Color is a powerful tool, but it must never be used as the sole indicator of the meaning or status of any element. For example, a red bar indicating an error can be used if it is accompanied by additional information, such as an icon with a unique shape or static text.
The following URLs point to helpful information on common types of color blindness and an online color blindness checker.
As web applications become more complex, designing to allow for an enlarged font size becomes more difficult.
Truncation of text and other elements is allowable, provided that the meanings of the elements are maintained and that all functionality is usable.
When the browser does not properly manage fonts that are double the standard size, you must make changes that allow larger fonts to work correctly. Many designs are acceptable, as long as this "double standard size" requirement is met. A common problem occurs when the application uses a navigation frame that does not allow scrollbars. The frame could be made resizable, or empty space could be provided in the frame to accommodate the expanded text.
To determine the standard font size, you must first find all the dialog pages and control panels that affect font specifications. (These panels are the same as those listed in D-4.1 Respect the User's Preference Settings.) Then, set all the font size options to standard settings such as "normal," "medium," "12 points," "12 pixels," or "100%," as appropriate for each option. Once you have set the font size to the standard size, change the document settings by finding the font size options that directly affect the browser, and select a font size that is approximately double the standard size (such as "24" or "Largest").
Style sheets provide the developer and user alike with greater flexibility in the visual presentation of the application. When properly utilized in the application, they allow the developer to define the default look of the application. They also provide the user with a method of changing and fine tuning many more property settings than are available in the browser's property page. This allows a user with a visual impairment to set values that make the application usable for him or her.
Complete this test in conjunction with the tests highlighted in D-4.1 Respect the User's Preference Settings and D-4.3 Accommodate the Use of Larger Font Sizes.
Style sheets provide many features beyond the specification of fonts and colors. These features are implemented differently in different browsers, and they must be used with caution. The choice of style sheet features used in an application is primarily a choice based on which browsers are supported by that application.
Dynamic HTML (DHTML) is a generic term that encompasses any markup that modifies the contents of a browser without contacting the server. The term is not rigorously defined and, in practice, relates only to scripting and layers.
Content generated dynamically in the web page versus being generated by the server is a problem because the new content is transparent to screen readers and smart screen magnifiers. No events are sent out to notify the assistive technology that a change in the page's appearance has occurred.
Web applications are heavily dependent upon scripting, and the only language recommended for use in Sun's products is the JavaScriptTM language. The W3C suggests that scripting be avoided. However, doing so is impossible when you are developing a web-based application. Given the need for such applications, these guidelines help explain how to utilize the JavaScript language in an accessible manner.
The names of these methods are presented to users in the status bars of some browsers and are read aloud to users of screen readers. Because this name is presented to users, it should be considered a public interface and named accordingly.
There are many ways to provide this functionality, and it is not necessary to make every script accessible. For example, the functionality of pop-up menus that appear on a mouseover can be made available as redundant navigation links at the bottom of the page, or by using an onKeyPress() event handler.
More information on developing accessible scripts is provided by the Access Board, the authors of the Section 508 rule, at http://www.access-board.gov/sec508/guide/1194.22.htm#(l).
JavaScript and the Java TM programming language are completely separate entities. Java applets are not covered by these JavaScript requirements.
The use of layers in HTML is becoming more common, but very few accessibility guidelines exist regarding their use.
Technically speaking, servlets and JSPs (Java Server Pages) are not dynamic content. However, they run on the server and send HTML to the browser for display. JSPs and Servlets must be constructed such that the HTML generated by them meets all the requirements specified in Section 508 and this appendix.
Many users cannot use the mouse, so all web applications must be usable solely by using the keyboard.
Utilize the Tab key to perform this test. Verify that the visual indication moves from element to element and is never lost.
The following HTML elements support the HTML "TABINDEX" attribute:
<A>, <AREA>, <BUTTON>, <INPUT>, <OBJECT>, <SELECT>, and <TEXTAREA>.
This URL provides more guidance on how to use the
HTML "TABINDEX" attribute:
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex.
Important differences exist in how effectively web browsers support keyboard navigation. For example, some versions of Netscape don't allow navigation of all links in a page, even if the page is defined using proper HTML markup. Other browsers do not support keyboard navigation of frames very well. If the web application works well with the keyboard in at least one browser, then the application is meeting the keyboard navigation requirements.
Web content frequently includes regions on web pages devoted solely to site navigation, and these regions are frequently called navigation bars. These regions are typically located at the edges of the main content. The methods typically provided for skipping over these regions are to 1) place the navigation links in a separate frame (for example, a table of contents frame) or 2) to provide a link at the beginning of the navigation bar that, when activated, moves the input focus to the first element after the navigation region. Either method is acceptable, as long as it meets the following guidelines.
The application's right and bottom navigation bars don't usually need to provide a skipping method because their content is typically presented by the user's assistive technology after the application's main content has been presented to the user.
Both methods are invisible to the sighted user, take up no screen real estate, and are visible to the user's assistive technology.
"Skip link #1: to navigation tree"
"Skip link #2: to main content"
In general, always identify the location the skip link will jump to after the colon (for example, "to navigation tree", "to form", "to main content").
The product might be unusable by users with disabilities if the documentation isn't accessible. If the documentation isn't accessible, then the application as a whole does not meet the Section 508 requirements.
An application becomes easy to learn for users with disabilities when it includes information such as how to use the application with the keyboard, how to change the colors used by the application, and how to change the font sizes used by the application. Documentation should, at a minimum:
Individual products should fully document their own user interfaces, including keyboard navigation and shortcuts, command-line interfaces, and so on, in the product's documentation. This information can appear in the user guide, online help, man pages, or in any location where it can be easily found.
The documentation must also include any features specifically aimed at supporting users with disabilities. These features must be fully documented and must be located in a separate accessibility chapter or appendix. Examples of this type of information are built-in magnification for low-vision users and enhancements to the product that improve the behavior of a third-party screen reader.
These features must be documented, but it is not necessary to call them out as accessibility features. This is because keyboard commands are utilized by many people who have no serious disability.
See D-5 Style Sheets for more information on the usage of style sheets in an application.
Web page accessibility checkers are designed to test pages from a variety of different accessibility perspectives, such as Section 508, color blindness, and macular degeneration. The checkers of most general usefulness to web content developers are those that evaluate content against Section 508's web requirements and the W3C's accessibility guidelines.
For web page accessibility checking, the tool InFocus is very useful. This tool was chosen over others because it did a better job of evaluating tables and nontext elements than other similar tools. However, as with all accessibility checkers, it has its weaknesses. For example, analysis of JavaScript code is still rudimentary and a certain amount of human follow-up is often necessary to verify a potential problem. It cannot "certify" that a web application meets Section 508 requirements. These weaknesses exist in all web page accessibility checkers because accessibility, like usability, cannot be verified through a fully automated process.
| Privacy Policy | Terms of Use | Trademarks | Copyright 2007 Sun Microsystems, Inc. |