Checkpoint 502.3.2 Modification of Object Information

States and properties that can be set by the user shall be capable of being set programmatically, including through assistive technology.

Rationale

Someone who is blind or visually impaired uses a computer with the aid of assistive technology (AT) such as a screen reader, screen magnifier, speech recognition or Braille display. Software must provide semantic information about the user interface objects to the AT. This is done through platform specific application programming interfaces (APIs) that programmatically expose information to the AT including name (identity), role (operation), state, boundary, properties and description of user interface objects.

In some instances, the assistive technology may need to set the attributes, such as states and properties, in the object information. For example, a user accessing text  through a speech recognition program may need to style the text. The AT (speech recognition program) needs to access these attributes via APIs to programmatically set the styling of the text.

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

Each item in this section represents a technique or combination of techniques deemed sufficient.

  • Where available, implementing the Accessibility APIs that allow for user-settable properties and states to be directly set by assistive technologies

Note: For software applications, meeting the required development techniques of this checkpoint and of checkpoints 502.3.1 Object Information, 502.3.4 Values, and 502.3.5 Modification of Values is sufficient for meeting the required development techniques of checkpoint 4.1.2 Name, Role, Value.

Mobile Native (iOS) techniques

In addition to the General techniques, any item in this section represents a technique or combination of techniques deemed sufficient.

Note: The following examples also meet the name and role requirements in checkpoint 4.1.2  Name, Role, Value.

Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes

Software can extend or modify the behavior of standard iOS UI controls to create a custom control by sub-classing or super-classing the standard control. The custom control created may or may not be accessible depending on how the software modified the base control to create the appearance and behavior of the custom control. Software must verify the accessible name, role, state, and, if applicable, value are accessible. This can be done using Accessibility Inspector in the xCode development environment.

Software that creates custom controls must support the UI Accessibility Protocol to expose the object label, focus location, accessibility enabled status, value, traits (roles), and status changes. Developers should refer to the Accessibility Programming Guide for iOS.

A training module on accessibility for custom controls on iOS is available on iTunesU. Search for Stanford University Course CS193D “Developing Apps for iOS," 2010 Sessions, Lecture 18: “Accessibility on iOS: Make an App for Everyone,” guest lecturer Chris Fleizach, Apple Accessibility Development team.

Creating components using a technology that supports the accessibility API features of the user agents' target platforms to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes

When using the standard iOS controls, developers must set the accessibility attribute of the control that is used as the name of the control.

In Interface Builder, this is done by selecting the Accessibility checkbox Enabled. This is found on the Identity Inspector tab.

This can be done programmatically with the setIsAccessibilityElement and setAccessibilityLabel methods:

[self.myButton setIsAccessibilityElement:YES];
[self.myButton setAccessibilityLabel: @"label text for button"];

Eclipse techniques

In addition to the General techniques, any item in this section represents a technique or combination of techniques deemed sufficient.

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, use the following to support Windows accessibilty.


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