Skip to main content

2.0 Essential Accessibility Programming Practices

2.0 Essential accessibility programming practices
In this section, you will find a list of specific practices that are essential for making your Java applications accessible.

2.1 Make your application keyboard accessible
Keyboard access is essential to a wide range of disabled users. This section highlights the requirements needed to meet these needs.

2.1.1 Provide keyboard equivalents for all actions
Accessible software includes keyboard equivalents for all actions or functions of the application.

Mouse usage fundamentally depends on visual feedback of the location of the mouse pointer on the screen. The user who is blind depends on the keyboard for navigation. Keyboard navigation is also necessary when program controls, such as the tool bar, menus, or buttons are beyond the visible screen display, and therefore, cannot be accessed with the mouse. Without keyboard access, the application is inaccessible to both sighted and non-sighted users in this situation. Other examples include automated software, test cases, and voice-activated software that navigate the application programmatically simulating keyboard events.


Keyboard Navigation is provided by the JFC. The interfactive user interface components provide a full sets of keyboard bindings. Section 11.1.1 JFC Keyboard Binding contains keyboard assignments for the Java Foundation Classes. that enable mouseless navigation, edit, and control of the components. No special efforts are required of the developer to enable these capabilities. Java programs default to the Java Look and Feel bindings. For Java applications that will run on Windows or a Unix type operating system you may choose to include bindings for Windows or Motif that are provided.

The application should provide pull-down menu equivalents for keyboard inaccessible icon functions (menu, tool, and format bars) and ensure keyboard access to these pull-down menus. Traditional "usable" software ensures that these alternatives are provided - visible pull-down menu equivalents for all short-cut keys and tool bar functions. Use the following techniques for accessibility.

Important: Where possible, maintain consistent keyboard navigation definitions within the applications and for each release of your software.

For usability reasons, most software needs to have product features that are consistent between releases. For example, Lotus maintained the same keyboard accelerators when converting the 123 spreadsheet product from DOS to Windows. The same is true for keyboard access. Imagine the difficulty for users if you swapped the cut and paste keyboard keys.


Unplug the mouse and verify that you can get to all application components and controls via the keyboard and activate them.

At a minimum, the following keyboard operations should be tested:

  • Move the keyboard focus to the menu and the system menu.
  • Display context sensitive menus.
  • Navigate to and select all menus and menu items including the menu bar, system menu, and context sensitive menus.
  • Verify that each toolbar function can be performed using the keyboard.
  • Navigate to and operate every control or "hot spot" in window client areas and dialog boxes.
  • Navigate to sections or panes of the application window.
  • Switch the keyboard focus between modeless dialogs and the application window.
  • Select text and objects in the window client area.
  • Verify that features invoked via direct manipulation using the mouse are available through some keyboard method. For example, if an object can be sized using the mouse by drag and drop, it should also be able to be sized by setting the size attributes explicitly on a dialog or properties sheet.

Any additional enhanced keyboard support provided by the software should also be verified, and documented in an Accessibility Section of the online documentation and helps.

See section 8.0 Testing for Accessibility.

2.1.2 Observe operating system keyboard conventions
It is essential when implementing your keyboard interface that you observe operating system keyboard conventions for the platforms where your application will run.

In Java, you never know what platform your application might run on. Therefore, you must consider how keyboard conflicts might affect the usability of your keyboard implementation.


Take the following steps to prevent conflicts with the underlying operating environment:

Important: The application must not interfere with existing mobility access features built into the operating system, such as Sticky Keys, Slow Keys, and Repeat Keys.


Compare your keyboard bindings to those specified for each target operating system and eliminate conflicts. Run your application on each target operating system and verify that the results of each keyboard action provide the desired results.

See section 8.0 Testing for Accessibility.

2.1.3 Set mnemonics on components
Mnemonics are keyboard equivalents for component activation, for example Alt-F for File. In particular, mnemonics quickly give components focus via the keyboard. Mnemonics are used by all users as a convenient way to switch focus to an application component.

Keyboard mnemonics may be defined for a component as a way for the keyboard to get to that component. It is a fast and direct path to the required control.

Important: Whenever you have a component that supports a setMnemonic method, set the mnemonic to a unique key sequence to activate the object. Don't over use Mnemonics.

One example where this is needed is JFC Menus. Although JFC supports F10 to bring you to a menu bar, there are situations where you might have two menu bars. A mnemonic for the first JMenuBar entry to allow easy access using the keyboard.


