How to Configure Optional Localization Properties

22 Developing Accessible ADF Faces Pages 22-1 22 Developing Accessible ADF Faces Pages This chapter describes how to add accessibility support to ADF Faces components with keyboard shortcuts and text descriptions of the component name and state. Accessibility guidelines for ADF pages that use partial page rendering, scripting, styles, and certain page and navigation structures are also described. This chapter includes the following sections: ■ Section 22.1, Introduction to Accessible ADF Faces Pages ■ Section 22.2, Exposing Accessibility Preferences ■ Section 22.3, Specifying Component-Level Accessibility Properties ■ Section 22.4, Creating Accessible Pages ■ Section 22.5, Running Accessibility Audit Rules

22.1 Introduction to Accessible ADF Faces Pages

Accessibility involves making your application usable for persons with disabilities such as low vision or blindness, deafness, or other physical limitations. This means creating applications that can be used without a mouse keyboard only, used with a screen reader for blind or low-vision users, and used without reliance on sound, color, or animation and timing. Oracle software implements the standards of the Web Content Accessibility Guidelines WCAG 1.0 Level AA using an interpretation of the standards at http:www.oracle.comaccessibilitystandards.html Additional framework and platform issues presented by client-side scripting, in particular using asynchronous JavaScript and XML AJAX have been addressed in Oracle’s accessibility strategy. ADF Faces user interface components have built-in accessibility support for visually and physically impaired users. User agents such as a web browser rendering to nonvisual media such as a screen reader can read component text descriptions to provide useful information to impaired users. Access key support provides an alternative method to access components and links using only the keyboard. ADF Faces accessibility audit rules provide direction to create accessible images, tables, frames, forms, error messages and popup windows using accessible HTML markup. While following provided ADF Faces accessibility guidelines for components, page, and navigation structures is useful, it is not a substitute for familiarity with accessibility standards and performing accessibility testing with assistive technology. 22-2 Web User Interface Developers Guide for Oracle Application Development Framework

22.2 Exposing Accessibility Preferences

ADF Faces provides three levels of application accessibility support, configured in the trinidad-config.xml file using the accessibility-mode element. The acceptable values for accessibility-mode are: ■ default: By default, ADF Faces generates HTML code that is accessible to disabled users. ■ screenReader: ADF Faces generates HTML code that is optimized for the use of screen readers. The screenReader mode facilitates text usage for disabled users, but may degrade the output for nondisabled users or users with only some physical limitations. For example, access keys are disabled in screenReader mode in order to prevent conflicts with keys used by assistive technology. ■ inaccessible: ADF Faces removes all code that supports assistive technology. This optimization reduces the size of the generated HTML. The application, however, is no longer accessible to disabled users. You can also use the accessibility-profile element to define finer-grain accessibility preferences in the style sheet or you can specify the accessibility profile options in the trinidad-config.xml file.The options are high-contrast, large-fonts, or both. For more information, see Section 20.1.1, ADF Faces Skins. The acceptable values for accessibility-profile are: ■ high-contrast: ADF Faces can generate high-contrast–friendly visual content. The high-contrast mode is intended to make ADF Faces applications compatible with operating systems or browsers that have high-contrast features enabled. For example, ADF Faces changes its use of background images and background colors in high-contrast mode to prevent the loss of visual information. Note that the high-contrast mode is more beneficial if it is used in conjunction with your browser’s or operating system’s high-contrast mode. Also, some users might find it beneficial to use the large-font mode along with the high-contrast mode. ■ large-fonts: ADF Faces can generate browser-zoom–friendly content. In default mode, most text and many containers have a fixed size to provide a consistent and defined look. In the large-font mode, text and containers have a scalable size. This allows ADF Faces both to be compatible with browsers that are set to larger font sizes and to work with browser-zoom capabilities. Note that if you are not using the large-font mode or browser-zoom capabilities, you should disable the large-font mode. Also, some users might find it beneficial to use the high contrast mode along with the large-font mode.

22.2.1 How to Configure Accessibility Support in trinidad-config.xml

