Provide text through standard system function calls or through an API (application programming interface) which supports interaction with assistive technology.


Rationale

Screen readers determine what software is doing by watching calls to drawing functions and remembering what text and graphics have been drawn and where. Screen readers also save attributes of the text such as font, size, color, and style, to be reported to the user. They also watch information being copied from one location to another and being erased or overwritten by other text or graphics.

The component in a screen reader that does all this work is called an off-screen model (OSM). OSM's rely on being able to monitor normal system drawing operations. Screen readers use the OSM to get information such as text content, text input caret location, and text attributes. If text is displayed in a non-standard way, the screen reader may not be able to detect it and read it to a blind user.


Required development techniques


The following techniques are the minimum required to meet Checkpoint 4.1 from the IBM Software Accessibility Checklist:

  1. The minimum information that must be provided about the text is text content, input caret location and attributes.
  2. Display text using standard program interfaces.
  3. Use standard functions to copy or erase text and graphics.
  4. Do not directly modify the screen.

Examples for Microsoft Windows developers

  1. The minimum information that must be provided about the text is text content, input caret location and attributes.

    Example 1

    If an "About" box is provided, it must be accessible including product version number and copyright information. Splash screens that are displayed briefly when an application is loading are not required to be accessible if the version and copyright information in the splash screen is also available in an accessible "About" dialog box. Providing accessible text allows a screen reader to read it to a user and will make it more readable when magnified with a screen magnifier, as in the example below:

    An accessible about box.
  2. Display text using standard program interfaces.

    Example 2

    Use the standard Windows program interfaces to display text, inluding ExtTextOut, TextOut and DrawText . See font and text functions for more information on the use of the standard text functions.

  3. Use standard functions to copy or erase text and graphics.

    Example 3

    For Windows systems, these APIs include BitBlt, PatBlt, and StretchBlt . You need to do this whether drawing to a screen or to an off-screen bitmap, because screen readers track the text and graphics from the time they are drawn until they are copied to the screen.

  4. Do not directly modify the screen.

    Example 4

    Some applications directly manipulate the memory associated with a device context, bypassing the system functions altogether. In these cases screen readers are not aware of the changes taking place and the application is not accessible.

    Example 5

    The following Windows APIs should be avoided since they manipulate bitmaps or display pixels directly: DirectDraw, Display Control Interface (DCI), WinG, and CreateDIBSection .

Examples for Eclipse SWT developers

  1. The minimum information that must be provided about the text is text content, input caret location and attributes.

    Example 1

    For text widget the accessible attributes for text content, input caret location are set properly, no additional action is required by the application. For custom developed text controls the accessible attribute support must be set using the org.eclipse.swt.accessibility class support.

  2. Display text using standard program interfaces.

    Example 2

    When possible use the standard SWT text widget for text support, for example:

    Text text = new Text (shell, SWT.BORDER);

  3. Use standard functions to copy or erase text and graphics.

    Example 3

    Examples for this technique to be developed.

  4. Do not directly modify the screen.

    Example 4

    Some applications directly manipulate the memory associated with a device context, bypassing the system functions altogether. In these cases screen readers are not aware of the changes taking place and the application is not accessible.

Examples for iOS developers

  1. The minimum information that must be provided about the text is text content, input caret location and attributes.

    Example 5

    Text field and text view are accessible. The developer must set the Accessibility attribute. Text content, input caret location, and other attributes are set properly; no additional action is required by the application.

    For custom developed text controls the accessible attribute support must implement the full NSTextInputClient protocol. See Apple documentation on Creating Custom Views (link resides outside of ibm.com).

  2. Display text using standard program interfaces.

    Example 2

    Use the standard iOS UI elements to display text.

  3. Use standard functions to copy or erase text and graphics.

    Example 3

    For iOS, use UIPasteboard, UIMenuController, UIResponder, and UIResponderStandardEditActions Protocol. See Copy, Cut, and Paste Operations (link resides outside of ibm.com)

  4. Do not directly modify the screen.

    Example 4

    Some applications directly manipulate the memory associated with a device context, bypassing the system functions altogether. In these cases screen readers are not aware of the changes taking place and the application is not accessible.

Required test techniques

Test the software to ensure that it complies with accessibility requirements.

Test software

Install the following software as needed to test this checkpoint.

  • A screen reader

Test techniques

The following test techniques are required to verify this checkpoint.



Action Results

With a screen reader active, navigate to all text content and every user interface element. (Use Tab, the Arrow keys, and any other application specific navigation keys to move to all text, controls and objects.)

Pass:

Fail:

Debug techniques

If the screen reader test fails for any user interface element, the problem must be debugged with an accessibility API validation tool. These techniques can be used to help determine if a problem is caused by a coding error in the application, or if it is caused by a screen reader defect.


The following techniques are required to verify this checkpoint:
Action Results for compliance
  1. Review the development techniques and ensure the implementation is correct according to the development techniques.
  2. Use the API validation tool that is appropriate to your product to determine if the development techniques have been implemented properly.

Additional information on how to use the API validation tool is included with the tool.

  1. The implementation is correct according to the development techniques.
  2. The accessibility API validation tool shows that the API properties expose sufficient information as defined in the development techniques for this checkpoint.
  3. Additional instructions:

©2009, 2013 IBM Corporation

Last updated January 28, 2013.