Current Edition: Accessibility

back To Overview of Edition

Leading Articles

SAP's Accessibility Approach

Regulations and More

Assistive and Other Technology

Personal Report

For Your Reference

CSUN 2007

Accessibility from the Perspective of a Visually Impaired User

By Alexander Kuban, Accessibility Competence Center, SAP User Experience, SAP AG – 06/07/2005

German Version

Perception

Blind and partially sighted PC users have a limited overview of the program window and screen compared to users with normal vision. They generally only have direct information about the one window element on which they are focusing at that point. As they gain experience of the software, they remember the program windows they use frequently and gain an overview in this way. In this situation, clear structures and explicit naming of the window's content appropriate to the processes is very helpful. Information that is not necessary at a particular time for the process should therefore not be displayed. For technical reasons, it should not just be hidden because this only makes the information invisible. It is often still available in the tools that visually impaired people use, which is disruptive.

One of these tools is a screen reader program that interprets the content of the program window and reads it aloud. Another one is a Braille display that can be integrated into the screen reader program using a driver. It enables the screen to be read line by line.

In contrast, partially sighted people use screen magnifier programs that magnify the screen to the scale they choose using the mouse pointer or cursor. These tools can also be supplemented by speech output.

Possible operating system settings, such as character set and font size, have the disadvantage that they enlarge the screen content absolutely. Users therefore need to scroll horizontally or vertically, which is a less efficient way of working.

For more information about such tools and their manufacturers, go to https://www.rehadat.de

 

Navigation, Selection, and Focus

Visually impaired PC users navigate just using the keyboard - not only within an application but also between different applications. Some partially sighted users can use a mouse, depending on their sight and range of vision. While navigating, they only have information about the window element on which they are focusing at that point.

In this context, the "focus" is for example, the cursor in an input field, the dotted outline around a pushbutton or checkbox, and the altered font and/or background color of an entry in a tree or list box (list box, combined input field, expandable list, and so on).

To navigate, select, or activate a user interface element, they use the navigation keys offered by the user interface (cursor keys, tab key in combination with the control and shift keys) or selection keys (space bar, enter key).

Switching Screens and Focus

For users working with keyboards, it is very helpful to set a focus in the program window so that they can start working directly. The focus should be set according to the program logic so that the cursor is always located where it should logically be for the next step of the work.

The Advantage of Hot Keys

Functions that are only available on a toolbar and elements placed anywhere within the window can only be reached using navigation, which means users need to preselect the element on which they want to execute the action. In such cases, a hot key to trigger the function is necessary.

 

Identifying the Content of a Window

With tools used by visually impaired people, it is important that the program window has a technical structure that is oriented to the standards of the programming model on which it is based. Using the structure, the screen reader program recognizes whether an element in focus is a pushbutton, input field, or similar. Elements that define completely new elements from individual components of the programming model cannot be read by a screen reader program - either at all or only incorrectly. This incorrect identification can lead to incorrect operation.

The label text, which must be technically associated with the window element, tells the user what the element currently in focus is called and thus its purpose. This technical association is essential - otherwise the screen reader program cannot identify and read out the information.

The label text of a window element must be short but also meaningful. Ideally, it should be visible and should not require action from the user for it to appear. This is particularly important for people using Braille displays because otherwise only a graphical symbol that does not have a direct meaning for them is displayed.

Combinations of UI elements, for example, an input field belonging to a selector switch, or an expandable list for determining a label text, are more difficult to understand and frequently can be difficult or impossible to use with a keyboard.

 

Problem Areas

The increasingly interactive design of applications and the technical dependency or association of structured window contents greatly endangers accessibility and efficient work with keyboards. For example, if part of a program window changes when a user navigates in another area, he or she must navigate a great deal to reach the changed window area and then navigate through it to interpret or evaluate the new content. Therefore, these types of changes to the program window should only occur if they are specifically selected and not as a result of navigation.

Another problem for accessibility is the newly established technologies for screen setup and interaction.

User interfaces that consist entirely or partly of a graphic have a number of major disadvantages in terms of accessibility:

 

