ICT is used in most cases to communicate with other people using various media. Users who are unable or unwilling to access a media, perhaps due to sensory limitations, require an alternative in order that they be included in the exchange. Alternatives may be created separately by the author, embedded in the media or generated when it is accessed. So for example with electronic media, a text transcript of a video may be made available, a video may have embedded captions or a text document can be spoken using speech synthesis.

Computer programs used to create and access electronic media add complexity as they are often controlled using a limited range of user interface options. Current operating systems interact with the user through mouse, keyboard and visual display. A few major variations such a keypads, touch pads and trackballs, are usually supported as they emulate standard devices fairly closely. The limited device support is reflected by programs that use Operating System services for much of their functionality.

Alternative access is usually achieved by emulating existing device interactions that the programs expect and by converting output. After market add-ons for existing programs are usually developed, but sometimes a program will have accessibility features designed in or an Operating System extension may be utilised to work with more programs. Emulating existing devices is not ideal as it is indirect, it is difficult to determine the programs state in a general way and is sensitive to changes in the controlled program or operating system. For example a switch control scanning program that emulates key board input requires templates for each program that is to be controlled and cannot easily be made to react to program state.

Graphical User Interfaces (GUI)are popular but obviously require both vision and fairly complex physical skills with a mouse. For some users that is irrelevant and direct keyboard, switch or audio access is much more suitable than trying to convert to/from GUIs.

Useful add-ons have been developed by trial and error reverse engineering of interfaces. More recently several attempts have been made to create generic interfaces can be use to control and access programs (Java and Microsoft Accessibility APIs). While this helps it requires developers to support the APIs by adding specific features and they are not mandatory so do not get used. Interestingly these APIs are of most use for creating systems that automate GUI testing, accessibility of media is indirectly gained.

Thin client systems such as Terminal Services or web applications cause further problems by splitting the program and user interface across machines. This effectively exposses a completley different set of interfaces for add-ons which often expect direct access to specific interfaces on the same machine.

That is a summary of the main issues, what are the solutions? Adding support for different interfaces directly into the operating system and making it mandatory for all programs to support is a good start. Standard APIs that work across operating systems and thin clients will help. Document and media formats can be designed to include alternative formats and addressing schemes (e.g. ODF).