ADF Data Visualization Components Accessibility Guidelines

22-10 Web User Interface Developers Guide for Oracle Application Development Framework Example 22–4 ValueAndAccessKey Attribute Defined af:outputLabel for=someid valueAndAccessKey=Select Datamp;e af:inputText simple=true id=someid Access key modifiers are browser and platform-specific. If you assign an access key that is already defined as a menu shortcut in the browser, the ADF Faces component access key will take precedence. Refer to your specific browser’s documentation for details. In some browsers, if you use a space as the access key, you must provide the user with the information that Alt+Space or Alt+Spacebar is the access key because there is no way to present a blank space visually in the components label or textual label. For that browser you could provide text in a component tooltip using the shortDesc attribute.

22.3.5 How to Define Localized Labels and Access Keys

Labels and access keys that must be displayed in different languages can be stored in resource bundles where different language versions can be displayed as needed. Using the resource-bundle element in the JSF configuration file available in JSF 1.2, you can make resource bundles available to all the pages in your application without using a f:loadBundle tag in every page. To define localized labels and access keys: 1. Create the resource bundles as simple .properties files to hold each language version of the labels and access keys. For details, see Section 21.3.1, How to Define the Base Resource Bundle.

2. Add a locale-config element to the faces-config.xml file to define the

default and supported locales for your application. For details, see Section 21.3.3, How to Register Locales and Resource Bundles in Your Application.

3. Create a key and value for each string of static text for each resource bundle. The

key is a unique identifier for the string. The value is the string of text in the language for the bundle. In each value, place an ampersand or amp in front of the letter you wish to define as an access key. For example, the following code defines a label and access key for an edit button field in the UIStrings.properties base resource bundle as Edit: srlist.buttonbar.edit=Edit In the Italian language resource bundle, UIStrings_it.properties, the following code provides the translated label and access key as Aggiorna: srlist.buttonbar.edit=Aggiorna 4. Add a resource-bundle element to the faces-config.xml file for your application. Example 22–5 shows an entry in a JSF configuration file for a resource bundle. Example 22–5 Resource Bundle in JSF Configuration File resource-bundle varresvar base-nameresources.UIStringsbase-name resource-bundle Developing Accessible ADF Faces Pages 22-11 Once you set up your application to use resource bundles, the resource bundle keys show up in the Expression Language EL editor so that you can assign them declaratively. In the following example, the UI component accesses the resource bundle: af:outputText value={res[’login.date’]} For more information, see Chapter 21, Internationalizing and Localizing Pages.

22.4 Creating Accessible Pages

In addition to component-level accessibility guidelines, you should also follow page-level accessibility guidelines when you design your application. While component-level guidelines may determine how you use a component, page-level accessibility guidelines are more involved with the overall design and function of the application as a whole. The page-level accessibility guidelines are for: ■ Using partial page rendering ■ Using scripting ■ Using styles ■ Using page structures and navigation ■ Using WAI-ARIA landmark regions

22.4.1 How to Use Partial Page Rendering

Screen readers do not reread the full page in a partial page request. Partial page rendering PPR causes the screen reader to read the page starting from the component that triggered the partial action. Therefore, place the target component after the component that triggers the partial request; otherwise, the screen reader will not read the updated target. For example, the most common PPR use case is the master-detail user interface, where selecting a value in the master component results in partial page replacement of the detail component. In such scenarios, the master component must always appear before the detail component in the document order. Screen reader or screen magnifier users may have difficulty determining exactly what content has changed as a result of partial page rendering activity. It may be helpful to provide guidance in the form of inline text descriptions that identify relationships between key components in the page. For example, in the master-detail scenario, some text that indicates that selecting a row on a master component will result in the detail component being updated could be helpful. Alternatively, a help topic that describes the structure of the page and the relationships between components may also be helpful.

22.4.2 How to Use Scripting

Client-side scripting is not recommended for any application problem for which there is a declarative solution and should be kept to a minimum. Follow these accessibility guidelines when using scripting: ■ Do not interact with the component DOM Document Object Model directly. 22-12 Web User Interface Developers Guide for Oracle Application Development Framework ADF Faces components automatically synchronize with the screen reader when DOM changes are made. Direct interaction with the DOM is not allowed. ■ Do not use JavaScript timeouts. Screen readers do not reliably track modifications made in response to timeouts implemented using the JavaScript setTimeout or setInterval APIs. Do not call these methods. ■ Provide keyboard equivalents. Some users may not have access to a mouse. For example, some users may be limited to keyboard use only, or may use alternate input devices or technology such as voice recognition software. When adding functions using client-side listeners, the function must be accessible in a device-independent way. Practically speaking this means that: – All functions must be accessible using the keyboard events. – Click events should be preferred over mouseover or mouseout. – Mouseover or mouseout events should additionally be available through a click event. ■ Avoid focus changes. Focus changes can be confusing to screen reader users as these involve a change of context. Applications should avoid changing the focus programmatically, and should never do so in response to focus events. Additionally, popup windows should not be displayed in response to focus changes because standard tabbing will be disrupted. ■ Provide explicit popup triggers. Screen readers do not automatically respond to inline popup startups. In order to force the screen reader to read the popup contents when in the screen reader mode, the rich client framework explicitly moves the keyboard focus to any popup window just after it is opened. An explicit popup trigger such as a link or button must be provided, or the same information must be available in some other keyboard or screen reader accessible way.

22.4.3 How to Use Styles

ADF Faces components are already styled and you may not need to make any changes. If you want to use cascading style sheet CSS to directly modify their default appearance, you should follow these accessibility guidelines: ■ Be aware of accessibility implications when you override default component appearance. Using CSS to change the appearance of components can have accessibility implications. For example, changing colors may result in color contrast issues. ■ Use scalable size units. When specifying sizes using CSS, use size units that scale relative to the font size rather than absolute units. For example, use em, ex or units rather than px. This is particularly important when specifying heights using CSS, because low-vision users may scale up the font size, causing contents restricted to fixed or absolute heights to be clipped. ■ Do not use CSS positioning.