Supporting Users with Efficiency and Ergonomics

A key aspect of a business application for supporting and managing a business process is entering and changing data. Therefore, navigation must always be designed around the keyboard. It enables data to be entered and therefore needs to be able to trigger all functions in the system to avoid users' having to work with more than one entry medium. This is extremely important for users who do not use a mouse. People only using a keyboard must be able to work efficiently by navigating between the different data required for the current work step with just a few keystrokes. Screen areas displaying overview and detailed data must therefore be placed directly next to each other. Windows containing elements for selecting functions must never be placed in between such areas. Users must be able to select them with menus activated by keystroke.

Users must also be able to focus on navigation elements by keystroke (for example, Ctrl+y for the folder list in Microsoft Outlook). They should be available in menus that can be activated by keystroke and without further navigation. In this way, the content of a window is reduced to just what is required. It is therefore much easier to maintain an overview and is more ergonomic.

 

Receiving Information from Speech Output and Braille Displays

While navigating, speech output and Braille displays give users information about the content of the window. Speech output only provides information abut the user interface element currently in focus, but if it is combined with a Braille display, users gain an overview of the entire screen line as soon as the focus is set on an element. Here, a "line" is a group of horizontally arranged window elements. This horizontal arrangement of elements that semantically belong together makes it easier for blind users using a Braille display in conjunction with a screen reader program to interpret them.

The horizontal arrangement of user interface elements is also very helpful for partially sighted users with a limited field of vision.

To identify the content of a screen, it is important that the screen reader program or screen magnifier program can access the attributes that identify the window element (label text, status). For structured elements (tables, trees), information about the focus position within the structure should also be available.

Optimal support for users depends on the sequence of these individual attributes and characteristics:

In technological terms, this information needs to be available to an interface as metadata that a technical tool then can use to prepare and give information.

However, the tool must be able to interpret this metadata. If it can, the interface gives this information to the user in the way with which he or she is familiar from other platforms. In technological terms, this procedure also reduces the general development and translation work.

Such interaction between GUI and tool technology has the additional benefit that manufacturers of tool technology can design their products specifically to users' requirements.

"Not available" and "Read only" Attributes

For determination of the status, there is a difference between the attributes "not available" and "read only." "Read only" is an attribute for texts that cannot be changed but can be selected - in part or in full - so that the selected text can be transferred to the clipboard. "Not available" is an attribute for interactive elements - for example, a pushbutton - that is not available in the current context.

On being informed of one of these attributes, the user recognizes whether he or she can interact with the element or not.

If the attributes are not used in accordance with these rules, it is confusing for users.

Braille Displays and Ergonomics

If a Braille display is used in conjunction with a screen reader and speech output, users gain an overview of the entire screen line as soon as the focus is set on an element on this line. They are not given attribute and type information but can call it if necessary. Users can choose to display the supplementary information all the time but this takes up space that could be used for the overview of the entire screen line. As a rule, in this mode, only the element in focus plus its name, type, and status are displayed on the Braille display. This then takes up an entire line.

 

Tables

The interpretation and processing of information in structured content, such as tables and lists, is more difficult than in forms. Although they only display one form of a type of information (for example, the details of an invoice), they are easier to handle because the sequence of output fields is designed more simply than in tabular displays. Tables offer more information at a glance but this is of no benefit to blind or partially sighted users.

It is very important that the columns and rows of tables and list-like output have headings so that blind users know what type of information can be found in the table's cells. The column headings act as field labels for the cells.

The heading of a table column must be technically defined as such and must be announced when entering the column. During vertical navigation, this information becomes redundant and users should only have to call it using the tool if they require.

If several structures are visible at the same time that change depending on each other, visually impaired users must navigate further to be able to interpret the data. One example is if a user selects an object in a table and the details appear in a second window area. In this case, it is very helpful if the focus is explicitly set once the user has given a command to display the detailed data.

However, one way of reducing the display of mass data and making it easier to process is a search dialog enabling users to enter search terms concatenated with relational data. A form makes it easier for users with a visual impairment to read the data.

 

top top