Checkpoint 11.3.2.3: Use of Accessibility Services

Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.

Rationale

Interoperability with assistive technology (AT) such as a screen reader, screen magnifier, speech recognition software or a Braille display is only possible for software applications that use accessibility services that are documented for that purpose. Each software platform has its own accessibility services, also known as accessibility APIs, that are either documented by the platform or developed as standardized extensions to the platform API's. These API's give applications a way to provide the required accessibility information and make it available to the ATs.  The AT then uses the platform accessibility services to query the accessibility information as well as allow AT interaction with the UI elements in the application.  

By using the platform accessibility services, an application can provide information about user interface elements such as the name, role, value, state, and property information as well as methods to insert text, follow or move the focus, perform actions on UI elements, and so on.

Note: Clauses 11.3.2.5 to 11.3.2.17 referenced in this EN 301 549 requirement are equivalent to the Revised 508 Standards requirements documented in checkpoints 502.3.1 through 502.3.14.

Note: The IBM compliance reporting system will be able to convey compliance status with European EN 301 549/Mandate 376: Accessibility requirements suitable for public procurement of ICT products and services in Europe. IBM accessibility checkpoints for the Revised Section 508 standard cover most of the EN 301 549 requirements. However, this is one of a set of additional checkpoints that must be completed to fully report compliance with the European standard.

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: Items in this section represent techniques which can be used to achieve this checkpoint.

  • Using documented platform accessibility APIs
  • Where platform accessibility APIs have gaps in accessibility support, using additional documented accessibility APIs
  • Using toolkits that incorporate the use of documented accessibility APIs

Mobile Native (iOS) techniques

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

Meet General technique "Using documented platform accessibility APIs" with:

Meet General technique "Using toolkits that incorporate the use of documented accessibility APIs" with:

Using standard native iOS UI controls

Native iOS UI controls from the UIKit framework have the accessibility API built-in so that developers won’t need to do additional work to provide the accessibility API support. Refer to the iOS section of checkpoints 502.3.1 through 502.3.14 for the detailed implementation and requirements needed for AT interoperability.

On custom controls, using the UI Accessibility informal protocol to meet AT interoperability requirements

Refer to the UI Accessibility API Reference and checkpoints 502.3.1 through 502.3.14 for the detailed implementation instructions and requirements for AT interoperability.

Eclipse techniques

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

Meet General technique "Using toolkits that incorporate the use of documented accessibility APIs" with:

Using the built-in Eclipse accessibility API features to meet AT interoperability requirements

The org.eclipse.swt.accessibility package provides the Eclipse application programmer with a set of facilities designed to enable the application for interoperability with assistive technologies on Windows® and Linux®. All accessibility support in Eclipse flows through org.eclipse.swt.accessibility, which contains platform-specific code for talking to the accessibility API on the underlying platform. Eclipse’s built-in capabilities support both the MSAA and the IAccessible2 API's.

Windows-based (MSAA+IA2) techniques

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

Meet General technique "Using documented platform accessibility APIs" with any of the following:

Using standard native Windows UI controls

Most Windows standard UI elements have the accessibility APIs built-in without any additional work. Simply provide the accessibility information such as the role, state, name, and so on as described in the documentation. Refer to checkpoints 502.3.1 through 502.3.14 for the detailed implementation and requirements.

Using Microsoft Active Accessibility (MSAA) along with IAccessible2, as needed, to meet AT interoperability requirements

Software can extend or modify the behavior of standard Windows controls to create a custom control by sub-classing, or super-classing the standard control. In these cases, either MSAA with IAccessible2 or Microsoft UI Automation can be used to provide the accessibility layer needed for AT interoperability.

Checkpoints 502.3.1 through 502.3.14 provide the requirements and details on how to correctly implement UI elements using MSAA and IAccesible2.

On custom controls, using Microsoft UI Automation (UIA) to provide accessibility information

Microsoft created UIA to be a more robust API for providing full AT interoperability capabilities and address the limitations in MSAA. Refer to the UI Automation Specification for more details about this accessibility API. Checkpoints 502.3.1 through 502.3.14 contain the requirements that must be met by the Windows application and use UIA to implement the accessibility support for those requirements.


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