Section 508 rules for application designers

An accessible application can be used by anyone, regardless of disability. Section 508 is United States federal law that requires federal buyers to purchase, use, and maintain applications that people with disabilities can access.

To support section 508, the mid tier provides DHTML information that screen readers can read out. No extra work is required by the application developer.

This information is not available by default. You must set this preference in the AR System User Preference form. It is the application developer's responsibility to adhere to the design rules specified in the following document.

Use the following rules when designing your forms to ensure a successful interaction for No Vision and Low Vision users:

Design your application with accessibility in mind

Users who can access your application only with a keyboard cannot use the mouse to jump from one area to another. Nor can they see your form layout, which can convey information to the sighted user.

If you design forms with accessibility in mind, you will avoid problems later in the project.

Make all tasks and interaction available using the keyboard

Make sure that all tasks and interactions are available using the keyboard. Mouse-only interactions should not be allowed.
For example, both Windows and the Web enable users to use a keyboard to open a menu associated with a field. On Windows, press Alt+M in the edit field. On the mid tier, tab to the menu icon and press Enter.

If you support multiple platforms, position field labels to the left of the input boxes

To avoid having the wrong label associated with an edit field, also consider the horizontal and vertical alignment with respect to other fields.

Make sure that all fields have a label

No Vision users must have a context in which to associate an edit field without a label because they depend on the screen reader for interpreting the form. Do not position a text field as a label for a field because screen readers do not read text fields in Forms mode on the Web.

Do not use the same label for multiple fields on a form

No Vision users cannot hear trim text used to distinguish one field from another.

Indicate all required fields with bold type and an asterisk at the end of the field

If the required field also includes a ➕️ sign, the asterisk must come before the plus sign. Both the asterisk and plus sign are bold.

In the following example, JAWS does not read the asterisk because it is placed after the plus sign. Because sight-impaired users cannot see the screen, they will not know that the fields shown are required.

When the asterisk is placed before the plus sign, JAWS reads the asterisk, which tells users that these fields are required.

Use of the asterisk and the order of * and + are BMC Remedy conventions. They do not have to be followed, but using them provides consistency with other BMC Remedy applications.

Provide a descriptive alt attribute for graphics and images such as icons

In the following example, an alt attribute provides a description of the graphic that can be read by a screen reader.

If an image is not meaningful to users with visual impairments (for example, an image for aesthetic purposes only), the alt attribute must have a null value (alt="").

You can add alt text to images and graphics in Remedy Developer Studio. For No Vision Web users, expand boxes and menu images have title text dynamically associated with them. As users tab through the fields on a form, they know that an expand box or a menu is associated with the field.

Expand boxes and menu images are read on the Windows client when a field is tabbed into, and users can access them with shortcut keys.

Do not use images with text to convey information

No Vision users do not hear text on images.

Make sure that the tab order in forms is set correctly

The BMC Remedy convention is a tab order from top left to bottom right. In a column of fields, the tab order is top to bottom. You can order tabs differently depending on the form. What is important is that the tab order layout makes sense.

Note

Each view has its own tab order. If you create multiple views of a form, verify that the tab order is set correctly in every view.

Use a descriptive name for the singular alias

When a window is opened, its title is read. The singular alias is part of the title in both windows and dialog boxes. When the focus is switched between windows, the window title is read so that users know which window currently has focus.

Sometimes a form is designed with a page title, which describes the contents of the page. Screen readers do not always read the descriptive information reliably.

Set the focus in a form to the first readable field

In the following example, Company is the first readable field in the form.

Allow users more time to complete a timed task

To verify that No Vision users have enough time to complete an action, look at usage of the onInterval active link condition.

Increase the session timeout for each No Vision user.

Make sure that data represented with a graphic file is available in an alternative format that a screen reader can understand

This includes spreadsheets, HTML, and any other format that a screen reader can read.

Collapse trees for initial view

When defining a tree, if Initial Row Selection is set to Select First, the first tree node is displayed as opened and the first item is selected. No Vision users must close the node or tab through all the opened items and nodes. Consider setting the Initial and Refresh option to No Selection.

Provide skip links in forms

Because No Vision users can set focus only with the keyboard, they are at the mercy of the defined tab order. Consider offering links in the form to allow the No Vision user to skip blocks of fields.

Provide only one skip link per form. Add a skip link for keyboard users to bypass repetitive links.

In HTML, place the bold tag outside the label tag.

If you generate your own HTML, place the (bold) tag outside of the <label> tag. Otherwise, JAWS does not handle the label correctly.

Correct:
<label>my label</label>

Incorrect:
<label>my label</label>

Avoid displaying Header Text II and System fonts in italic if magnification software will be used

When using ZoomText with the magnification set to 4 or higher, italicized text becomes distorted and cannot be easily read. This appears to be an issue with italic fonts when assistive technologies are used.

To achieve consistency across all clients, modify your preferences in BMC Remedy Developer Studio for Header Text II and System fonts to remove the italic.

Comment out .f10 and .f3 style in the arsystem.css stylesheet. This applies changes to System and Header Text II fonts for all users.
Removing the italic attribute is the easiest way to get readable text when using a screen magnification program.

Do not use color to convey information

Because No Vision users cannot see the screen, do not use color to highlight important information. In the following example, No Vision users do not hear the warning because it is trim text and cannot be read by the screen reader.

You can also use Results color in table fields and trees. Keep in mind that No Vision users cannot see your use of color.

If your form uses color, make sure the contrast between the different colors works for a low vision user.

Do not use shared fields in a page holder

The Web tab order is not correct when shared fields are used in a page holder.

Disable the wait cursor in the mid tier for all users

Section 1194.22, Paragraph J, of the Section 508 guidelines addresses screen flicker for people with photosensitive epilepsy. By default, the wait cursor is enabled.

By modifying the config.properties file, you can turn off the wait cursor for all users. You can also modify the image used for the wait cursor. For more information, see BMC-Remedy-Mid-Tier-configuration.

Provide alternative information if Flex widget doesn't support accessibility

When compiling a Flex widget, you can turn on accessibility. If accessibility is not enabled, provide an alternative way of showing the same information. For example instead of displaying data graphically, you could display the data in a table. If possible, make this view the default view for accessible users.

Avoid using tables within an RTF field, except for layout purposes

In rich text field (RTF) fields, key sequences do not always behave consistently in tables within RTF fields.

Make sure that the State_Action of the floating panels is indicated

A floating panel is created by explicitly marking a panel or panel holder to create a new layer when it is displayed. The Float Style determines the interaction style and location of the floating panel.

For more information about panels and panel holders, see "Panels and Panel holders" in Fields-and-No-Vision-support.

Panels which are used as tooltips can be dismissed using the ESC key. Dialog Panels can be dismissed using workflow to dismiss the panel. Make sure the state of the Floating Panels is indicated. Each panel announces the state when the panel is expanded or collapse in a stack based panel holder. Developers should make sure the context to signify the state or action of the panel has been applied while designing the form (such as Show Content/ Hide Content).

Developers should provide information to users on availability of the Tooltip Floating Panels

Tooltip Floating panels can be triggered by pressing Alt+F12 for Low Vision or No Vision users. Likewise, the Esc key dismisses the tooltip panels.

Developers should make sure that Low Vision or No Vision users understand where tooltips are applicable, as well as the usage of Alt+F12 to display the tooltips. This can be done by adding additional text as ALT text to instruct the user.

Use the on-click attribute in view fields with cell-based tables

If you want users to be able to tab to the anchor tab in a view field with a cell-based table, add the on-click attribute to the anchor tab in the template.