1. Accessibility Guide
  2. Accessibility Features and Tips for Oracle Forms and Reports
  3. Accessibility Features and Tips for Oracle Forms
  4. Building Forms that Support Accessibility Features
  5. Keyboard Access

Keyboard Access

This section provides information to build Forms that support keyboard access to menu, toolbar functionality, and components.

To support keyboard access:

  • Radio buttons, check boxes and push buttons should have access keys (mnemonics) defined.

  • The keyboard tabbing sequence should follow a logical order, typically left-to-right, top-to-bottom.

  • The keyboard tabbing sequence should cycle through most if not all items in a window.

  • The user should be able to navigate between all of the blocks and windows of an application with only the keyboard.

  • Scrollbars should not be the only way to move between records or to scroll canvasses.

  • List Tab Pages function (typically mapped as F2) to switch tab pages should move focus to the first navigable item on that tab page.

Access Keys

Access keys allow operators to select or execute an item by pressing a key combination, even when that item is not the currently focused item. For example, a button labeled Open with an access key of O can be activated at any time by pressing Alt+O. Access keys are applicable to menu items, push buttons, checkboxes, radio buttons and tab pages. All access keys within a window should be unique, including keys used in the top level of the pull-down menu (typically F for File, E for Edit, etc.).

Accelerators

Accelerators are keyboard shortcuts for actions that are frequently performed, for example, Ctrl+P for Print. Keyboard shortcuts allow users to bypass opening the menu by using a specific combination of keystrokes that perform the same function as a corresponding menu item. Instead of pressing Alt+F, then S, to activate menu item File-Save, a user can just press Ctrl+S to execute the same function. Accelerator keys are desirable but not mandatory and are listed in Keyboard Help at runtime.

Exceptions for Not Having Access Keys

Push Buttons, Check boxes, Tabs, Menu Items and Radio Buttons should have an access key unless:

  • They are keyboard navigable (an access key is still desirable in this case).

  • There is an excessive number of them such that deriving a unique letter would be difficult (in which case the ones with no access key must be Navigable).

  • They are not absolutely critical to the functionality of the product.

  • For Checkboxes and Radio Buttons: if they are part of a multi-row block and use the Prompt, not the Label attribute, they cannot render any access key.

Labels

Not every item with a Label property must have an access key. If the item can be navigated to (that is, it is part of the keyboard tabbing sequence), then it does not need an access key, although adding one is highly desirable as it benefits all users. Note that the Microsoft Windows User Interface Guidelines state that OK and Cancel buttons should not have access keys.

Menu Items

Menu items should have access keys for the top-level entries at the very least, though they are not required. The menu can always be invoked from the keyboard by pressing and releasing Alt. This will move the focus to the menu, and the arrow keys can be used to navigate through it.

Iconic Buttons

Iconic buttons (Push Buttons with the Iconic property set to Yes) cannot have an access key, therefore the functionality they invoke should be replicated elsewhere in a manner that is accessible, such as the pull-down menu.

Checkboxes and Radio Buttons

  • In a single-row block, the speakable prompt of a checkbox is almost always its Label attribute. In a multi-row block, where only a single instance of the prompt is typical, the Prompt attribute should serve as both the on-screen and speakable prompt for the item, and the Label should be null.

  • For radio buttons, use the Hint Text of the radio group to hold the speakable prompt. In a single-row block, the Label attribute of each button acts as its value; in a multi-row block where only a single instance of the prompt is typical, the Prompt attribute should serve as both the on-screen prompt and 'value' for the item, and the Label should be null.

  • If the Label can be utilized, then it is very desirable to provide an access key, though not required as long as the widget is navigable. If the widget is not navigable, then using the mouse would be the only activation means, thus the access key is required.

Oracle E-Business Business Suite Features

  • Radio groups, radio buttons, push buttons and check boxes need to be subclassed with the appropriate FND property class. These classes specify a Pluggable Java Component (PJC) to guarantee uniqueness of access keys. At runtime, if the letter specified is already in use within the window, including the pull-down menu, a different letter will automatically be selected. This feature is most useful for applications which will be translated, where the translators may have a difficult time establishing unique access keys because they may not be operating in an environment where they can see the effect of their changes at runtime.

  • Tabs, pop-up menu items, and dynamically labeled pull-down menu items should not have access keys because they cannot be guaranteed to be unique after translation. The PJC mechanism used on other items is not possible on these.

  • An access key should be specified within the label, such as &Print. The separate Access Key property should not be used.

  • One default button per window should be provided, where that function is the most likely for the user to perform. Always provide a default button in a modal window (typically OK). All push buttons should have an access key except OK and Cancel within dialog windows. OK must have an access key if it is not the default button, and Cancel must have an access key if it does not perform the same function as Close Window.

Blocks

Every block must be navigable with the keyboard. Typically the navigation between blocks is controlled with the Next Navigation Block and Previous Navigation Block properties, and/or the KEY-NEXT-BLOCK and KEY-PREVIOUS-BLOCK triggers.

Tab Pages

The WHEN-TAB-PAGE-CHANGED trigger needs to be coded properly so that focus moves to the first navigable item when the user presses List Tab Pages function (typically mapped as F2) to switch tab pages. The cursor does not automatically move to a different item. To move the cursor, there must be code to include a GO_ITEM statement in the WHEN-TAB-PAGE-CHANGED trigger. This is intended functionality to allow users to view other tab pages without navigating the cursor and therefore causing item navigation and validation.

Sample WHEN-TAB-PAGE-CHANGED trigger at a form level:
DECLARE
	tp_name VARCHAR2(30);
	tp_label VARCHAR2(30);

BEGIN 
	tp_name := :SYSTEM.TAB_NEW_PAGE;
	tp_label := GET_TAB_PAGE_PROPERTY(tp_nm, label);

IF tp_lbl = 'NAME' THEN
	GO_ITEM('FIRST_NAME'); -- or GO_BLOCK(...)
ELSIF tp_lbl = 'ADDRESS' THEN
	GO_ITEM('ADDRESS_LINE_1');
END IF;
END;

Menus

Include the Window menu entry when building a custom menu; by default the Window menu entry is not included. This entry allows a user to switch between currently open windows within the application from the keyboard.

Parent topic: Building Forms that Support Accessibility Features