A Giant Rises to the Challenge of Accessibility

By Audrey Weinland & Dena Schumila, SAP Accessibility Competence Center, Palo Alto – February 18, 2002

Disclaimer: Please note that this article was written in 2002. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, and organizational structure, may no longer be valid.
For up-to-date information on SAP's accessibility strategy, please refer to "Accessibility" on the SAP Service Marketplace or the
current edition on accessibility.

It's not every day that a global company takes a challenge and turns it into an opportunity. SAP AG (headquartered in Waldorf, Germany) along with its subsidiaries (which span over 50 countries worldwide) is in the process of turning the accessibility challenge into an accessibility opportunity.

With the passage of technology-related laws that protect the rights of computer users with disabilities in several countries around the globe, SAP, along with its peers in the Information Technology industry, has suddenly been faced with the tremendous task of reviewing all of its products and services for accessibility, and improving the ones that do not meet the new legislative requirements. This has proved to be a particularly daunting process for SAP: with thousands of transactions, tens of thousands of screens, a range of operating environments, and multiple product versions that need to be localized for a variety of languages and countries. Less than a year after the establishment of its Accessibility Program, however, SAP is not only facing this challenge head on, but it is able to look back on the accomplishments in the short history of this new company-wide initiative with pride.

 

SAP Responds to the Challenge

What has this multi-billion dollar, global behemoth done to reach this point? Thus far, the SAP accessibility effort has consisted of four major steps.

  1. A central group was formed to spearhead the accessibility push inside SAP
  2. Research was conducted on accessibility issues that pertained specifically to SAP products and services
  3. A strategy for tackling those accessibility issues was defined and
  4. The process began to implement those accessibility changes on a company-wide (i.e. worldwide) scale.

As the first step toward reaching SAP'S accessibility goals, in April of 2001 the company formed the SAP Accessibility Competence Center (ACC). The ACC is located at SAP Labs, in Palo Alto, California. This group, which reports directly to executive management, is the focal point for the SAP Accessibility Program. The ACC is responsible for ensuring that SAP, as a company, meets its accessibility-related goals. These are:

  1. To ensure compliance with accessibility requirements outlined in legislative and industry standards, and
  2. To move beyond these accessibility requirements to create software products that can be used easily and efficiently by people with disabilities.

 

Accessibility Evaluation Process

The ACC began by setting up an assistive technology lab and testing environment at its location in Palo Alto. This involved acquiring hardware and software to enable the team to evaluate various assistive technologies, such as screen readers and screen magnifiers, as well as automated testing tools that could be used to check the accessibility of SAP websites. These machines would also be used as test machines for evaluating the accessibility of SAP products.

Once the lab was set up, the ACC immediately began evaluating SAP products and services for compliance with legal and industry standards, and defining a strategy for tackling the accessibility issues found. The results of all accessibility evaluations, including both the accessibility issues that were identified, and suggestions for improvements, were compiled into reports and distributed to the responsible development teams.

The ACC hoped to achieve three main goals with these evaluations:

  1. Identify areas where work needed to be done to improve the accessibility of SAP products.
  2. Evaluate the effectiveness and compatibility of automated testing tools and assistive technologies with SAP products and services.
  3. Establish a baseline accessibility evaluation methodology that could be incorporated into SAP'S software development lifecycle (SDLC) and Global Quality Management (GQM) process.

In terms of identifying where work needed to be done, the evaluations not only provided direct information to the respective development teams about the accessibility of their products; they also provided a research arena in which the ACC team could investigate different solutions for accessibility problems that were encountered. Through an iterative process of evaluations by the ACC--and fixes by development teams--it was possible to determine the level of the software architecture where an issue existed (for example, whether it was a Basis issue or an application issue), as well as to try out various solutions for the issue to determine the best one. The preliminary evaluations also helped the ACC evaluate various testing tools and assistive technologies, and in turn establish and refine the ACC accessibility evaluation methodology that is in use today.

 

Automated Testing Environment

SAP websites are evaluated for accessibility using automated accessibility checking tools, specifically Insight 508 (by SSB Technologies) and CAST'S Bobby product. In addition, ACC team members perform heuristic evaluations on the sites using the JAWS for Windows screen reader, IBM's Homepage Reader, and other assistive technology solutions.