Java Foundation Classes provide for keyboard mnemonics in their design. In the case of JFC keyboard mnemonics, all visible items on the screen that set a mnemonic for a component can have the component activated via the ALT+mnemonic.

It is important that all visible menu items in an application's menubar be activated via the keyboard. In JFC, this is accomplished by setting the mnemonics for those menu items. To set a mnemonic, pass a Java virtual key as defined in java.awt.KeyEvent. For example, to set the mnemonic to ALT+F, use:

 JMenu myMenu = new JMenu();

For components that do not specifically have a setMnemonic, the JLabel component in JFC has a method called setDisplayedMnemonic. Use the method to change the focus to the component it is labeling, as defined in the setLabelFor method. Here is a code example:

 //Create a JLabel
 JLabel mylabel = new JLabel("File Name");
 //Create a JTextField
 JTextField myfield = new JTextField("MyFilename");
 //Associate label with text field
 //Set ALT+F for the text field

Some components will be available via the standard keyboard mappings such as those in the logical tabbing order. For these you do not need to set a mnemonic.


Unplug the mouse and verify that you can get to all components with mnemonics.
See section 8.0 Testing for Accessibility.

2.1.4 Use accelerators for commonly used functions
Accelerators are keyboard shortcuts for actions that are frequently performed (e.g. CNTL-P for print, ESCAPE for cancel). When possible, it is a good, but not mandatory practice, to provide keyboard accelerators. A good rule to use is to always set a keyboard accelerator for menu items that appear visually on a tool bar.

It vastly improves the productivity of users if they can quickly access commonly used functions without having to go through a long list of keyboard navigation mechanisms to access frequently used functions.


Java Foundation Classes provide for accelerators in their design. In JFC these are provided in Menus. JFC JMenuItem components provide a setAccelerator method to let you set a keyboard accelerator key. This lets the user activate a menu item without going through the menu.

In the following example we will add the accelerator Alt_L to a menu item in JFC. To assign the Alt+L accelerator to a menu item, use the Swing KeyStroke class to create the key stroke, and pass it to the JMenuItem setAccelerator method as follows:

 JMenuItem myItem = new JMenuItem();


Unplug the mouse and verify you can activate all functions that have accelerator keys.

See section 8.0 Testing for Accessibility.

2.1.5 Provide a logical keyboard tabbing order
Provide a logical navigation sequence between interface objects (logical tab order between buttons, lists, etc.) The navigation order is defined as the order with which you use the keyboard to navigate between components and component elements in your graphical program. Navigation is accomplished by tabbing between components or groups, and using the arrow keys within a component group or component's elements.

The ability to tab between software components is a key feature in the implementation of keyboard accessibility. It is important that application developers maintain a logical keyboard navigation order.


The order in which the tab key navigates among components or groups of components should make sense. The order in which you use of the arrow keys to navigate within a group of components should also make sense such as in a menu.

The techniques for correctly implementing a logical tab order are divided into the following areas:

Adding a component to the tab sequence
A component is added to the tabbing ording in the order in which it appears in the code. A component is inclusive in the tabbing order when added to a panel. Its isFocusTraversable() method returns true. A component can be removed from the tabbing order by simply extending the component, overloading this method, and returning false.

Tab groupings
Buttons of common functionality, such as a set of radio buttons used to set the location of a panel (top left, bottom left, and so on.), should be grouped together so the first element of the group can be tabbed to. The arrow keys can be used to navigate to each of the buttons in the group.


Test your logical keyboard navigation by using the keyboard to Tab through your panels.
See section 8.0 Testing for Accessibility.

2.1.6 Provide electronic access to keyboard navigation documentation
All non standard key assignments for the platform the the application will be deployed on need to be documented online.

A serious problem with many software applications is that documentation for keyboard access features is non-existent. Documenting the features in print format does not help blind users.


To correct this problem, documentation about accessibility features should be available electronically in the application's accessible help facility, and a user should be able to activate the help using the keyboard, typically the F1 key. In the case of blind users, they can use the same screen reader program to access the help facility that they use to access the application. It also improves usability to define a "Keys Help" section in your help facility.

A helpful technique is to include the keyboard mnemonic in the menu alongside the menu item such as "Save Alt-s". This is done automatically in JFC for you whenever you create a menu accelerator.


