Command-line (text) In early
operating systems, such as
MS-DOS, which employed
command-line interfaces (CLIs), the screen display consisted of
characters mapping directly to a
screen buffer in
memory and a
cursor position. Input was by keyboard. All this information could therefore be obtained from the system either by
hooking the flow of information around the system and reading the screen buffer or by using a standard hardware output socket
Graphical Off-screen models With the arrival of
graphical user interfaces (GUIs), the situation became more complicated. A GUI has characters and graphics drawn on the screen at particular positions, and therefore there is no purely textual representation of the graphical contents of the display. Screen readers were therefore forced to employ new low-level techniques, gathering messages from the
operating system and using these to build up an "off-screen model", a representation of the display in which the required text content is stored. For example, the operating system might send messages to draw a command button and its caption. These messages are intercepted and used to construct the off-screen model. The user can switch between controls (such as buttons) available on the screen and the captions and control contents will be read aloud and/or shown on a
refreshable braille display. Screen readers can also communicate information on menus, controls, and other visual constructs to permit blind users to interact with these constructs. However, maintaining an off-screen model is a significant technical challenge; hooking the low-level messages and maintaining an accurate model are both difficult tasks.
Accessibility APIs Operating system and application designers have attempted to address these problems by providing ways for screen readers to access the display contents without having to maintain an off-screen model. These involve the provision of alternative and accessible representations of what is being displayed on the screen accessed through an
API. Existing APIs include: • Android Accessibility Framework • Apple Accessibility API •
AT-SPI •
IAccessible2 •
Microsoft Active Accessibility (MSAA) •
Microsoft UI Automation •
Java Access Bridge Screen readers can query the operating system or application for what is currently being displayed and receive updates when the display changes. For example, a screen reader can be told that the current focus is on a button and the button caption is to be communicated to the user. This approach is considerably easier for the developers of screen readers, but fails when applications do not comply with the accessibility API. One approach when the accessibility API is insufficient is to use available operating system messages and application object models to supplement accessibility APIs. Screen readers can be assumed to be able to access all display content that is not intrinsically inaccessible. Web browsers, word processors, icons and windows and email programs are just some of the applications used successfully by screen reader users. However, according to some users, using a screen reader is considerably more difficult than using a GUI, and many applications have specific problems resulting from the nature of the application (e.g. animations) or failure to comply with accessibility standards for the platform. == Customization ==