Evaluating SAP software is another matter, however. The ACC team soon realized that the automated tools available on the market were not useful for evaluating SAP software, because they were designed to check HTML content on websites, not complex, Web-based applications such as those offered by SAP. As a result, SAP software is currently evaluated manually, with the same types of heuristic evaluations mentioned above.

The ACC (and therefore SAP) is not in the business of developing proprietary access tools or assistive technologies. Its task is to ensure that SAP'S e-business solutions are accessible through their use in conjunction with existing assistive technologies. The selection of JAWS for Windows as SAP'S initial screen reader was based on the product's global popularity with blind computer users, as well as its compatibility with platforms supported by SAP and its support for multiple languages. On the other hand, other screen readers had to be eliminated as candidates, because--at the time of our evaluations--they did not work on either Windows NT or Windows 2000. Of course, additional assistive technology solutions will need to be selected in the future to ensure that SAP products and services can be used in a variety of user scenarios.

As stated above, the evaluations done to date have focused on the accessibility of SAP software in conjunction with screen reading products. The rationale for concentrating on screen reading products before any other type of assistive technology is that many accessibility issues that impact blind computer users also affect individuals with other types of disabilities. For instance, while keyboard-only access obviously improves accessibility for blind users, who cannot visually track the movements of a mouse pointer on the screen, it also improves accessibility for people with learning disabilities, who are often unable to use mice because they lack the hand/eye coordination required to manipulate them, and for people with mobility impairments, who have problems with fine motor control or cannot move their hands at all. Of course, concentrating on screen readers cannot cover all of the bases, so the ACC has plans to expand its evaluations to include other types of assistive technology such as screen magnifiers, voice recognition systems, and alternative keyboards. In fact, the SAP Corporate Research Center (CRC), is currently conducting research on the compatibility of SAP solutions with existing assistive technologies, including voice recognition systems and natural language navigators.

 

Graphical User Interface Selection

