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 for ABAP Programs

By Gisbert Loff, Head of Accessibility Competence Center, SAP User Experience, SAP AG – 06/07/2005

 

The Task

The task sounded simple: "Can you create some accessible screens for us?" "OK, I said" "Oh – sorry – did I mention that we have 20000 screens within the application?"

This fictitious dialogue shows the amount of work that could accompany a task to create an accessible SAP solution.

 

The Architecture

With a small "Hello World Type" application, written in Visual Basic, for example, you could try to modify every screen by hand, define rules for a screen reader for each and every screen, do some testing, and that's it. Every screen is programmed individually; all fixes have to be made "locally" to these screens.

ABAP applications based on SAP Web Application Server (SAP Web AS) are different. SAP's three-tier client/server architecture distinguishes between Database layer, Application layer, and User Interface layer.

Obviously, the database layer has no influence at all.

Most of the screens are designed individually with the screen painter tool (some, however, are generated automatically), fed with runtime information by an ABAP program, and displayed with the SAP GUI, SAP's generic UI rendering engine. So, there are various places where you could improve the user experience. Fortunately, the architecture provides central locations where some of the accessibility needs can be addressed and fixed.

 

The Focus

In order to create accessible screens, you have to look for keyboard enablement, correct usage of colors, support for various color schemes and font scaling, screen-reader enablement, and appropriate textual description for several UI elements.

Keyboard Enablement

Neither the ABAP coding nor the screen painter definition can influence the general keyboard enablement of the UI elements. There is no room to "not keyboard-enable" an application on that level.

Keyboard enablement can be centrally solved at the user interface layer. We can talk about the keyboard enablement of SAP GUI rather than talking about the keyboard enablement of thousands of screens. In previous versions of SAP GUI, keyboard enablement of UI elements was not guaranteed in all cases. So, with SAP GUI 6.40, this has been fixed centrally.

Usage of Colors

Using colors is somehow more complicated. Some of the more complex UI elements provide runtime parameters to set colors, for example the color of a certain cell within a grid control. In this case, the occurrences of the corresponding method calls have to be tracked and looked after individually on application level. In addition, you have to think about an appropriate textual description of what a user color really means (for example, "green" could mean "in stock", or "functional", or "not critical").

Enablement for High-Contrast Color Schemes

Even if an application does not misuse colors as the only means of conveying information, not every user might be happy with the actual assignment of colors Some users may prefer an inverted color scheme or higher contrast.

As with the keyboard enablement, being able to adapt to another caller scheme is not part of the application programming, but can be handled by SAP GUI. The latest SAP GUI version has been enhanced to better integrate with the windows color schemes.

Enablement for Font Scaling

Fortunately, there is no way to choose a font style or font size within an ABAP program or within the screen painter, so this is not an application problem at all. Improvements have been made centrally with the latest SAP GUI version.

Enablement for Screen Reader

The three-tier client/server architecture provides a perfect environment for a centralized screen reader enablement. The complete screen description is sent from the application server to the presentation server on the client PC in a standardized way.

Since the introduction of SAP GUI Scripting in SAP GUI 6.20, the structure of the screen can be exposed via a COM interface.

So the task of enabling thousands of screens for a screen reader can be reduced to providing a link between the screen reader and the object model that is exposed via SAP GUI.

This is described in more detail in a separate article.

Labels and Textual Descriptions

Missing textual descriptions are a major accessibility issue. Providing tooltip information, titles for groups of UI elements or tables and column header information is essential for a good user interface.

The textual information mentioned above cannot be provided automatically, so this is a manual task for the application developer.

Also, the linkage between an entry field and the appropriate label has to be done manually within the screen painter for each screen.

In some cases, the programming interface for UI elements was enhanced to enable definition and transport of this textual information.

Selecting the "Right" UI Elements

It turns out that not all UI elements or programming methods are equally suited to address the needs of "programming for accessibility." Special care has to be taken when using lists (via "write" statement; structured lists can be replaced using the ALV control (ALV = ABAP List Viewer)) or the HTML control (using the HTML control might be easy from the "ABAP" perspective, but redirects the problem to the HTML (content)-generating component. In that case, guidelines for accessible HTML apply).

 

Summary

The architecture of the SAP system allows us to improve a large portion of the user experience by focusing on a few central components, mostly SAP GUI.

The application developer can concentrate mainly on providing textual information for buttons, header information, and column information for tables. In order to do this, some of the methods and properties for various UI elements had to be enhanced in newer releases of SAP Web Application Server or SAP NetWeaver, so the application developer can use these methods to fill the required textual information.

Topic
Centralized Solution
Keyboard enablement Latest SAP GUI for Windows version
Color-scheme support Latest SAP GUI for Windows version
Screen-reader enablement Latest SAP GUI for Windows Version
Screen Reader extension
(Screen reader not part of SAP shipment)

Table 1: Centralized solutions

Topic
Local Activities
Textual information for headers, columns, entry-fields Call appropriate methods / set properties of UI controls (ABAP code)
Link entry-fields with corresponding label Provide link information (in Screenpainter)
Selection of UI elements Use ALV rather than lists wherever possible (ABAP code)
Replace HTML control wherever possible (ABAP code)

Table 2: Local activities

Using a new SAP GUI will address the first group of topics, representing in any case a benefit for any SAP release or customer-created ABAP applications. The second group of topics represents local "per screen" activities which have to be realized irrespective of the used SAP GUI version used.

 

top top