ISO/IEC 13066-1:2011

INTERNATIONAL ISO/IEC
STANDARD 13066-1
First edition
2011-05-15
Information technology — Interoperability
with assistive technology (AT) —
Part 1:
Requirements and recommendations for
interoperability
Technologies de l'information — Interopérabilité avec les technologies
d'assistance —
Partie 1: Exigences et recommandations pour l'interopérabilité

Reference number
©
ISO/IEC 2011
©  ISO/IEC 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Terms and definitions .1
3 Conformance .5
3.1 Applying the requirements.5
3.2 Applying the recommendations.5
3.3 Evaluation of products.6
4 Framework for IT-AT interoperability .6
4.1 Assistive technology.6
4.2 Interconnection.6
5 Requirements and recommendations on hardware-to-hardware interoperability .9
5.1 Responsibilities of ICT manufacturers.9
5.2 Responsibilities of device manufacturers .10
6 Requirements and recommendations on hardware-to-software interoperability.10
6.1 Responsibilities of ICT system manufacturers .10
6.2 Responsibilities of operating system manufacturers .11
6.3 Responsibilities of device driver developers .12
6.4 Responsibilities of device manufacturers .12
7 Requirements and recommendations on software-to-software interoperability.12
7.1 Responsibilities of all software developers.12
7.2 Responsibilities of operating system and platform software developers.15
8 Support of assistive technology.15
8.1 Provision of AT-specific documentation .15
8.2 Provision of accessible help .15
8.3 Avoiding monopolizing devices .15
9 Expectations of assistive technology .16
9.1 AT responsibilities regarding the functional units they represent / replace.16
9.2 Utilizing platform accessibility services .16
Annex A (informative) Survey of accessibility application programming interfaces
(accessibility APIs).17
Bibliography.35

© ISO/IEC 2011 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 13066-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 35, User interfaces.
ISO/IEC 13066 consists of the following parts, under the general title Information technology —
Interoperability with assistive technology (AT):
⎯ Part 1: Requirements and recommendations for interoperability
The following parts are under preparation:
⎯ Part 2: Windows accessibility API [Technical Report]
⎯ Part 3: I-Accessible-2 accessibility API [Technical Report]

iv © ISO/IEC 2011 – All rights reserved

Introduction
Interoperability involves the ability to use assistive technology (AT) to add to or augment existing components
of information technology (IT) systems. Interoperability between AT and IT is best facilitated via the use of
standardized, public interfaces for all IT components.
This part of ISO/IEC 13066 provides a basis for designing and evaluating interoperability between IT and AT.
It formalizes the layered architecture of hardware-to-hardware, hardware-to-software, and software-to-
software connections that have long been implicit in the IT definitions of ISO/IEC JTC 1. It also recognizes the
central role that accessibility application programming interfaces (accessibility APIs) play in aiding this
interoperability.
This part of ISO/IEC 13066 identifies a variety of APIs that are described further in other parts of
ISO/IEC 13066. These APIs can be used as frameworks to support IT–AT interoperability.

© ISO/IEC 2011 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 13066-1:2011(E)

Information technology — Interoperability with assistive
technology (AT) —
Part 1:
Requirements and recommendations for interoperability
1 Scope
This part of ISO/IEC 13066 defines the responsibilities of different information technology (IT) and assistive
technology (AT) functional units in supporting interoperability. It recognizes that AT can be provided both as
functional units that are installed or otherwise connected to a system or can be utilized by being provided as a
service which is accessed via communications connections. It bases these responsibilities on fundamental IT
definitions of major types of functional units. It focuses on the utilization of standard, public interfaces for
functional units and on the provision of accessible documentation of their capabilities.
This part of ISO/IEC13066 recognizes that IT is implemented both in conventional computer systems and as a
major component of other systems within the wider scope of information and communications technology
(ICT). This part of ISO/IEC 13066 recognizes the fundamental role of operating systems and application
programming interfaces (APIs), in managing interoperability, and in providing guidance to developers of other
functional units. It also recognizes that different operating systems will have their own standardized methods
of supporting interoperability.
This part of ISO/IEC 13066 does not define or require specific technology, commands, APIs, or hardware
interfaces. It defers to other existing standards and supports the development of new standards in these
areas.
It identifies a variety of common accessibility APIs that are further described in other parts of ISO/IEC 13066.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
accessibility API
set of programming interfaces designed specifically to provide accessibility services
NOTE An accessibility API is a special instance of an API.
2.2
accessibility services
services provided by an operating system or other platform software, commonly in the form of APIs
(application programming interfaces) that are used by software to expose information about the user interface
and events to assistive technologies and that provide two-way communication with assistive technologies,
including exposing information about objects and events
NOTE Accessibility services might provide additional information used by assistive technologies, e.g. about operating
system status.
© ISO/IEC 2011 – All rights reserved 1

