Software checklist

Checkpoint 2.2: Object information - examples for Java developers

Provide semantic information about user interface objects. When an image represents a program element, the information conveyed by the image must also be available in text.

This page provides specific examples to implement the Software techniques for providing visual focus indicator using Java Swing. For an explanation of this requirement, see Rationale for object information in the Software checklist.


Required development techniques

The following techniques are the minimum required to meet Checkpoint 2.2 from the IBM Software Accessibility Checklist:

  1. All standard user interface controls must expose the accessible attributes for name, role, and state. Value must be exposed when there is visual information contained in the control.
  2. All custom controls must expose the accessible attributes for name, role, and state. Value must be exposed when there is visual information contained in the control.

 

Examples for Java developers

1. All standard user interface controls must expose the accessible attributes for name, role, and state. Value must be exposed when there is visual information contained in the control.

Example 1

Implement the Java Accessibility API by:

Example 2

Unless otherwise noted, use the Swing components unmodified. Ensure that the AccessibleName , AccessibleDescription , AccessibleRole , and AccessibleState are set, as appropriate, for every user interface element and control. Follow the guidelines in section "4.0 Using the JFC to Build Accessible Applications" of the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java™.

Example 3

When using radio buttons add them to a ButtonGroup . This will allow a screen reader to inform the user that the radio button they have selected is part of a set.

For example:

//Various radio buttons private JRadioButton lab_button; private JRadioButton poodle_button; private JRadioButton shepherd_button; private JRadioButton mut_button; //Create the button group and add the radio buttons. radio_group = new ButtonGroup(); radio_group = new ButtonGroup(); JRadioButton buttons[] = {lab_button, poodle_button, shepherd_button, mut_button}; for (int i=0; i<buttons.length; ++i) {JRadioButton rb = buttons[i]; radio_group.add (rb); }

For more information, download the JRadioButtonSample from the Java accessibility samples page

2. All custom controls must expose the accessible attributes for name, role, and state. Value must be exposed when there is visual information contained in the control.

Example 4

Create a hybrid component by subclassing the JFC JComponent class. Implement the Accessibility API on your class library or component. Follow the guidelines in section "4.0 Using the JFC to Build Accessible Applications" of the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java™

Example 5

Implement the Java Accessibility API on all custom class library components. Follow the guidelines in section "5.0 Building Custom Accessible Components" of the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java™. The following sample JCustomControl Sample will be useful in illustrating custom controls.

Example 6

An "About" box is a dialog box usually displayed when the user selects the "About..." menu item on the "Help" menu. It usually contains information such as the product version number and copyright information. If an "About" box is provided, it must be an accessible dialog box, not a bit map containing text. Providing accessible text allows a screen reader to read it to the user and makes it more readable when magnified with a screen magnifier. Splash screens that are displayed briefly when an application is loading are not required to be accessible if the product version number and copyright information is available in an accessible "About" dialog box.


Recommended development techniques

The techniques above are required; the following techniques are recommended to enhance accessibility:

Lists, combo boxes, and trees should use the AccessibleDescription to provide further context as to their function. For example, a user may be able to select a server from a tree structure, and then make changes to it by using a set of controls. A visual user can scan the whole screen and be able to determine the complete picture, but a screen reader user can only tab to one control at a time. So, adding a description as to the tree's function would help a screen reader user understand the screen's layout more effectively.

private JTree server_tree ; Server_tree.getAccessibleContext().setAccessibleDescription("This tree represents the servers in the system. Use the other controls on this screen to make changes to the currently selected server.") ;

 

Required test techniques

Test the software to ensure it complies with accessibility requirements.

Required test software

Install the following software to test this checkpoint.

  • A screen reader that supports Java, and the Java Access Bridge (link resides outside of ibm.com).

Test techniques

There are no unique steps for testing object information for Java Swing. Follow the required test techniques in Software checkpoint 2.2.

  • If a screen reader defect prevents properly coded information from being announced this checkpoint passes. See the debug techniques for details.

Debug techniques

If the screen reader test fails for any user interface element, the problem must be debugged with an accessibility API validation tool. These techniques can be used to help determine if a problem is caused by a coding error in the application, or if it is caused by a screen reader defect.

The following techniques are required to verify this checkpoint:
Action Results for compliance
  1. Review the development techniques and insure the implementation is correct according to the development techniques.
  2. Use the API validation tool that is appropriate to your product to determine if the development techniques have been implemented properly.

Additional information on how to use the API validation tool is included with the tool.

  1. The implementation is correct according to the development techniques.
  2. The accessibility API validation tool shows that the API properties expose sufficient information as defined in the development techniques for this checkpoint.
  3. Additional instructions:

©2009, 2013 IBM Corporation

Last updated January 1, 2013.