Considering Accessibility for Fluid Pages

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:

• Background images

• Gradients

• RGBA (transparent or semi-transparent) colors

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:

• Custom controls need a meaningful programmatically exposed name.

• Custom controls have appropriate roles specified using the role attribute.

• Custom controls have an appropriate value or state and property information conveyed using the relevant WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) or HTML 5 attributes.

Drag-and-drop

If you are leveraging drag-and-drop capabilities on your page, you must provide an accessible mechanism that non-sighted users can use. A similar mechanism must be available.

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:

• Starts automatically.

• Lasts more than five seconds.

Focus indicator

An end user must be able to see when focus is set for a control, for example a box surrounding the widget:

• If the widget is in HTML area, provide your own focus indicator.

• If you style a delivered widget in a unique way so it no longer looks like others of its kind, you also need to make sure to style a clear focus indicator.

Group box pop-ups

Do not use the word "menu" in a title for a group box pop-up. Otherwise, a screen reader user will expect keyboard actions (up, down, left, and right arrow keys) that work with menus to be available.

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 tabindex="0" for controls that are not accessible using TAB, but should be (those that can receive user input).

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:

&Fld.JavaScriptEvents = "aria-label=""Partial Days None""role=""button""";

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

• If your fluid component and classic component are exactly the same in functionality, you might want to display the classic component when a user is in fluid screen reader mode for desktop and tablet users; classic pages do not display well on smart phones. This can eliminate the need to design fluid pages for regular and screen reader mode.

• For selected list items, add the following ARIA attribute:

  aria-current="true"

• If you use styles to hide a column, ensure that you don’t hide the column in screen reader mode. If you always hide it, there will be no action available on the row. For example, the use of none in the following example is incorrect:

  :root:not(.psc_mode-access) .GRID1_EDIT,
  :root:not(.psc_mode-access) .GRID1_EDIT {
  	display:none !important
  }

Sensory descriptors

Avoid instructions with sensory characteristics or descriptions of page elements, such as:

• Color (red, blue, and so on).

• Visual location (above, below, and so on)

• Orientation (right, left)

• Size and shape (small, larger, round, arrow, and so on).

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:

• Default focus location for initial page display.

  By default, the focus will be set to the first interactive field found on the page. However, if this field is not visible because it is within an invisible element (for example, a group box that is set to invisible) or within collapsed accordion content, then focus will be lost.

• Focus location after refreshing part of a page.

• Focus location before and after pop-up windows are displayed.

Testing

Perform the following additional testing:

• Test your application in Windows high contrast mode.

• If you build your fluid application for tablets or phones, test using a native screen reader. For example, use VoiceOver (OSX native screen reader).

Toggle buttons

If you have a toggle button with different visual styles for on and off, you should do one of the following:

• Change the label of the button when on versus off.

• Code WAI-ARIA states aria-pressed="true/false".