2.3
application programming interface
API
collection of invocation methods and associated parameters used by one piece of software to request actions
from another piece of software
[ISO/IEC 18012-1, definition 3.1.1]
2.4
application software
software that is specific to the solution of an application problem
[ISO/IEC 2382-1, definition 10.04.01]
EXAMPLE A spreadsheet program.
2.5
assistive technology
AT
hardware or software that is added to or incorporated within a system that increases accessibility for an
individual
EXAMPLES Braille displays, screen readers, screen magnification software and eye-tracking devices.
[ISO 9241-171, definition 3.5]
NOTE 1 Assistive technology can be helpful to individuals with disabilities or other specialized needs.
NOTE 2 Within this document, where assistive technology (and its abbreviation AT) is used, it is to be considered as
both singular and plural, without distinction. If it is to be used in the singular only, it will be preceded by the article “an”
(i.e. an assistive technology). If it is to be used in the plural only, it will be preceded by the adjective “multiple”
(i.e. multiple AT).
2.6
compatibility
capability of a functional unit to meet the requirements of a specified interface without appreciable modification
[ISO/IEC 2382-1, definition 10.06.11]
2.7
computer
functional unit that can perform substantial computations, including numerous arithmetic operations and logic
operations, without human intervention
[ISO/IEC 2382-1, definition 10.03.03]
NOTE A computer can consist of a stand-alone unit or several interconnected units.
2.8
computer system
system
one or more computers, peripheral equipment, and software that perform data processing
[ISO/IEC 2382-1, definition 10.01.20]
2.9
connectivity
capability of a system or device to be attached to other systems or devices without modification
[ISO/IEC 2382-1, definition 10.03.27]
2 © ISO/IEC 2011 – All rights reserved

2.10
device driver
software component that permits a system to control and communicate with a peripheral device
[IEEE Std. 610.10-1994, IEEE Std. 610.12-1990, definition 3.542]
2.11
function
defined objective or characteristic action of a system or component
[IEEE Std. 610.12-1990, unnumbered definition]
EXAMPLE A system has inventory control as its primary function.
2.12
functional unit
entity of hardware or software, or both, capable of accomplishing a specified purpose
[ISO/IEC 2382-1, definition 10.01.40]
2.13
hardware
all or part of the physical components of an information processing system
[ISO/IEC 2382-1, definition 10.01.07]
EXAMPLES Computers and peripheral devices.
2.14
information/communication technology
ICT
technology for gathering, storing, retrieving, processing, analysing and transmitting information
[ISO 9241-20, definition 3.4]
EXAMPLE A computer system.
2.15
interface
shared boundary between two functional units, defined by various characteristics pertaining to the functions,
physical interconnections, signal exchanges, and other characteristics, as appropriate
[ISO/IEC 2382-1, definition 10.01.38]
2.16
interoperability
capability to communicate, execute programs, or transfer data among various functional units in a manner that
requires the user to have little or no knowledge of the unique characteristics of those units
[ISO/IEC 2382-1, definition 10.01.47]
2.17
operating system
OS
software that controls the execution of programs and that may provide services such as resource allocation,
scheduling, input-output control, and data management
NOTE Although operating systems are predominantly software, partial hardware implementations are possible.
[ISO/IEC 2382-1, definition 10.04.08]
© ISO/IEC 2011 – All rights reserved 3