In JDeveloper, when you insert an ADF Faces component into a JSF page for the first time, a starter trinidad-config.xml file is automatically created for you in the WEB-INF directory. The file has a simple XML structure that enables you to define element properties using the JSF expression language EL or static values. The order of elements in the file does not matter. You can configure accessibility support by editing the XML file directly or by using the Structure window. Note: The accessibility-mode and accessibility-profile elements are EL-bound to a session scope managed bean that contains the user-specific preference. Developing Accessible ADF Faces Pages 22-3 To configure accessibility support in trinidad-config.xml in JDeveloper: 1. In the Application Navigator, double-click trinidad.xml. 2. In the XML editor, enter the element name accessibility-mode and accessibility support value default, screenReader, or inaccessible. For example: accessibility-modescreenReaderaccessibility-mode This code sets the application’s accessibility support to the screen reader mode. 3. Enter the element name accessibility-profile and accessibility profile value high-contrast, large-fonts. For example: -- Enable both high-contrast and large-fonts content -- accessibility-profilehigh-contrast large-fontsaccessibility-profile This code sets the application’s profile support to use both high contrast and large fonts. 4. Alternatively, you can use the Structure window to insert the value:

a. In the Application Navigator, select the trinidad-config.xml file.

b. In the Structure window, right-click the XML file root element, choose the Insert Inside menu item, and click the accessibility-mode element. c. Double-click the newly inserted element in the Structure window to open the Property Inspector. Enter a value or select one from the dropdown list. Once you have configured the trinidad-config.xml file, you can retrieve the property values programmatically or by using JSF EL expressions. For example the following code returns nothing if the accessibility mode is not explicitly set: String mode=ADFFacesContext.getCurrentInstance.getAccessibilityMode; In this EL expression example, a null is returned if the accessibility mode is not explicitly set: af:outputText value={requestContext.accessibilityMode}

22.3 Specifying Component-Level Accessibility Properties

Guidelines for component-specific accessibility are provided in Section 22.3.1, ADF Faces Component Accessibility Guidelines. The guidelines include a description of the relevant property with examples and tips. For information about auditing compliance with ADF Faces accessibility rules, see Section 22.5, Running Accessibility Audit Rules. Access key support for ADF Faces input or command and go components such as af:inputText, af:commandButton, and af:goLink involves defining labels and specifying keyboard shortcuts. While it is possible to use the tab key to move from one control to the next in a web application, keyboard shortcuts are more convenient and efficient. To specify an access key for a component, set the components accessKey attribute to a keyboard character or mnemonic that is used to gain quick access to the component. You can set the attribute in the Property Inspector or in the page source using amp encoding. 22-4 Web User Interface Developers Guide for Oracle Application Development Framework The same access key can be bound to several components. If the same access key appears in multiple locations in the same page, the rendering agent will cycle among the components accessed by the same key. That is, each time the access key is pressed, the focus will move from component to component. When the last component is reached, the focus will return to the first component. Using access keys on af:goButton and af:goLink components may immediately activate them in some browsers. Depending on the browser, if the same access key is assigned to two or more go components on a page, the browser may activate the first component instead of cycling through the components that are accessed by the same key. To develop accessible page and navigation structures follow the additional accessibility guidelines described in Section 22.4, Creating Accessible Pages.

22.3.1 ADF Faces Component Accessibility Guidelines

To develop accessible ADF Faces components, follow the guidelines described in Table 22–1 . Components not listed do not have accessibility guidelines. Note: Access keys are not displayed if the accessibility mode is set to screenReader mode. For more information, see Section 22.2, Exposing Accessibility Preferences. Note: In cases where the label property is referenced in the accessibility guidelines, the labelAndAccessKey property may be used where available, and is the preferred option. Unless noted otherwise, you can also label ADF Faces input and select controls by: ■ Specifying the for property in an af:outputLabel component ■ Specifying the for property in an af:panelLabelAndMessage component Table 22–1 ADF Faces Components Accessibility Guidelines Component Guidelines af:chooseColor For every af:chooseColor component, there must be at least one af:inputColor component with a chooseId property which points to the af:chooseColor component. af:chooseDate For every af:chooseDate component, there must be at least one af:inputDate component with a chooseId property which points to the af:chooseDate component af:commandButton One of the following properties must be specified: text, textAndAccessKey, or shortDesc. The text should specify the action to be taken and make sense when read out of context. For example use go to index instead of click here.