The content of text objects, text attributes, and the boundary of text rendered to the screen, shall be programmatically determinable.

Rationale

Users depend on Assistive Technology (AT) to relay programmatic information to them about text content and attributes. If text is editable, AT users also need the ability to interact with the text content. The AT uses the required programmatic text attributes to describe the text styling to the user. When the text is editable, the caret focus, text selection and text boundaries must also be made programmatically available to the AT.

Note: The selection and manipulation of text involves considerations for several checkpoints. Depending on circumstances, such as whether text is static, read-only or fully editable, similar techniques may be cited by each of a set of checkpoints. These are:

Development Techniques

Note: Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first.

General techniques

Instructions: Where applicable, each item in this section represents a technique deemed sufficient.

  • Providing text through standard system function calls
  • Implementing Accessibility APIs for standard and custom controls (see supplement)
  • When the rich text is editable, programmatically exposing the caret focus, text selection, and text boundaries

Implementing Accessibility APIs for standard and custom controls

Some basic widgets that provide text such as buttons, labels and menuItems require no additional coding to properly expose their textual information to assistive technology. For text widgets, standard and custom, that provide selection, copying, and spell checking and/or language support, additional interfaces must be implemented. See individual technologies for the techniques required.

Mobile Native (iOS) techniques

Instructions: In addition to the General techniques, any item in this section represents a technique deemed sufficient.

Making sure text contents, text attributes, and the boundary of text rendered to the screen are programmatically determinable

The text and text attributes of UIKit Text Fields and Text Views are exposed without needing additional code. Boundaries are determined by the view coordinates. Text attributes can be changed in the attributedText instance property.

Eclipse techniques

Instructions: In addition to the General techniques, these techniques are deemed sufficient in the following situations when used as instructed.

Meet "Provide text through standard system function calls or through an API which supports interaction with assistive technology" with one of the following:

Meet “Implementing Accessibility APIs for standard and custom controls” through the following, where applicable:

Providing information about text content, input caret location and attributes

For a text widget, the accessible attributes for text content and the 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.

Displaying text using standard program interfaces

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

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

Not directly modifying the screen

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.

Create a StyledText widget

Eclipse provides the org.eclipse.swt.custom.StyledText widget, an editable user interface object that displays lines of text. Applications that utilize this widget will receive accessibility coverage for this checkpoint "at no additional cost."  Other custom editors and text-based widgets, need to implement additional interfaces to be made accessible. For these custom editors, see the following techniques.

StyledText text = new StyledText(shell, SWT.SINGLE | SWT.BORDER);

text.setText("Sets a text into StyledText widget");

Identify text area to assistive technology as text

  1. Move focus to the text area and expose the focus information to assistive technology (AT) as outlined in checkpoint (502.3.12 Focus Cursor).
  2. Return a role of ROLE_TEXT or ROLE_DOCUMENT for the text area.
  3. A text area with a role of ROLE_TEXT must return a state of STATE_MULTILINE if it spans multiple lines.
  4. Text areas may return a state of STATE_READONLY.

Notes:

  • As outlined in checkpoint (502.3.1 Object Information) roles and states are returned through getRole and getState methods of the org.eclipse.swt.accessibility.AccessibleControlListener.
  • Although it is implied that objects with a state of STATE_READONLY and a role of either ROLE_TEXT or ROLE_DOCUMENT support keyboard access to navigate text content, keyboard navigation support of read only objects is not a requirement to meet this checkpoint.

Implementing AccessibleTextListener and AccessibleTextExtendedListener

Implement org.eclipse.swt.accessibility.AccessibleTextListener and org.eclipse.swt.accessibility.AccessibleTextExtendedListener interfaces and add the listeners to the custom text control to expose the text area to Assistive Technologies (ATs).

Along with implementing these interfaces ensure the following access to the text control:

  • Implement the expected caret movement and text selection. See Keyboard Access section of the IAccessible2 Implementation Guide  for full details on the essential keyboard access for screen reader users.
  • Provide the caret to the AT through the getCaretOffset method of the AccessibleTextListener and notify the AT every time the caret moves through the textCaretMoved helper method of the org.eclipse.swt.accessibility.Accessible object as outlined in checkpoint (502.3.14 Event Notification).
  • Support the AT's getting of text through the getText and getCharacterCount of org.eclipse.swt.accessibility.AccessibleTextExtendedListener .
  • Support AT request for text at a given boundary through getRanges method of the org.eclipse.swt.accessibility.AccessibleTextExtendedListener.
  • Expose automatically inserted characters through the getText and getRanges methods of org.eclipse.swt.accessibility.AccessibleTextExtendedListener according to the cases outlined in the Automatically Inserted Characters section of the IAccessible2 Implementation Guide.
  • Expose embedded objects such as lists, tables, links, graphics and headings through the inclusion of embed characters, Unicode 0xFFFC, and implementation of the getHyperlink, getHyperlinkCount and getHyperlinkIndex methods of the org.eclipse.swt.accessibility.AccessibleTextExtendedListener.  The embed character indicates to the screen reader that the text contains an embedded object. The AT will first ask for the index to the embedded object and then will call getHyperlink to retrieve the accessible of the embedded object. The embedded object must implement org.eclipse.swt.accessibility.AccessibleHyperlinkListener and org.eclipse.swt.accessibility.AccessibleControlListener returning its role through the getRole method. For further discussion on how ATs detect and retrieve embedded objects, see the Embed Characters section of the IAccessible2 Implementation Guide.
  • Provide the ability for ATs to retrieve selected text through the getSelection method of the org.eclipse.swt.accessibility.AccessibleTextExtendedListener.
  • Return the text attributes for a range of text through the getTextAttributes method of the org.eclipse.swt.accessibility.AccessibleAttributeListener.