2.18
operation
process of running a computer system in its intended environment to perform its intended functions
[IEEE Std. 610.12-1990, unnumbered definition]
2.19
peripheral equipment
device that is controlled by and can communicate with a particular computer
[ISO/IEC 2382-1, definition 10.03.07]
EXAMPLES Input–output units and external storage.
2.20
platform software
collection of software components that runs on an underlying software or hardware layer, and that provides a
set of software services to applications that allow them to be isolated from the underlying software or
hardware layer
NOTE A particular software component might play the role of a platform in some situations and not in others.
Platforms can include such things as internet browsers, operating systems, plug-ins to internet browsers or other software
applications, and, under some situations, byte-code interpreted virtual environments and other “programming within
another programming” environments.
2.21
service
functionality made available to a user electronically
[ISO/IEC 24752-1, definition 4.27]
EXAMPLES Airline reservation service, currency translation services, weather forecasting, and restaurant
recommendations.
2.22
role
semantic association which allows tools to present and support interaction with the object in a manner that is
consistent with user expectations about other objects of that type
EXAMPLES Checkbox, menu item, list item, and table column header.
2.23
software
all or part of the programs, procedures, rules, and associated documentation of an information processing
system
NOTE Software is an intellectual creation that is independent of the medium on which it is recorded.
[ISO/IEC 2382-1, definition 10.01.08]
2.24
support software
software that aids in the development, maintenance, or use of other software or provides general
application-independent capability
[ISO/IEC 2382-1, definition 10.04.03]
EXAMPLES Compilers and database management systems.
4 © ISO/IEC 2011 – All rights reserved

2.25
system software
application-independent software that supports the running of application software
[ISO/IEC 2382-1, definition 10.04.02]
EXAMPLE An operating system, a Web browser, or a programming environment (e.g. Java) can be used as a
platform for application software.
NOTE Platform software (2.20) is similar to but not always the same as system software.
2.26
user interface element
user interface object
entity of the user interface that is presented to the user by the software
[ISO 9241-171 definition 3.38]
NOTE 1 User interface elements may or may not be interactive.
NOTE 2 Both entities relevant to the task and entities of the user interface are regarded as user interface elements.
Different user interface element types are text, graphics and controls. A user interface element may be a representation or
an interaction mechanism for a task object (such as a letter, a sales order, electronic parts, or a wiring diagram) or a
system object (such as a printer, hard disk, or network connection). It may be possible for the user to directly manipulate
some of these user interface elements.
EXAMPLE 1 User interface elements in a graphical user interface include such things as basic objects (such as
window title bars, menu items, push buttons, image maps, and editable text fields) or containers (such as windows,
grouping boxes, menu bars, menus, groups of mutually-exclusive option buttons, and compound images that are made up
of several smaller images).
EXAMPLE 2 User interface elements in an audio user interface include such things as menus, menu items, messages,
and action prompts.
EXAMPLE 3 User interface elements in tactile interfaces include such things as tactile dots, tactile bars, surfaces,
knobs, and grips.
2.27
boundary
〈user interface element〉 physical display area occupied by a particular user interface element when outputting
it on a display
3 Conformance
3.1 Applying the requirements
This part of ISO/IEC 13066 contains requirements and recommendations for a variety of different products.
Where a requirement does not identify a particular type of product, it is expected to apply to all types of ICT
products.
All requirements in Clauses 5–9 shall be implemented by the products to which they apply.
3.2 Applying the recommendations
Individual recommendations in Clauses 5–9 should be evaluated for their applicability to the particular product.
The applicable recommendations shall be implemented.
NOTE This has the effect of transforming applicable recommendations into additional requirements.
© ISO/IEC 2011 – All rights reserved 5

3.3 Evaluation of products
If a product is claimed to conform to this part of ISO/IEC 13066 then the procedures used to establish the
product’s requirements (as identified in 3.1 and 3.2), and to evaluate the product based on these
requirements, shall be specified. The level of detail of the specification is a matter of negotiation between the
involved parties.
4 Framework for IT-AT interoperability
4.1 Assistive technology
AT connects to ICT hardware or software components to modify, duplicate, or replace the user interface
functionalities of those components.
EXAMPLE 1 A glare filter is physically attached to a display to modify the way in which a user is able to see the
information on a visual display.
EXAMPLE 2 A single switch is used with an on-screen keyboard to replace the functionality of a standard keyboard.
EXAMPLE 3 A voice recognition program can provide the user with either an alternate or a duplicate method of
entering data into a computer that is equipped with a microphone.
NOTE AT can be provided as a service without the need of being installed on an individual system
4.2 Interconnection
4.2.1 Introduction to interconnection
AT typically make use of standard connections between ICT components. For interconnection to take place, it
is important that standard interfaces that are expected by AT be available to them.
The use of standard interfaces means that AT do not have to interoperate with ICT in unsupported,
undocumented, and non-standard methods.
NOTE Unsupported, undocumented, and non-standard methods often lead to incompatibilities.
EXAMPLE 1 A Braille display is connected to a computer via a Universal Serial Bus (USB) interface.
EXAMPLE 2 Output from an application program is processed by screen magnification software prior to its being sent
to the display driver in an operating system which forwards the magnified information to a video display device.
EXAMPLE 3 On-screen keyboard software is connected by the operating system and provided to an application for
use instead of a physical keyboard.
6 © ISO/IEC 2011 – All rights reserved