Verify that you can gain access to keyboard documentation in your electronic help facility. Ensure that your keys help section is accessible and lists all keyboard navigation mechanisms.

See section 8.0 Testing for Accessibility.

2.2 Support multimedia access essentials

2.2.1 Provide visual alternatives to significant audio and video
When using multimedia in your application, you need to incorporate the following functionality:

Users who are deaf are unable to hear audio information and so, it is essential that a text alternative be provided. Users who are blind are unable to see the video track and so it's essential that an alternative description of the significant visual information be provided.


Visual indication of sound and audio can be done using message dialogs or displaying messages in a visible status field in your application. The status field or dialog used must also be accessible. A technique for displaying an accessible message box would be to use the JFC JOptionPane to display a message. JFC JOptionPanes support the Java Accessibility API.

The standard JDK does not provide:

Techniques for implementing these requirements are:

You would need to create or use a Java player that supported the Java Accessibility API and supported these features. Additional information of accessible multimedia is available from the CPB/WGBH National Center for Accessible Medial (NCAM).


Ensure the visual indications for sound and audio cues are accessible as they pertain to the Java Accessibility API. To test the other requirements of this section you will need a player to ensure that alternative video and audio tracks can be rendered in response to captioning and descriptive video. As a mimimum, significant audio and significant video should be available as text files.

2.2.2 Provide an option to adjust the volume
Provide an option to enable the user to disable sound and adjust the volume.

Users may not be able to hear or distinguish sounds at certain volumes, so they need the ability to adjust the volume. Sometimes it may be necessary to disable sound to avoid disturbing others.


To meet this checkpoint you may either have your application respond to system settings for sound, such as a standard beep, or implement your own volume control for your Java application.

If you would like to respond to Windows sound settings you can respond to Windows system settings for sound using JNI and a dynamic link library to access system settings.


Here are some techniques to verify that users can disable sound and adjust the volume.

See section 8.0 Testing for Accessibility.

2.3 Providing focus
It is essential that an application component have a focus at all times. A well-defined on-screen indication of the current focus shall be provided that moves among the interactive interface elements as the input focus changes. The focus shall be programmatically exposed so assistive technology can track focus and focus changes.

Access devices and software, as well as users, need to know where focus is being directed in an application. It is imperative that you always give input focus to the object on which you want the user to operate.


There are a number of ways to request the focus in the JFC. The standard way is to use the focus transversal. Using focus transveral with provided components is automatic. Add components to the user interface and they participate in the focus transveral.
A standard way is to have a particular component execute the requestFocus method. See sample JRequestFocusSample

JFC might not automatically request the focus your Java application becomes the active window. This occurs when the user is running another application and clicks on your Java application with the mouse, or presses Alt+F6 to switch to your Java application. When this happens, your application becomes "active", but does not necessarily receive the focus. Correct this by creating a "default focus" of your choosing. Two techniques of achieving this are as follows:

  1. Using the Window Activation Trigger to Set the Focus in JFC:

