Section 508 guidelines for application design and testing

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.

The Web modifies the form and form content for No Vision and Low Vision users. However, application designers must still make sure that the forms they design have the visually impaired user in mind. (For example, in forms, avoid using multi-level character menus whenever possible. No Vision users must go through menus and submenus to choose a menu item.) If the forms are not easy to use, No Vision and Low Vision users will not use the application.

A good reference for Web forms is WAI Web Content Accessibility Curriculum (https://www.w3.org/WAI/wcag-curric/). This site summarizes guidelines for accommodating No Vision users.

Application developers must ensure that all custom HTML and client script code (such as text in a view field or JSP page modifications) is compliant with accessibility requirements.

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

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.

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

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.

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

If the required field also includes a plus (+) 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 Helix ITSM conventions. They do not have to be followed, but using them provides consistency with other BMC Helix ITSM applications.

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 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.

No Vision users do not hear text on images. 

The BMC Helix ITSM 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.

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.

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

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.

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.

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.

Disable the wait cursor in the Mid Tier for all users.

Consider Mid Tier caching when creating forms.

When a view of a form is requested, the Mid Tier caches a copy of the form. When the next user requests the same form, the Mid Tier checks for a cached copy of the form.

Because HTML is generated dynamically for No Vision and Low Vision users, the cache could include multiple copies of the form. Consider potential increases in memory usage when creating forms for No Vision and Low Vision users.