4.2.2 Types of standard connections
Connections can be classified as:
a) Hardware-to-hardware connections;
b) Hardware-to-software connections;
c) Software-to-software connections.
4.2.3 Hardware-to-hardware connections
Hardware to hardware connections involve physical and/or logical interfaces that support the transfer or
communication of information between the connected hardware or between the user and the hardware.
External hardware-to-hardware connections are intended to provide easy connection of peripheral devices
(including AT) to a computer or another device. These connections benefit from being standardized. Hardware
to hardware connections can be subdivided into:
a) wired connections (e.g. monitor, USB, speaker, microphone, Ethernet);
b) wireless connections (e.g. WI-FI, Bluetooth, infra-red);
c) non-electronic connections (e.g. the ability to place a glare filter over a display screen, the ability to use a
key guard).
NOTE Internal hardware-to-hardware connections within a computer are primarily intended for connecting parts of a
computer to one another (e.g. the connection used for a laptop screen to the processing capabilities of the laptop).
Because of their internal nature, internal hardware to hardware connections are not necessarily standardized.
4.2.4 Hardware-to-software connections
Hardware to software connections are provided by device drivers within the ICT's system software interacting
with the system's external hardware to hardware connections.
While it can be possible for other programs, besides device drivers, to provide instructions directly to external
hardware, this practice generally results in interconnectivity problems and is discouraged.
4.2.5 Software-to-software connections
The standard method of software to software connection with platform software is via an Application
Programming Interface (API) that has been defined by the platform software.
NOTE 1 The term "platform software" can be used to refer to any system or application software that provides services
to other software from the underlying layers. It could be the operating system or it could be a browser or any application
runtime environment (which might also be considered as application or support software).
NOTE 2 According to ISO/IEC 2382-1 there are three classes of software:
a) System software, which includes the operating system and other instance of platform software;
b) Application software;
c) Support software.
It is important to recognize the ISO/IEC 2382-1 definition of "application-independent software that supports the running of
application software" is not specific to operating systems and is not specific to software provided by operating system
vendors. This definition is consistent with the common use of the term "platform software".
© ISO/IEC 2011 – All rights reserved 7

4.2.6 AT-IT Connectivity
AT can be connected to ICT in the following ways:
a) An AT device can connect to another device that is connected to a computer or to ICT.
b) An AT device can replace another device that is connected to a computer or to ICT.
c) AT software can connect to the operating system.
d) AT software can replace some of the functionality provided by system software.
e) AT software can connect to an application program.
f) AT software can connect to a utility software program.
4.2.7 Introduction to interoperability
Interoperability involves more than the provision of standard connections. Interoperability involves the ability to
effectively communicate between AT and the component(s) to which it is connected.
4.2.8 Goals for interoperability
The goals of AT-IT interoperability include:
a) The number of individuals who can operate ICT with (or without) standard AT is maximized.
b) The efficient use of all of the features offered by the ICT products by all individuals, including those with
disabilities.
c) Individuals are enabled to use all relevant functions to operate ICT via AT.
d) Various types of AT can be easily and simply connected to ICT.
e) Standard methods are available to interface AT with ICT systems that use standard control commands.
f) Compatibility is maintained, even when version changes occur in either the AT or ICT products.
4.2.9 Hardware-to-hardware interoperability
Hardware-to-hardware interoperability is achieved by the effective communications of commands and data
across hardware to hardware connections.
Hardware-to-hardware interoperability is enabled by using standard sets of hardware commands and
interconnections. Hardware commands are often specific to a type of device.
Interoperability is enhanced by various devices sharing a common set of hardware commands.
Common sets of hardware commands are generally defined based on the type of devices that they apply to.
EXAMPLE ETSI TS 102 511 identifies current and potential AT Commands for Assistive Mobile Device Interfaces.
8 © ISO/IEC 2011 – All rights reserved

4.2.10 Hardware-to-software interoperability
Hardware-to-software interoperability is achieved by device drivers effectively translating between hardware
commands and data and software commands and data.
Each operating system provides its own standard for how device drivers operate and typically provides a basic
set of generic device drivers.
Manufacturers of peripheral devices can utilize these generic device drivers or can provide specialty device
drivers to be installed within the system software, which provide advanced functionality for controlling features
of their devices.
Interoperability is enhanced by various device drivers sharing common functionalities and common sets of
hardware and software commands.
4.2.11 Software-to-software interoperability
Software-to-software interoperability is achieved through pre-defined application programming interfaces (or
API’s). Each operating system provides its own standard for how this is done and the specific set of API’s.
Additionally, APIs can be provided by other forms of system software (e.g. Web browsers or programming
environments) which run on operating systems and which are in turn used to provide a platform for running
application software.
5 Requirements and recommendations on hardware-to-hardware interoperability
5.1 Responsibilities of ICT manufacturers
5.1.1 Presence of hardware interfaces
ICT systems shall include hardware interfaces that support connection of industry standard user input and
output devices.
NOTE 1 While directly providing currently available interfaces is preferable, this requirement can be met by providing
interfaces to which currently available adapters can be connected, where these adapters can connect to standard user
input and output devices.
NOTE 2 The particular hardware interfaces that an ICT system includes will vary based on current technology and on
the physical characteristics of the ICT.
NOTE 3 While USB 2.0 interfaces are most common at the time of developing this standard, some other technology
may replace it in the future.
NOTE 4 While computer systems intended for permanent locations include a wider variety of specialized interfaces,
small, highly portable computers (e.g. Personal Digital Assistants), and other ICT systems often use a single USB
connection to perform all types of hardware interfacing.
5.1.2 Following hardware interface standards
Standard hardware interfaces (e.g. USB ports, PC Card interfaces) shall comply precisely with applicable
specifications.
NOTE AT products rely on standard hardware interfaces and assume they conform to a given standard. Many times,
a hardware manufacturer will step outside of the standards and make their own enhancements/changes to these hardware
interfaces which subsequently cause it to become incompatible with AT.
EXAMPLE A computer that ships with its own low-power USB mouse pointer that doesn’t require a lot of power still
supplies the standard prescribed power to its USB ports, so that an AT can be plugged into that port replacing the mouse,
with the assumption the power will be there.
© ISO/IEC 2011 – All rights reserved 9

5.2 Responsibilities of device manufacturers
5.2.1 Use of standard hardware interfaces
Peripherals should make use of standard hardware interfaces, wherever possible.
NOTE Where device manufacturers choose to utilize non-standard hardware interfaces (for performance or other
reasons), they are encouraged to also produce alternate models of the device that can utilize standard hardware
interfaces. Where alternate models cannot be provided, the manufacturers can at least provide discuss how non-standard
the components of the hardware interface map to a standard hardware interface and/or API.
5.2.2 Support of standard functionality and commands
Where applicable hardware command standards exist, device functionality shall be accessible via standard
hardware commands.
NOTE 1 Where device manufacturers choose to utilize non-standard commands to replace standardized commands
(for performance or other reasons), it is important for them to also support the standardized commands that they have
chosen to replace.
NOTE 2 It is especially important that accessibility functionalities are either unaltered or enhanced in a manner
consistent with providing the same service as if they were unaltered.
5.2.3 Providing information about non-standard functionality of devices
Manufacturers of devices with functionalities that are not accessible via standardized commands, shall provide
accessible documentation that describes their non-standard functionalities and the hardware commands
required to make use of these functionalities.
NOTE 1 This information can be made available on the manufacturers Web site, on machine readable media that are
provided with the device, or through some other accessible mechanism.
NOTE 2 ISO/IEC 24756 provides a useful approach to specifying this information in a manner that can be electronically
processed.
6 Requirements and recommendations on hardware-to-software interoperability
6.1 Responsibilities of ICT system manufacturers
6.1.1 Providing external control of system functions
Functions shall be available to be invoked via the accessibility services provided or supported by an ICT
system to control major IT system functionalities from an external device.
NOTE 1 It is desirable that proprietary commands and new functions be standardized as soon as possible.
NOTE 2 Major IT system functionalities include controlling:
a) downloading and installing applications on the ICT;
b) starting the running of an application on the ICT;
c) operating the application on the ICT;
d) closing down the application on the ICT.
10 © ISO/IEC 2011 – All rights reserved

6.1.2 Information about system functionalities
Accessible information shall be provided by ICT systems, on which functionalities are accessible through
standardized commands.
6.2 Responsibilities of operating system manufacturers
6.2.1 Provision of device drivers and APIs
An operating system shall provide a set of device drivers and APIs to support the needs of assistive
technologies for providing alternative input and output mechanisms.
NOTE 1 It is recognized that each operating system has its own distinct needs in this area.
NOTE 2 It is recognized that additional accessibility services exist and can interoperate with some operating system
APIs.
EXAMPLE 1 Drivers and APIs to the audio subsystem for generating text to speech for screen reading for blind users
or people with print impairments; or for playing audio for people with speech impairments.
EXAMPLE 2 Drivers and APIs to the video device for screen magnification.
6.2.2 Information about device drivers and accessibility services
Operating system manufacturers shall provide sufficient information about the functionalities of their device
drivers and accessibility services so that device manufacturers and software developers can properly interface
with them. Where necessary, operating system manufacturers may allow device manufacturers and software
developers to or create customized versions of device drivers.
NOTE It is desirable for OS manufacturers to present information on their APIs for potential international
standardization.
6.2.3 Operating system installations
Operating System installation procedures shall ensure that all standard device drivers (i.e. mouse, keyboard,
video, sound, printer, etc.) that are provided by the operating system are included in the installation.
NOTE Partial and selective installations of operating systems can lead to drivers that AT is counting on not being
there.
EXAMPLE 1 While an Other Equipment Manufacturer (OEM) system that comes with its own pointing device with a
custom mouse driver, the standard mouse driver might still needed.
EXAMPLE 2 Installing/upgrading the OS when USB is disabled in the BIOS can lead to a system that’s missing USB
or HID drivers, causing a problem if the user enables USB at a future date.
6.2.4 Device Driver Management
If the operating system allows deletion or replacement of device drivers, the operating system should allow
assistive technology to register their use of device drivers. In such cases, the operating system should warn
the user of the potential to create interoperability problems when deleting or replacing any of the device
drivers that are used by assistive technology.
© ISO/IEC 2011 – All rights reserved 11

6.3 Responsibilities of device driver developers
6.3.1 Avoiding device driver incompatibilities
Specialized versions of device drivers shall conform precisely to the device driver specifications of the OS
manufacturer and/or applicable international standards.
NOTE 1 This involves extending existing functionalities and commands rather than replacing them.
NOTE 2 This is especially critical for video drivers.
NOTE 3 It is important to keep performance enhancements in hardware, rather than drivers. This retains the possibility
of compatibility of AT software with video displays.
6.3.2 Providing information about device driver functionalities
Developers of device drivers shall provide accessible information about which functionalities are available
through standardized commands that are currently supported by their device driver.
NOTE 1 This information can be made available on the developers Web site, on machine readable media that are
provided with the device, or through some other accessible mechanism.
NOTE 2 ISO/IEC 24756 provides a useful approach to specifying this information in a manner that can be electronically
processed.
6.4 Responsibilities of device manufacturers
6.4.1 Providing information about specialized device drivers
Manufacturers of devices with functionalities, that require specialized device drivers, shall provide accessible
information that describes any non-standard functionalities and any API extensions required to make use of
these functionalities.
NOTE 1 This information can be made available on the manufacturers Web site, on machine readable media that are
provided with the device, or through some other accessible mechanism.
NOTE 2 ISO/IEC 24756 provides a useful approach to specifying this information in a manner that can be electronically
processed.
7 Requirements and recommendations on software-to-software interoperability
7.1 Responsibilities of all software developers
7.1.1 Extending existing functionality
New features/functions required by the software being installed shall append existing installed features, not
replace them.
NOTE Installation of software that makes use of shared hardware or software components or shared applications can
inadvertently overwrite existing settings and features used by AT.
12 © ISO/IEC 2011 – All rights reserved