When deciding how best to proceed with implementing accessibility changes in SAP software products and services, SAP was faced with another choice: which of its three graphical user interfaces (GUIs) should it concentrate its initial efforts on?: SAP WinGUI, SAP JavaGUI, or SAPGUI for HTML? This decision needed to be made because there would not be enough ACC or development bandwidth to improve all three GUIs simultaneously. After analyzing the different GUIs, the ACC proposed that SAP concentrate its initial efforts on improving the accessibility of SAP'S browser-based technologies (the HTML GUI, et al.). This proposal was supported by key representatives of SAP'S Basis development organization. Reasons for this choice included:

  1. The availability of clear accessibility standards (including code samples) for both HTML and browser-based interfaces, which have been developed by the World Wide Web Consortium (W3C's) Web Accessibility Initiative (WAI) and are outlined in the Section 508 Standard Rules.
  2. The relative ease of integrating browser-based applications with 3rd party assistive technologies such as screen readers, because work has already been done to ensure their compatibility with mainstream Web browsers such as Microsoft's Internet Explorer, and because of the clearly defined accessibility standards mentioned above and
  3. The fact that SAP uses standard HTML in its Web-based application development, and assistive technologies have already been enhanced--or especially created--to work well with standard HTML.

A Giant Rises to the Challenge of Accessibility

By Audrey Weinland & Dena Schumila, SAP Accessibility Competence Center, Palo Alto

Disclaimer: Please note that this article reflects the state as of 2002. Therefore, statements in the articles, particularly those on SAP's products, product strategy, and organizational structure, may no longer be valid.
For up-to-date information on SAP's accessibility strategy, please refer to Frontend Requirements and Infrastructure for Accessibility.

It's not every day that a global company takes a challenge and turns it into an opportunity. SAP AG (headquartered in Waldorf, Germany) along with its subsidiaries (which span over 50 countries worldwide) is in the process of turning the accessibility challenge into an accessibility opportunity.

With the passage of technology-related laws that protect the rights of computer users with disabilities in several countries around the globe, SAP, along with its peers in the Information Technology industry, has suddenly been faced with the tremendous task of reviewing all of its products and services for accessibility, and improving the ones that do not meet the new legislative requirements. This has proved to be a particularly daunting process for SAP: with thousands of transactions, tens of thousands of screens, a range of operating environments, and multiple product versions that need to be localized for a variety of languages and countries. Less than a year after the establishment of its Accessibility Program, however, SAP is not only facing this challenge head on, but it is able to look back on the accomplishments in the short history of this new company-wide initiative with pride.

 

SAP Responds to the Challenge

What has this multi-billion dollar, global behemoth done to reach this point? Thus far, the SAP accessibility effort has consisted of four major steps.

  1. A central group was formed to spearhead the accessibility push inside SAP
  2. Research was conducted on accessibility issues that pertained specifically to SAP products and services
  3. A strategy for tackling those accessibility issues was defined and
  4. The process began to implement those accessibility changes on a company-wide (i.e. worldwide) scale.

As the first step toward reaching SAP'S accessibility goals, in April of 2001 the company formed the SAP Accessibility Competence Center (ACC). The ACC is located at SAP Labs, in Palo Alto, California. This group, which reports directly to executive management, is the focal point for the SAP Accessibility Program. The ACC is responsible for ensuring that SAP, as a company, meets its accessibility-related goals. These are:

  1. To ensure compliance with accessibility requirements outlined in legislative and industry standards, and
  2. To move beyond these accessibility requirements to create software products that can be used easily and efficiently by people with disabilities.

 

Accessibility Evaluation Process

The ACC began by setting up an assistive technology lab and testing environment at its location in Palo Alto. This involved acquiring hardware and software to enable the team to evaluate various assistive technologies, such as screen readers and screen magnifiers, as well as automated testing tools that could be used to check the accessibility of SAP websites. These machines would also be used as test machines for evaluating the accessibility of SAP products.

Once the lab was set up, the ACC immediately began evaluating SAP products and services for compliance with legal and industry standards, and defining a strategy for tackling the accessibility issues found. The results of all accessibility evaluations, including both the accessibility issues that were identified, and suggestions for improvements, were compiled into reports and distributed to the responsible development teams.

The ACC hoped to achieve three main goals with these evaluations:

  1. Identify areas where work needed to be done to improve the accessibility of SAP products.
  2. Evaluate the effectiveness and compatibility of automated testing tools and assistive technologies with SAP products and services.
  3. Establish a baseline accessibility evaluation methodology that could be incorporated into SAP'S software development lifecycle (SDLC) and Global Quality Management (GQM) process.

In terms of identifying where work needed to be done, the evaluations not only provided direct information to the respective development teams about the accessibility of their products; they also provided a research arena in which the ACC team could investigate different solutions for accessibility problems that were encountered. Through an iterative process of evaluations by the ACC--and fixes by development teams--it was possible to determine the level of the software architecture where an issue existed (for example, whether it was a Basis issue or an application issue), as well as to try out various solutions for the issue to determine the best one. The preliminary evaluations also helped the ACC evaluate various testing tools and assistive technologies, and in turn establish and refine the ACC accessibility evaluation methodology that is in use today.

 

Automated Testing Environment

SAP websites are evaluated for accessibility using automated accessibility checking tools, specifically Insight 508 (by SSB Technologies) and CAST'S Bobby product. In addition, ACC team members perform heuristic evaluations on the sites using the JAWS for Windows screen reader, IBM's Homepage Reader, and other assistive technology solutions.

Evaluating SAP software is another matter, however. The ACC team soon realized that the automated tools available on the market were not useful for evaluating SAP software, because they were designed to check HTML content on websites, not complex, Web-based applications such as those offered by SAP. As a result, SAP software is currently evaluated manually, with the same types of heuristic evaluations mentioned above.

The ACC (and therefore SAP) is not in the business of developing proprietary access tools or assistive technologies. Its task is to ensure that SAP'S e-business solutions are accessible through their use in conjunction with existing assistive technologies. The selection of JAWS for Windows as SAP'S initial screen reader was based on the product's global popularity with blind computer users, as well as its compatibility with platforms supported by SAP and its support for multiple languages. On the other hand, other screen readers had to be eliminated as candidates, because--at the time of our evaluations--they did not work on either Windows NT or Windows 2000. Of course, additional assistive technology solutions will need to be selected in the future to ensure that SAP products and services can be used in a variety of user scenarios.

As stated above, the evaluations done to date have focused on the accessibility of SAP software in conjunction with screen reading products. The rationale for concentrating on screen reading products before any other type of assistive technology is that many accessibility issues that impact blind computer users also affect individuals with other types of disabilities. For instance, while keyboard-only access obviously improves accessibility for blind users, who cannot visually track the movements of a mouse pointer on the screen, it also improves accessibility for people with learning disabilities, who are often unable to use mice because they lack the hand/eye coordination required to manipulate them, and for people with mobility impairments, who have problems with fine motor control or cannot move their hands at all. Of course, concentrating on screen readers cannot cover all of the bases, so the ACC has plans to expand its evaluations to include other types of assistive technology such as screen magnifiers, voice recognition systems, and alternative keyboards. In fact, the SAP Corporate Research Center (CRC), is currently conducting research on the compatibility of SAP solutions with existing assistive technologies, including voice recognition systems and natural language navigators.

 

Graphical User Interface Selection

When deciding how best to proceed with implementing accessibility changes in SAP software products and services, SAP was faced with another choice: which of its three graphical user interfaces (GUIs) should it concentrate its initial efforts on?: SAP WinGUI, SAP JavaGUI, or SAPGUI for HTML? This decision needed to be made because there would not be enough ACC or development bandwidth to improve all three GUIs simultaneously. After analyzing the different GUIs, the ACC proposed that SAP concentrate its initial efforts on improving the accessibility of SAP'S browser-based technologies (the HTML GUI, et al.). This proposal was supported by key representatives of SAP'S Basis development organization. Reasons for this choice included:

  1. The availability of clear accessibility standards (including code samples) for both HTML and browser-based interfaces, which have been developed by the World Wide Web Consortium (W3C's) Web Accessibility Initiative (WAI) and are outlined in the Section 508 Standard Rules.
  2. The relative ease of integrating browser-based applications with 3rd party assistive technologies such as screen readers, because work has already been done to ensure their compatibility with mainstream Web browsers such as Microsoft's Internet Explorer, and because of the clearly defined accessibility standards mentioned above and
  3. The fact that SAP uses standard HTML in its Web-based application development, and assistive technologies have already been enhanced--or especially created--to work well with standard HTML.

The SAP WinGUI was considered as a candidate for an initial effort due to the fact that it uses custom components, which cannot be recognized by the most commonly used assistive technologies. The level of effort required to make this GUI accessible was thought to be significantly higher than the effort that would be required to make the browser-based interfaces accessible. As for the SAP JavaGUI, it had to be set aside due to the lack of support in the assistive technology industry for the Java (TM) Accessibility Bridge. This Sun Microsystems tool, makes it possible for existing Windows-based assistive technology products to talk to the components in a JAVA Foundation Classes (JFC) application. However, although SAP's JavaGUI uses standard JFC components' which implement the Java Accessibility Application Programming Interface (API), without an assistive technology to bridge this gap, choosing the SAP JavaGUI became extremely complicated. Therefore, it became clear to all that by focusing on the SAPGUI for HTML, and other browser-based interfaces, SAP would be able to offer an accessible solution to customers with disabilities more quickly than if another GUI were selected.

Once the decision to go with browser-based interfaces had been made, the ACC had to deal with the fact that there were multiple technologies underlying those interfaces. For instance, some SAP screens are comprised of dynamically generated HTML and others are template-based. There are also different HTML libraries used to build the components that make up different SAP products. Beyond that, accessibility problems can occur at various levels in the software architecture; the ACC had to determine which problems originated at the GUI level, which were Basis-level problems, and which problems belonged to the application developers.

 

Accessibility Using the SAP HTML GUI

Despite these challenges, the ACC, the GQM team, and the Internet Transaction Server (ITS) group immediately began to work on the accessibility of the HTML GUI. Examples of changes made include: better navigation due to tab indexing, and the addition of labels for icons, buttons, and edit fields, making these elements more accessible to a screen reader.

At the same time that this work was being done on existing products, steps were being taken to ensure the accessibility of future products, by defining a process for building accessibility into the software from the start. This involved the integration of automated checks for accessibility into SAP internal systems--such as Checkman. One benefit of this process is that accessibility errors are being treated the same way as program errors, which receive a high level of attention, through to resolution. This project culminated in the formation of SAP-SPECIFIC standards for developing accessible software products. The ACC, together with GQM, has written a suite of documents that reflect these standards. The documents include a design guide, a process document, handover checklists, and development and quality assurance checklists, and they are already being used by several development organizations to design and code brand-new products.

 

SAP's Worldwide Development Project

Following on the heels of the ITS accessibility effort, SAP recently launched a worldwide development effort to make accessibility changes at the Basis and application levels for SAP'S flagship products: the R/3 Enterprise solutions. Since the changes being made to SAP transactions in this project are based on the accessibility standards developed by the ACC and GQM, these changes will not only improve the accessibility of affected transactions, they will also result in transactions that have a greater degree of usability for people with disabilities. The ACC unveiled the first of these improved transactions at SAP TechEd 2001 in Los Angeles in November and demonstrated them again at the Public Services American SAP Users' Group (ASUG) meeting in Orlando a few weeks later. The changes were received with enthusiasm by audiences at both events.

Like any global company, SAP will continue to face challenges as it pursues its goal of becoming a leading provider of accessible solutions. A worldwide company faces planet-sized issues. Nevertheless, SAP has what it takes to turn the accessibility challenge into an accessibility opportunity. This global contender is eager to become a leader in offering accessible solutions for customers with disabilities.

 

top top

 

Once the decision to go with browser-based interfaces had been made, the ACC had to deal with the fact that there were multiple technologies underlying those interfaces. For instance, some SAP screens are comprised of dynamically generated HTML and others are template-based. There are also different HTML libraries used to build the components that make up different SAP products. Beyond that, accessibility problems can occur at various levels in the software architecture; the ACC had to determine which problems originated at the GUI level, which were Basis-level problems, and which problems belonged to the application developers.

 

Accessibility Using the SAP HTML GUI

Despite these challenges, the ACC, the GQM team, and the Internet Transaction Server (ITS) group immediately began to work on the accessibility of the HTML GUI. Examples of changes made include: better navigation due to tab indexing, and the addition of labels for icons, buttons, and edit fields, making these elements more accessible to a screen reader.

At the same time that this work was being done on existing products, steps were being taken to ensure the accessibility of future products, by defining a process for building accessibility into the software from the start. This involved the integration of automated checks for accessibility into SAP internal systems--such as Checkman. One benefit of this process is that accessibility errors are being treated the same way as program errors, which receive a high level of attention, through to resolution. This project culminated in the formation of SAP-SPECIFIC standards for developing accessible software products. The ACC, together with GQM, has written a suite of documents that reflect these standards. The documents include a design guide, a process document, handover checklists, and development and quality assurance checklists, and they are already being used by several development organizations to design and code brand-new products.

 

SAP's Worldwide Development Project

Following on the heels of the ITS accessibility effort, SAP recently launched a worldwide development effort to make accessibility changes at the Basis and application levels for SAP'S flagship products: the R/3 Enterprise solutions. Since the changes being made to SAP transactions in this project are based on the accessibility standards developed by the ACC and GQM, these changes will not only improve the accessibility of affected transactions, they will also result in transactions that have a greater degree of usability for people with disabilities. The ACC unveiled the first of these improved transactions at SAP TechEd 2001 in Los Angeles in November and demonstrated them again at the Public Services American SAP Users' Group (ASUG) meeting in Orlando a few weeks later. The changes were received with enthusiasm by audiences at both events.

Like any global company, SAP will continue to face challenges as it pursues its goal of becoming a leading provider of accessible solutions. A worldwide company faces planet-sized issues. Nevertheless, SAP has what it takes to turn the accessibility challenge into an accessibility opportunity. This global contender is eager to become a leader in offering accessible solutions for customers with disabilities.

 

top top