Considering Accessibility for Fluid Pages
When building any application, developers need to consider accessibility requirements always. This topic describes some key concepts to keep in mind with regard to accessibility while developing fluid pages.
For more information on accessibility for PeopleSoft applications in general, see Accessibility in PeopleSoft Applications.
Accessibility Consideration |
Description |
---|---|
ARIA live regions |
Use Accessible Rich Internet Applications (ARIA) live regions sparingly. |
Background and foreground colors |
If you specify a foreground color, it is strongly recommended that you also specify a background color and vice versa. Otherwise, users changing their system colors may produce invisible text. Also, be cautious when using any of the following CSS techniques:
These all make it difficult to test for color contrast, if not applied appropriately. |
Background images |
Do not use background images for informational icons. They are not visible in high contrast mode. Only do this for decorative images. |
Button or hyperlink row actions |
If you have a button or hyperlink and the control is used for a row action, you must supply a translatable label for the item regardless of whether it's visible or hidden. This label is needed for screen reader users. |
Consistency with images and control labels |
Use images and controls consistently throughout your application. For example, do not include a button labeled "Search" on one page and a button labeled "Find" on another page of the same application. |
Creating custom controls |
If you create a custom control using HTML Area, which is discouraged, the "Name, Role, Value" rule has to be in place. For example:
|
Drag-and-drop |
If you are employing drag-and-drop capabilities on your page, you must also provide the ability to perform the same functions for users using the keyboard only. For example, with homepage personalization, users can drag-and-drop tiles into their own specific layout and order. For non-sighted users, who cannot use drag-and-drop, a Personalize Homepage interface is available where users can also use the keyboard to arrange pagelets. |
Dynamic information |
User should be able to stop, pause, hide information that is moving, blinking, or auto-updated if:
|
Focus indicator |
An end user must be able to see when focus is set for a control, for example a box surrounding the widget:
|
Group box pop-up menus |
Use only the techniques described in Creating Fluid Pop-up Menus to create pop-up menus on fluid pages. |
Hidden fields |
When a fields is not visible (for example, within closed accordion content or within group box that is itself set as invisible), the field should not be tab-able. It also must not be set to have focus. |
HTML areas |
The controls in an HTML area must be able to be operated using the keyboard only, with no reliance on the mouse. Use |
Links versus buttons |
Use links for transferring users to a different location; use buttons for actions on the current page. |
List items |
List items must have one interactive field only, which becomes the target of the row action for the list item. In addition, limit the number of display-only fields (attributes) to three or less per list item. Because each list item is treated as a single cell, all of the fields are read by the screen reader for each list item when it is selected. More than four fields presents too much information for the reader to retain and act on. If you must present more than four fields, create a grid instead of a list. That way, each grid cell can be read individually. |
Lists |
If you have a list, use list grid layout to render it, because it is a list, not a table, you are presenting. In addition, when you have only one column, it is not a table, it is a list. If you want to show how many items are in the list, do not use the word "rows" for the counter. Row implies tables, which is confusing for screen reader users. |
Plug-ins |
If you use plug-ins, verify that content rendered with those plug-ins is accessible. |
Read-only group box content |
For group boxes that contain read-only elements and have a row action, it is recommended to add an aria-label and set the role using PeopleCode:
|
Row headers |
Fluid pages should specify a row header for tables, specified in Application Designer. Use the Row Header property on the Grid Properties > Use tab. |
Screen reader mode |
|
Sensory descriptors |
Avoid instructions with sensory characteristics or descriptions of page elements, such as:
Use field identification instead to point users to page elements. |
Table summaries |
Provide table summaries for table. Use Application Designer to populate them. Use the Summary attribute for Accessibility property on the Grid Properties > Use tab. |
Tab order and field focus |
With fluid pages, the tab order cannot be set by the application developer, unlike classic pages. The tab order is based strictly on a top-to-bottom, left-to-right sequence. For fluid pages, design in such a way that the logical tab order is maintained as much as possible, leveraging group boxes to gather page elements together as necessary. Pay attention to field focus by tabbing to make sure the tab order is in a logical sequence. Pay close attention to these situations:
|
Testing |
Perform the following additional testing:
|
Toggle buttons |
If you have a toggle button with different visual styles for on and off, you should do one of the following:
|