About CIA

 

Section 3. Text

Accessibility Score Sheet Questions

3.1    Is ALT text or other text equivalent provided for all non-text elements with content?

3.2    Are links visually distinct with text that explains what will happen when the link is clicked?

3.3    Are all controls, feedback mechanisms, status indicators, etc. meaningfully and consistently labeled throughout the interface?

3.4    Do field labels indicate mandatory format, length, or values and if the field is required?

3.5    Are all decorative elements coded as decorative?

Rationale

Applications must provide information about interface elements so assistive technology (e.g. screen reader) can identify the focus object as well as its role (operation) and state. For example, when the focus in a form is on a radio button object, an assistive technology user needs to know that the object is a radio button, the label of the radio button group, the label for that particular radio button, and whether it is checked or not. Examples of user interface elements that require text equivalents include: checkboxes, menus, toolbars, form fields, scroll bars, buttons, applets, scripts, and any other object or feature of a program that is intended to allow the user to perform some action. Non-text elements which require text equivalents include: images, graphics, audio clips, or other features that convey meaning or indicate an action through sight or hearing. Elements which are decorative need to be coded appropriately so a screen reader skips over them.

In addition, buttons, icons and other controls need to be consistently labeled to facilitate voice commands and other navigation by assistive technology. Most screen reading programs allow users to assign text names to images. If the image changes meaning during a program’s execution, the assigned identifier is no longer valid and is confusing to the user. Consistent text use also facilitates navigating with voice recognition – for example, the user can say click “home page” for the image whose alternative text is “home page.” If the different words are used for the same action or the same word is used for different actions, it can cause confusion and make it difficult to program shortcuts into the assistive technology.

Scripts also need to be labeled with descriptive text. Without this text accompanying a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used.

The use of labels and alternative text is not just for people who have visual impairments; alternative text is also used by text-only browsers, display-less devices, and by search engines. Consistent labels, images, buttons, etc. supports anyone learning an application.

Test Approach

1a. Run an initial test using a browser toolbar (Errors, Features and Alerts in WAVE; Text Equivalents menu in FF Accessibility Toolbar). Note any items that do not have alt text. If they are decorative, note this as correct for 3.5. If they convey content, note these to be fixed for 3.1.

Note: Content may be off-screen and picked up by the toolbar. This can be confusing. Focus on what is visible on the screen you are testing.

1b. With JAWS turned OFF, mouse click on the text for all form fields, radio buttons, and checkboxes. If labels are correctly associated, the focus should move to the field or activate the checkbox/radio button.

1c. With JAWS turned ON, move the focus to icons, buttons, images, etc. (Insert-F5 lists form fields, Insert-Ctrl-G lists images) and ensure JAWS reads text that clearly explains what the objects are and do.

2a.Visually inspect the page. Can you easily visually identify the links? Links should either be located in standard navigation areas (top navigation, sidebar, etc.), underlined, or have a 3:1 contrast ratio compared to body text and be underlined on hover.

2b. List links in the Accessibility Toolbar or in JAWS (INSERT+F7).

  • Can the text displayed be understood out of context?
  • Text like “More” or “Click Here” within the href tags makes no sense out of context.

2c. Test to see if any links act in a way that is unexpected (i.e. they don’t link to a new web page). In this case, text on the link should include a description of what to expect.

3a. To get an idea of the complexity of the application’s interface:

  • How many UI developers work on the project?
  • If more than 3, do you have a user interface standards document that you test against?
  • If so, does the interface meet the standards?

3b. Compare labels, titles, and controls on all the test pages for consistency.

If you have a UI Standards document, include a link to the document in the notes section.

4. With JAWS turned ON, inspect field labels. Are required fields indicated in text in a location (label, hint, or help) that assistive technology can read? If a mandatory format such as a date format is required, is it indicated in text in a location (label, hint, or help) that assistive technology can read?

5. With JAWS turned off use the FireFox accessibility toolbar to hide background images (Text Equivalents > Hide Background Images). Identify any decorative images that are not hidden. With JAWS turned on, examine any decorative elements. Are images that have no content read by the screen reader or skipped?

  • Use INSERT+Num Pad Plus to turn on the virtual cursor. This allows you to navigate around a page independent of the application cursor. Use the arrow keys to move around the text on the page.

Development Techniques

Both Client Applications and Web Browser Applications:

  • Create a standard list of controls used with consistent labels, icons, and behaviors and test against it.
  • Avoid having multiple elements with the same name on the same form or dialog if they do not perform the same function.
  • Place text labels immediately to the left or immediately above the element. Screen readers use proximity to identify labels if they are not exposed programmatically.
  • The text information associated with a non-text element should, when possible, communicate the same information as its associated element.
  • When interacting with a non-text element moves the focus to a different part of the page, a new page, a new window, a PDF document, etc., include text that alerts them of this change.

Web Pages/Applications:

  • Use text labels and heading structure (H1 for page header, H2 for section header, etc.) to help the reader understand the structure and organization.
  • Use aria-required=”true” to indicate required fields.
  • Use the id, name, alt and value attributes in html for form elements as appropriate.
  • Use the “LABEL” Tag and Associated “FOR” Attribute to Tag Labels.
  • Provide alt text for non-text elements that perform an action, provide context or information, or link to other areas. Alternative text and labels should be meaningful and make sense out of context. Avoid “Click here,” “image” or other vague instructions.
  • Web page authors often utilize transparent graphics for spacing. Adding a text description to these elements will produce unnecessary clutter for users of screen readers.
  • Use an empty alt tag (alt=””) for images that are purely decoration or are redundant. The empty “” tells assistive technology not to read the graphic.
  • Java Applets: The tag for Java applets also accepts an “alt” attribute, but it only works for browsers that provide support for Java. Often, users with slower internet connections will turn support for Java applets off. A better alternative for providing textual descriptions is to simply include the alternative text between opening and closing or tags.

Client Applications:

  • Minimize client side scripting. For scripting that is needed, include an informative description of the script along with the code. This may be included in the link or image that initiates the script.
  • A label must be associated programmatically with an object in order for assistive technology to make the object available to the user. The text must identify the element and its current state or condition. For example, a button that shows a hand for getting more help must have the word “help” associated with the button. If a checkbox is present, a text label must indicate what is being checked, and whether the checkbox is checked or unchecked.
  • The easiest way to provide object information in Windows software is through the use of standard Windows controls. No additional work is required to expose the role and state for standard Windows controls.
  • Use the standard Windows tooltip control to apply a label to each image.
  • When standard Windows controls aren’t available use MSAA. If the Windows software uses non-standard controls, MSAA is a method of exposing object information and the name and description of each image.
  • If the application does not support MSAA, the following steps can help make a control more compatible, but not fully compatible, with accessibility aids. If the custom control has its own window, you can return a descriptive string when the control is queried using the WM_GETTEXT message. For example, a control that appears as a button with the label Print could return the string “Print button” to convey both the control type and the label. The same string would be appropriate if the control looked like a button but had a graphic showing a printer rather than a textual label. Likewise, a custom control that behaves like a check box could return a caption string “Printing Enabled check box, checked.”

Posted: Jan 07, 2016 12:41 PM
Last Updated: Jan 07, 2016 12:41 PM