//Create a Frame
JFrame jf        = new JFrame();
//Create a JButton Component
//(could use a different component)
JButton myButton = new JButton();
//Add the button the root pane
// Add a Window listener to the JFrame that requests the 
// button to have focus when the window is activated
jf.addWindowListener(new java.awt.event.WindowListener() {
   void windowActivate() {
      //Note: Do this if focus
      //      has never been set before in your window.
      //      Swing remembers the last focus set.
}; // Show the Window

For AWT you may also add a window listener to the Frame that requests focus for a descendent component. The requestFocus method is part of java.awt.Component.

If you want a JFC JButton to have the default focus in a window, you can use the JRootPane component of any JFrame to set the focus to a default button found in the JRootPane as follows:

  1. Using the javax.swing.JRootPane setDefaultButton Method:

JFrame  jf       = new JFrame(); //Create a frame
JButton myButton = new JButton();
//Create a JButton Component
// Add the button the root Pane
// Give the button the default focus
// Show the window;


Use the keyboard to navigate the application and observe that the focus is visible.

2.4 Using alerts and dialogs
Dialogs and Alerts should be built based on the Java accessibility development methodology described in these guidelines so that users of assistive technology can have access to these features.

Dialogs and Alerts often require special system features to maintain the modality of those windows such as disallowing the user to give other windows focus or keeping the dialog at the top of the z-order. Therefore, it is advisable that you use components that have successfully supported accessibility. See sample JDialogSample


It is recommended that you build alerts and dialog features from JFC components, such as JDialog and JOptionPane. These components are made to work with assistive technologies so that the software can track the user's input focus. While other mechanisms might appear to work visually, they might not be programmatically accessible by the assistive technology.


Use assistive technology to verify that dialogs and alerts are programatically available.

See section 8.0 Testing for Accessibility.

2.5 Avoid using AWT and native windowing invocations
Avoid the use of AWT and peered components.

Note: Applications written in Java 1.x using standard AWT components intended to run only on the Windows platform should use the IBM Software Accessibility Guidelines. To date, most Java Abstract Window Toolkit (AWT) components resort to a process called "peering." This means that AWT components, such as dialogs, buttons, menus, and File Dialogs use the native windowing system to do the drawing and much of the component state management. This means that most accessibility information may be lost to Java assistive technology software.

The new Java Accessibility API has not been implemented in the AWT library. We recommend you develop Java applications using the methodology outlined in these guidelines. Specifically, these guidelines recommend that you start building your application using Java Foundation Classes (JFC/Swing), rather than the AWT.


Use the JFC as defined in section 4.0 Using the JFC to Build Accessible Applications.

See section 8.0 Testing for Accessibility.

2.6 Multi-Threading your application - be access aware
Design your application to be adequately multi-threaded to allow assistive technologies to have sufficient time to assist the disabled user. Be access aware.

No applications should be single-threaded.

This avoids thee problem that critical tasks which are blocked or inhibited waiting for a task to complete, do not interfere with other tasks executing.
When there is an assistive technology running in the background, and you prohibit other threads from executing, or you severely inhibit the time they have to run, you inhibit the assistive technology from accessing your software.


Assistive technologies that use the accessibility API to extend access to your application are interacting with your graphical components. It is important that you separate your time intensive operations from your graphical operations. Techniques to do this is are:

The following are example tasks that should not be processed in-line with normal GUI operations and could cause an assistive technology to not respond due to inadequate multi-threading implementations.

The following example shows how to launch a thread that reads from a comm port device rather than performing the task in line. How you return the result back to your GUI will depend on how your application presents the data.

Spawning a Thread that reads from a Comm Port in Java

 private ReadThread readThread_;
 if (readThread == null) {
   //Create the read Thread
   readThread == newReadThread();
 if (!readThread.isAlive()) {
   //start the read thread
   try {
   catch (IllegalThreadStateException e) {
 class ReadThread extends Thread {
      byte inChar_;
      SearchTree searchTree_;
      private boolean wantToRun=true;
      ReadThread() {
         super( "Sample ComPort Read Thread");
         wantToRun = true;
      } // ReadThread constructor

      public void run() {
         while (wantToRun) {
            if (running_) {
               inChar_ = comPort_.readByte();
               if (inChar_ == -1) {       // nothing received
                  try { sleep( 60); }
                  catch (InterruptedException e) {}
            } // if running_
         } // while true
      } // AESerialSpeech.ReadThread#run

       * Stops the this thread.
      public void stopRunning() {
   } // class ReadThread


There are a number of ways to test your application for being adequately multi-threaded. One way is to include the execution of possibly time intensive operations in your system test procedures. Another is to use an assistive technology, like a screen reader, with your application as part of the same test procedure. You will not be adequately multi-threaded if you cannot:

See section 8.0 Testing for Accessibility.

2.7 Provide a logical component layout
When developing the visual layout of your components, provide a logical layout which is determined by the order in which your components are added.

Users of your application will need to navigate your application through the keyboard or through speech. Today there is not a common mechanism to specifically define this logical layout. To solve this problem you need to add components to your application in a logical order.

This logical layout effects the keyboard tabbing sequence and the order an assistive technology uses to read your application. Assistive technologies, today, use the order with which components are added to determine the logical order to use to speak application components. This is also an order for which the Java keyboard tabbing sequence depends.


Developers typically add components to their application by considering only the visual layout, and not the logical layout that a blind user or asssistive technology reads. For example, in most cases, you would not want your menu bar to be read last. Most component libraries today do not allow you, the developer, to define the logical ordering.

Until a better solution is devised, we recommend that when adding components to containers, add them in the logical order as they should be read on the screen. For example, if you are using an %%%%%%AWT border layout, you could add components as follows:

 public class BorderTest extends Frame implements Accessible{
     public BorderTest () {
          AccessiblePanel p = new AccessiblePanel();
          p.setLayout(new BorderLayout();
          p.add(new MyAccessibleButton("Left");
          p.add(new MyAcessibleButton("Bottom");
          p.add(new MyAcessibleButton("Right");
          p.add(new MyAcessibleButton("Top");
          add("North", p);
     AccessibleContext getAccesibleContext() {

Child enumeration in Java enumerates the children in the order that you added them. By merely changing the order in which you add the components, you can enable the assistive technology to read the components in the appropriate order, as shown in the following sample code, and still accomplish the same visual effect:

 p.add(new MyAcessibleButton("Top");
 p.add(new MyAccessibleButton("Left");
 p.add(new MyAcessibleButton("Right");
 p.add(new MyAcessibleButton("Bottom");


The best way to test your implementation is to use a screen reader to navigate your application. Have the screen reader read your page from top to bottom. If information is not spoken in a logical order you will need to modify your component layout.

See section 8.0 Testing for Accessibility.

2.8 Provide accessible relationships
Depending on the disability, a person may have difficulty using your application because the proper semantic relationships have not been provided to the user in an accessible way. For example, due to a learning disability or an inability to convey semantically what you want to achieve visually in your application the user may be unable to readily understand your software. In this section, three basic requirements are defined based on the available technology:

2.8.1 Label components
Label components and provide labeling semantics for components needing textual semantics to define the component. Examples of this are text entry fields.

Users who are blind and are using a screen reader to speak your application need to work with components such as text entry fields. It is necessary to speak the label as well as its text when it receives focus. As a developer you may have created a text label to label the component. If you do not provide a relationship that indicates the label is for the specific entry field the screen reader may be unable to make the association of the label with the entry field.


When using a JFC JLabel to label another component, call its setLabelFor method to set the component it is labeling. This can be null if this does not label a component. When you use setLabelFor, the component you label (e.g. a JTextField) will get the AccessibleName and AccessibleDescription of the JLabel. If both the displayedMnemonic and labelFor properties are set, the label requests focus to the component specified by the labelFor property when the mnemonic is activated. Section 2.3 Providing Focus provides details about requesting the keyboard focus.

Unfortunately, the above technique only applies to JFC components. In Java 1.3 and later, you will be able to define an AccessibleRelation of AccessibleRelation.LABEL_FOR to define a label for a specific component. This would be followed by adding an AccessibleRelation.LABELED_BY for the target component:

 //Create a label of First Name:. The AccessibleName will  
 //assume this initial setting in JFC
 JLabel label = new JLabel("First Name:");
 //Create an empty text field
 JTextField tf = new JTextField();
 //Create a LABEL_FOR relationship in the JLabel that 
 //indicates that the label is a label for the text field.
 AccessibleRelationSet arSet1
   = label.getAccessibleContext().getAccessibleRelationSet();
 AccessibleRelation ar1 
   = new AccessibleRelation(AccessibleRelation.LABEL_FOR, tf);

 //Create a LABEL_BY relationship in the JTextField that 
 //indicates that the text field is labeled by the label
 //of First Name.
 AccessibleRelationSet arSet2
   = label.getAccessibleContext().getAccessibleRelationSet();
 AccessibleRelation ar2 
   = new AccessibleRelation(AccessibleRelation.LABELED_BY,
 //Add the components to your application.

In this example a screen reader should speak "First Name:" followed by the text entry field role and text, in the entry field (if any), whenever the user tabs to the entry field. This Accessibility API feature allows you to add label semantics without the reliance on the JFC JLabel component.


To test proper component labeling use a screen reader or the Self Voicing Development Kit to ensure that your components have their labels spoken when they receive focus.

See section 8.0 Testing for Accessibility.

2.8.2 Name logical groups
When GUI components have a logical association, group them, and assign the grouping a name. See sample JRadioButtonSample


It is important for you to logically group components and assign that grouping a name. This facilitates navigation of your application. For example, you might need to group a set of check boxes into a panel. The collection of check boxes may define the search options of your application such as case sensitivity. Here, you would want to group the search options into a panel with a name of "Search Options." This would help an assistive technology to read the name of the "Search Options" when one of the elements in the group is tabbed to.


To identify a logical group , in JFC, you can add components to JPanels and set the AccessibleName on the JPanel. Another technique to do this is to create a JPanel with a JFC TitledBorder. There is no reason to set the AccessibleName> because the JFC will set the name to the title text.

In Java 1.3 and later, an accessible relation was defined to define objects which are a member of a given group. The following code indicates how you could take an arbitrary component set that implements the Accessibility API and create a named group containing accessible components indicating the relationship to the enclosing group:

 //Create a named group panel with name "Search Options"
 JPanel group = new JPanel();
                                       "Search Options");
 //Create a check box and indicate it as being a 
 //member of the group 
 JCheckBox cb1  = new JCheckBox("Case Sensitivity");
 AccessibleRelationSet  arSet 
   = cb1.getAccessibleContext().getAccessibleRelationSet();
 AccessibleRelation     ar    
   = new AccessibleRelation(AccessibleRelation.MEMBER_OF,
 //Create a check box and indicate it as being a 
 //member of the group 
 JCheckBox cb2 = new JCheckBox("Regular Expression");
 AccessibleRelationSet  arSet 
   = cb2.getAccessibleContext().getAccessibleRelationSet();
 AccessibleRelation     ar 
   = new AccessibleRelation(AccessibleRelation.MEMBER_OF,
 //Create a check box and indicate it as being a 
 //member of the group 
 JCheckBox cb3 = new JCheckBox("Wrap Beginning/End");
 AccessibleRelationSet  arSet 
   = cb3.getAccessibleContext().getAccessibleRelationSet();
 AccessibleRelation     ar 
   = new AccessibleRelation(AccessibleRelation.MEMBER_OF, 
 //Add the components to the panel


To test proper component grouping use a screen reader to ensure that your components have their group name spoken when they receive focus. Typically only the first element in a group will have its group name spoken with the component.

See section 8.0 Testing for Accessibility.

2.9 Describe icons and graphics
Provide text alternatives for icons and graphics.

Users who are blind or who have low vision are unable to determine what a graphic represents or the purpose of an application component.


To solve this problem, the best techniques are to:


To test text alternatives for icons and graphics (see sample JIconSample) use a screen reader or the Self Voicing Development Kit that supports Java to ensure that your icons and graphics have descriptions on them.

See section 8.0 Testing for Accessibility.

2.10 Support display access essentials for java
This section enumerate requirements related to display settings and features that improve accessibility.

2.10.1 Support system settings for font, size, and color
Support system system settings for font, size, and color for all user interface controls. In JDK 1.4 this is provided by using the Windows look and feel.

Operating systems, like Windows, provide the capability to configure system color, fonts, and font sizes to be helpful for people with disabilities. People with low vision often configure their system for high contrast and larger font settings. People who are color blind may wish to configure system colors for a monochrome color scheme. People who are dyslexic may wish to have the client area make use of a rose background to improve readability.


Java 1.4 allows the application to pick up system settings for font, size and color.


To test your implementation, modify the system settings for color and font for each component type in your application, then ensure that the changes appear in each of your Java application components.

2.10.2 Use color only as an enhancement
Use color as an enhancement, not as the only way to convey information or indicate an action.

If the software conveys information by color alone, users who cannot identify or distinguish colors will not be able to make use of the information. For example, asking users to press the red button is not useful if they can't distinguish the red button from other buttons on the screen. The software needs to provide another way of making the information available.


The following techniques and examples will help you comply with this requirement.


Test the software to ensure that it complies with accessibility requirements. Several techniques are available to verify that information conveyed with color is accessible.

See section 8.0 Testing for Accessibility.

2.10.3 Variety of color
When color customization is supported, provide a variety of color selections capable of producing a range of contrast levels.

For many people, color is a matter of preference, but it is critical for many users with visual impairments. Users with visual impairments require a high contrast between text and the background to be able to read. They may even need a particular scheme, such as white text on a black background, to prevent the background from "bleeding" over and obscuring the foreground text. They may need to change the color scheme due to color blindness.

Because different users need different colors and different high contrast settings, it is not sufficient to support only one set of colors or only one high contrast setting.


The following techniques are a minimum.

Lighthouse International provides guidelines for effective color contrast on their Web site at


Test the software to ensure that it complies with accessibility requirements. Several techniques are available to verify that software has a variety of color settings.

See section 8.0 Testing for Accessibility.

2.10.4 Support system settings for high contrast
Support system settings for high contrast for all user interface objects, including client area content.

Users with visual impairments may require a high contrast between text and the background to be able to read. They may even need a particular scheme, such as white text on a black background, to prevent the background from "bleeding" over and obscuring the foreground text. Some people consider the default color scheme quite legible but find that it causes eye strain over longer periods of time.


For operating systems that do not support system high contrast settings, this checkpoint does not apply.

The following techniques and examples will help you comply with this requirement.

If you use the Windows Pluggable Look and Feel (PLAF), provided with JFC, and you use standard JFC components you will automatically inherit system color settings, for high contrast, on all Windows systems for standard GUI components. This does not work for other operating systems. Also, high contrast settings will not be reflected in custom components you make yourself.

In order for you to use high contrast settings, with JFC, on a variety of platforms you will need to create a PLAF that uses Java Native Interface (JNI) to access a Dynamic Link Library (DLL), you'll create. This DLL will need to access system font and color settings for each component. Although not required, it is helpful if the your application responds to changes in these settings to avoid having to stop and restart your application. If your application is only built to run on Windows systems then you may wish to create your new PLAF from the Windows PLAF.

If you have a custom component that does not support JFC or PLAF you will need to access the appropriate systems settings using JNI and a DLL as described in the previous paragraph.

For components that do not have a corresponding standard system controls you will need to create high contrast capabilities to you components that respond to system changes in the setting of high contrast features.

On Windows systems:

If you have a custom component library that does not support JFC you will need to access the appropriate systems settings using JNI and a DLL as described in the previous paragraph.


Several techniques are available to verify that software supports high contrast settings.

On Windows systems, turn on the high contrast setting, and check that your application respects that setting. For example, if you choose the High Contrast scheme to be "High contrast #1" (yellow on black) in Windows 98, most window text, including the main (client, document) window, should be yellow on black. In this example, title bars and menus have different colors. You can check the colors of the "High Contrast #1" by choosing that scheme in the Display settings dialog, Appearance page.

Note: This requirement is only for operating systems that support high contrast color schemes.

2.10.5 Provide client area zooming
Provide a zoom funtion that allows the user to increase or decrease magnification of client area content.

The size of text and graphics affects usability as well as accessibility. Many individuals who do not consider themselves to be disabled want to "view" a document or an application work area in an enlarged font while not affecting the actual document or work. For individuals with acknowledged visual impairments, the ability to zoom the application work area to 150%, 200% or greater may make the difference between being able to use the application or not. The vast majority of individuals who need this kind of access do not use screen magnifiers.


Here are some techniques to implement a client area zooming feature.


Here are some techniques to verify that software supports zooming:

2.10.6 Provide option to turn off patterned backgrounds
Provide the capability for users to turn off patterned backgrounds behind text or graphics.

Text drawn over a patterned background will be illegible for many users because it does not provide sufficient contrast between the background and the text, and because the pattern "bleeds" into the text. In order for them to read the information on the screen, users need to be able to turn off the background and revert to a solid color background.


Here are some techniques for implementing this requirement:


Verify that any patterned background can be replaced with a solid background.

2.10.7 Animated presentation
Provide an option to display animation in a non-animated presentation mode.

Someone who is blind uses a computer with the aid of assistive technology such as a screen readers or a braille display. Animation is useful only for the sighted user. Another method of providing the needed information to the blind is needed.


Here are some techniques for implementing this requirement:


See section 8.0 Testing for Accessibility.

2.11 Support timing access essentials

2.11.1 Allow response time adjustment
Provide an option to adjust the response time or allow the instruction to persist.Some users have difficulty reading or responding to information if it is displayed briefly or requires a quick response time. Some response delays may also be caused by the use of assistive technology used to read the screen or by the use of tools which magnify only a portion of the screen.



Here are some techniques to verify that users can adjust response times:

2.11.2 Avoid blinking text, objects, or other elements.
Avoid the use of blinking text, objects, or other elements.

Displays which flicker or flash can cause epileptic seizures in susceptible individuals, particularly if the flash has a high intensity and is within certain frequency ranges. This includes flashing text or graphics on and off or repeatedly changing between different images on the screen.



This is a difficult feature to test however one way to do this is to add a programmatic test feature to display the time interval between flashes.

See section 8.0 Testing for Accessibility.

Next: 3.0 java foundation classes (JFC) - a foundation for accessibility