Implement AccessibleEditableTextListener

The org.eclipse.swt.accessibility.AccessibleEditableTextListener interface complements the AccessibleTextListener and AccessibleTextExtendedListener interfaces and provides clipboard level functionality for text areas. Since read only text areas can support copy functionality, this interface is not limited to editable text.

For all text areas, implement the copyText method.

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, refer to the Windows techniques tab in checkpoint 502.3.1 Object Information to learn about accessibility APIs, and use the following to support Windows accessibilty.

Displaying text using standard program interfaces

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

Not directly modifying the screen

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.

Note: When "Providing text through standard system function calls," the following Windows APIs should be avoided since they manipulate bitmaps or display pixels directly: DirectDraw, Display Control Interface (DCI), WinG, and CreateDIBSection.

 

Identifying IAccessibleText model used through IAccessible2:attributes

Since different text models may be used by different editable text controls, it is important to set the appropriate text-model in the IAccessible2::attributes. For example, text-model:a1 indicates that the IAccessibleText model A version 1 is being used. See IAccessibleText model section of the IAccessible2 Implementation Guide for further details.

Identifying text area to assistive technology as text

  1. Move focus to the text area and expose the focus information to assistive technology (AT) as outlined in checkpoint (502.3.12 Focus Cursor).
  2. Return a role of ROLE_SYSTEM_TEXT or ROLE_SYSTEM_DOCUMENT for the text area through the IAccessible object as outlined in checkpoint (502.3.1 Object Information). See Object Roles (link lies outside ibm.com) for further details.
  3. A text area with a role of ROLE_SYSTEM_TEXT must return a state of IA2_STATE_MULTI_LINE if it spans multiple lines.
  4. A text area with a role of ROLE_SYSTEM_DOCUMENT must return a state of IA2_STATE_EDITABLE and it is implied that it spans multiple lines.
  5. Text areas may return a state of STATE_SYSTEM_READONLY

Notes:

  • Although it is implied that objects with a state of STATE_SYSTEM_READONLY and a role of either ROLE_SYSTEM_TEXT or ROLE_SYSTEM_DOCUMENT support keyboard access to navigate  text content, keyboard navigation support of read only objects is not a requirement to meet this checkpoint.
  • IA2States are returned through the IAccessible2::states parameter of the IAccessible2 object while MSAA states are returned through the get_accState method of the IAccessible object.

Implementing IAccessibleText

Text areas must implement IAccessibleText interface to expose the text area to Assistive Technologies (ATs).

The IAccessible2 Implementation Guide outlines the considerations to follow when exposing a text area to an AT through the IAccessibleText interface. These are summarized in this list:

  • Implement the expected caret movement and text selection Keyboard Access. See Keyboard Access section of the implementation guide.
  • Provide the caret to the AT through IAccessibleText::caretOffset and notify the AT everytime the caret moves through IA2_EVENT_TEXT_CARET_MOVED.
  • Support the AT's getting of text through IAccessibleText::nCharacters and IAccessibleText::text.
  • Support AT request for text at a given boundary through IAccessibleText::textAtOffset and IATextBoundaryType.
  • Expose Automatically inserted characters
  • Expose Embedded objects such as Lists, Table, Links, Graphics, and Headings through the inclusion of embed characters and the support of the IAccessibleHyperText object. In addition, all embedded objects must support the IAccessibleHyperlink interface. See the IAccessible2 Implementation Guide on Embed Characteristics for full details on using these two interfaces to expose embedded objects to ATs.
  • Provide the ability for ATs to retrieve selected text through the IAccessibleText::selection function.
  • Return the text attributes for a range of text through the getTextAttributes method of the org.eclipse.swt.accessibility.AccessibleAttributeListener.

Note: IAccessibleText2 extends IAccessibleText and IAccessibleHyperText2 extends IAccessibleHyperText.

Implementing IAccessibleEditableText for editable text

The IAccessibleEditableText interface complements the IAccessibleText interface and provides clipboard level functionality for text areas. Since read only text areas can support copy functionality, this interface is not limited to editable text.

For all text areas, implement the copyText method.


Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation