|SAP and Accessibility|
|Accessibility (Overview article)|
|The SAP Accessibility Standard|
|SAP's Public Accessibility Website|
|Accessibility on SAP's Service Marketplace|
By Ulrich Kreichgauer, Architecture Governance and Standards, SAP AG – March 9, 2012
The majority of SAP Design Guild Editions deal with different aspects of "usability". This time, however, we will focus (for the third time) on "accessibility", a related topic that has a lot in common with usability but still presents its own particular challenges.
What do usability and accessibility have in common? If you look at accessibility regulations and laws, such as U.S. section 508 or the WCAG (Web Content Accessibility Guideline) or the BITV (Barrierefreie Informationstechnik-Verordnung / Barrier-Free Information Technology Ordinance), you will find the same requirements for self-descriptiveness, system feedback, error avoidance, consistent user interfaces, and control and supervision as those described in known usability standards and norms such as the ISO 9241/110.
Useable applications are the fundamental basis of accessibility, and all user groups benefit from them. But user groups with special needs, such as blind users who depend on the screen reader, or visually-impaired users who work with a modified color scheme, sometimes do not have enough options for compensating poor usability.
In addition to the typical usability aspects, there are also issues that are more specific to accessibility, such as the availability of equivalent alternatives to graphics, color information, video, or audio. Whenever users attach auxiliary tools (such as screen reader software, magnification software, special keyboards, or other forms of special hardware), they need to use programs that recognize or derive the user interface information, structures, or relationships.
The articles "The SAP Accessibility Standard" and "The SAP Accessibility Testing Process" describe how these aspects are implemented and tested at SAP. We can't always make all products 100% accessible, due to things like restrictions in a certain user interface technology, for example. So from a user's point of view, we must make it clear to what extent a product is barrier-free. The way this is done is described in the article "SAP's Accessibility Product Status Documents".
The authors of the following, somewhat more technical articles address two totally different issues: "New High Contrast Black…" discusses the challenges faced in defining a special color scheme for visually-impaired users. While "Accessible Rich Internet Apps…" deals with a very recent issue which focuses on reducing the accessibility deficits in modern interactive Internet applications.
A list of accessibility links, an accessibility glossary, and an article on visual handicaps round out the Edition.
A number of accessibility experts at SAP are working on creating SAP-internal guidelines, developing manual and automated test methodologies, and training developers to develop applications with reference to the SAP Accessibility Standard. Accessibility is a topic and quality characteristic that is firmly reflected in our quality assurance processes. The SAP status documents that we make available to our customers make our achievements reaching the SAP Accessibility Standard transparent to them.
But there is no end in sight to our efforts. One reason is that there are always new products, applications, or further developments that need to become barrier-free. And secondly, new questions continue to pop up, such as: (How) can mobile devices (like Smartphones and tablets) be made accessible, and which new or revived topics (for example, voice entry) can help accessibility?
Enjoy this new Edition of SAP Design Guild. We hope it inspires you.