7.1.2 Installation of new versions of application software
a) The user should be given the option of retaining or replacing the old version at the end of the installation
procedure.
NOTE 1 This allows the user to determine whether or not any existing customizations have been rejected by the
new version, due to incompatibilities between versions.
b) If a user chooses to retain the old version to check compatibility with AT, the user should be able at a
later time to uninstall the old version.
NOTE 2 This can allow a user to retain the old version until the compatibility of the new version with AT has been
tested.
c) Where new versions of an application are installed, customizations applied to the old version should be
applied to the new version unless the installation procedure asks users to decide whether or not they wish
to apply these customizations.
d) The installation procedure should alert the user to any customizations which cannot be applied to the new
version.
7.1.3 Installation of alternate versions of application software
Where multiple alternate versions of an application are installed, customizations applied to one version shall
not affect the capabilities of previously installed versions.
NOTE This can be handled by the installation software checking for existing settings before installing new settings
over top of them and by each version of application software maintaining its own set of settings.
7.1.4 Limited ability to uninstall application software
The operating system should ensure that uninstalling application software does not remove software
components shared with other applications.
7.1.5 Use of standard platform accessibility services
Software that provides user interface components shall either use the accessibility services provided by
platform software or use other services to cooperate with AT, when such services allow the software to meet
the accessibility provisions of this standard.
NOTE 7.1.6 and 7.1.7 provide further guidance on meeting this requirement.
EXAMPLE 1 A Windows application uses MSAA and IAccessible2 to enable interoperability with Windows assistive
technology.
EXAMPLE 2 A Windows 7 application uses User Interface Automation to enable interoperability with assistive
technology.
EXAMPLE 3 A UNIX application uses the UNIX Accessibility Framework to enable interoperability with assistive
technology.
EXAMPLE 4 A software developer works directly with an AT vendor to develop other services to provide optimized
access to the document object model of the application.
EXAMPLE 5 A third party works directly with an AT vendor to develop an interoperability interface where platform
accessibility services do not yet exist.
© ISO/IEC 2011 – All rights reserved 13

7.1.6 Making functionality available to accessibility services
Software should make its functionality available via the accessibility services that might be found on the
software platform(s) on which it runs.
NOTE 1 The use of calls to standard operating system libraries can make functionality related to these calls available
to accessibility services in the Operating System.
NOTE 2 Web browsers and/or specific programming environments (e.g. Java) can act as a platform running upon
another platform (i.e. the operating system). The use of standard functions on these platforms can make functionality
available to the various accessibility services of the immediate platform and/or the operating system.
NOTE 3 Annex A provides information on the major accessibility services.
7.1.7 Making information available about user interface elements
Software shall provide AT with information about user interface elements, including but not limited to:
a) role, state(s), boundary, name, and description of the user interface element;
b) current value and any minimum or maximum values, if the user interface element represents one of a
range of values;
c) text contents, text attributes, and the boundary of text rendered to the screen;
d) the relationship of the user interface element to other user interface element(s), including but not limited
to:
1) in a single data value, whether this user interface element is a label for another user interface
element or is labelled by another user interface element,
2) in a table, the row and column that it is in, including headers of the row and column if present,
3) in a hierarchical relationship, any parent containing the user interface element, and any children
contained by the user interface element.
NOTE This involves having interactive elements encoded in data operated on by the software associated with
sufficient information to determine a role, state(s), name, and description for the interactive element, that the software can
obtain as readily as it can obtain the interactive element itself.
7.1.8 Available actions on user interface elements
Software shall programmatically expose a list of available actions on a user interface element and allow
assistive technology to programmatically execute any of those actions.
7.1.9 Focus and selection attributes of user interface elements
Software shall programmatically expose information necessary to track and modify: focus, text insertion point
(where applicable), and selection attributes of user interface elements.
7.1.10 Changes related to user interface elements
Software shall programmatically expose notification of events relevant to user interactions, including but not
limited to:
a) changes in the user interface element value,
b) changes in the name of the user interface element,
14 © ISO/IEC 2011 – All rights reserved

c) changes in the description of the user interface element,
d) changes in the boundary of the user interface element,
e) changes in the hierarchy of the user interface element.
7.1.11 Programmatic modifications of states, properties, values and text
Software shall allow states, properties, values, and text
...