 |
|
|
Accessibility
- SAP and Accessibility
(offers public accessibility resources) - Accessibility
(overview article) - Accessibility Glossary
- Accessibility Links and References
Read also...
- Making Web Pages Accessible – Questions and HTML Examples
- Vision and Visual Disabilities – An Introduction
- Section 508 – § 1194.22
- Overview of the Web Content Accessibility Guidelines 1.0
- Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
Links & More
Accessibility
By Josef Köble, Tanja Schätz, and Dewi Gani, SAP Architecture Governance – Accessibility, SAP AG – October 6, 2009; see the disclaimer below
Accessibility is one of SAP's Top Priorities
SAP cares about the needs of its customers and communities and is committed in making its products more accessible to people with disabilities.
As mentioned above, accessibility is a top priority for SAP. This priority has been transformed in several areas within SAP, such as establishment of the SAP Accessibility Team, the creation of the SAP internal accessibility standard, the establishment of a test factory, and so forth.
The SAP Accessibility Team
SAP cares for the needs of its customers, including the customers who are strongly interested in the area of Accessibility and even make use of the accessible information and technology products in their working environment. As a result SAP also shares the same passion and vision that is to provide accessible products to our customers. This passion and vision has been transformed to the establishment of the SAP Accessibility team in Walldorf with various roles:
- Central contact center regarding internal and external accessibility related questions.
- Defines and maintains the SAP Accessibility Standard which is based on US Section 508, WCAG (Web Content Accessibility Guideline) and the German BITV (Barrierefreie Informationstechnik-Verordnung)
- Performs internal Accessibility technology assessments
- Follow-up with legislations and standards (work together with government/standard organizations to share our experience)
- Published Accessibility edition of SAP Design Guild at http://www.sapdesignguild.org/editions/edition9/overview_edition9.asp
- Authors of the book "Developing Accessible Applications with SAP NetWeaver" (ISBN: 978-1-59229-112-0). This book is available since 2007. You will find more information on the publisher’s home page, see http://www.sap-press.com/product.cfm?account=&product=H1985.
Front-End Requirements and Infrastructure for Accessibility
There is a prerequisite set of front-end requirements and settings required in order to work in the accessibility mode within SAP's solutions. In this section, you will find the required front-end requirements and infrastructure for Accessibility:
- Recommended Platform for Accessibility
- System Requirements and settings for Accessibility
- Supported screen reader and its version
The document of Front-end Requirements and Infrastructure for Accessibility can be found on the SAP Design Guild (page SAP and Accessibility) at http://www.sapdesignguild.org/resources/acc_technical_requirements_external_EN.pdf
Should you have any further questions, please contact accessibility@sap.com
Voluntary Product Accessibility Template (VPAT)
The ISO/IEC 17050 standard "Conformity assessment - Supplier's Declaration of Conformity" is an internationally agreed standard which defines the process and best practice that can be applied in all business sectors in all countries. The Information Technology Industry Council (ITI) and U.S. General Services Administration (GSA) partnered together to develop a standardized Supplier's Declaration of Conformity (SDoC), the so called VPAT. This is an official format which is used as well by other companies to declare the accessibility status of a product. It is based on the US section 508 and is SAP’s only means of communicating the status of its products to the customer. The VPAT is a legally binding document and the status reported in this document is reflected from the test results of our extensive testing process. Being aware of the needs of the European customers, SAP plans to provide as well product status documents based on WCAG. The WCAG product status documents will be provided not only for the web-based products but also for the non web-based products as long as the requirements are applicable. Since these product status documents are still in progress, please expect delay. To get more information about VPATs, please go to the following link: http://www.sapdesignguild.org/editions/edition9/vpat.asp
Different Perspectives on Accessibility
According to the World Health Organization (WHO), there were between 500 and 700 million people with disabilities worldwide in 2006. On top of this, there were around 600 million people aged 60 and over in 2000, some of whom might become disabled due to aging. The WHO forecasts that this sector of the world population will grow to 1.2 billion by 2025 and to 2 billion by 2050. In view of the sheer numbers of people affected by disabilities worldwide, considerable efforts have to be made at both the national and international level to address the challenges they face. As a result, awareness of the legitimate demands of older people and people with disabilities to take an active part in everyday life is no longer confined to interest groups, consumer organizations, and the public sector, but also has consequences for the actions of business enterprises. The private sector has recognized the economic importance of this ever increasing market segment and is becoming increasingly conscious of the requirements of this group of users.
There is a growing global awareness of the requirements of people with disabilities and older people, but this does not mean that all countries have a shared or even similar perception of the concept of accessibility. Some countries impose stricter laws and regulations, while some are less rigid. Some countries place a greater focus on the actual implementation of accessibility than others. The following section takes a brief look at how accessibility is perceived in a few selected countries.
United States
This country takes a strict stand when it comes to providing accessibility to people with disabilities. The US was the first country to put accessibility legislation (Section 508 of the Rehabilitation Act) in place to elimininate barriers in information and communication technology products and open up new opportunities for people with disabilities. Basically, Section 508 dictates that all US federal agencies must provide federal employees and members of the public with disabilities with equivalent access to information. More information about Section 508 is available at www.section508.gov/index.cfm?FuseAction=Content&ID=14.
Great Britain and Northern Ireland
In Great Britain and Northern Ireland (the United Kingdom), the scope of accessibility has been widened by several amendments to the Disability Discrimination Act (DDA) and now applies to people considered as disabled in the areas of education and transportation. It is now the task of providers to make “reasonable adjustments” in these areas to remove any barriers that could disadvantage people with disabilities compared with people without disabilities (www.drc-gb.org/the_law/legislation__codes__regulation/dda_and_related_statutes.aspx).
Germany and Austria
In Germany and Austria, the concept of accessibility does not just refer to products in information and communication technology, but also concerns "products" such as buildings or transportation. Section 4 of the German Act on Equal Opportunities for Disabled People (BGG) defines accessibility as follows: "Buildings and other installations, transportation, technical devices, information technology systems, acoustic and visual sources of information and communication installations, and other structured areas of life are accessible if they can be accessed and used by people with disabilities as intended, without significant difficulty, and unaided."
The corresponding Federal Act on Equal Opportunities for Disabled People in Austria (BGStG) is formulated in a similar way (Section 6, No. 5 of the BGStG).
In other words, Germany and Austria define accessibility as the ability of people with disabilities to access tangible and intangible objects or information and technology products without any assistance. The German BGG and the Austrian BGStG are addressed primarily at federal agencies. For more information about legislation in Germany, read Section 2.2.4 or visit www.gesetze-im-internet.de/bgg/__4.html; information about legislation in Austria is available at www.parlament.gv.at/pls/portal/docs/page/PG/DE/XXII/I/I_00836/fname_036804.pdf.
Different Legal Requirements
Legal requirements form the basis for the practical implementation of accessibility. Legislative competence rests in the sovereignty of each state, and if different states introduce different accessibility regulations, this can cause problems for enterprise software that is used around the world. If regulations differ from country to country or even contradict each other, a company must decide which regulations have priority for its software. Global companies – like SAP – support moves toward the harmonization of legislation in order to avoid this situation, since it is not possible to fulfill all accessibility legislation in all countries.
Internal Accessibility Standards at SAP
The development of accessible software at SAP is based on clearly defined requirements and processes, as described in the internal SAP Accessibility Standard. These standards were first introduced in 2002 and, as well as including the requirements from Section 508 of the US Rehabilitation Act, also incorporate requirements from WCAG 1.0 of the World Wide Web Consortium (W3C) and International Organization for Standardization (ISO) 9241-171.
Establishing our standard as a central principle for all development activities at SAP presented us with the following challenges:
- Determining the basis for the standards
We first had to consolidate a variety of international accessibility legislation, standards, and guidelines into criteria applicable to a large enterprise's development teams.
- Formulating the requirements as standards
Once the spectrum of requirements had been defined, our second challenge was to combine them into a central set of company-specific standards. The way the requirements are formulated is crucial to how they are understood, and to whether they are actually put into effect as intended.
The following aspects were critical:- All requirements must be formulated as clearly and precisely as possible so that they can be understood easily by the target audience responsible for applying them. With this in mind, it is often best to replace the often abstract formulations found in legislation and guidelines with your own choice of words. This can include any technology-specific terminology.
- It is a good idea to go beyond a mere description of the requirements and to illustrate them with concrete examples of how they benefit the user. In this way, development teams know why a requirement is needed and are better motivated to implement it.
- Some requirements are formulated in a way that, despite being legally
valid, does not provide users with a guarantee of increased efficiency
or usability. Where this is the case, you can adapt a requirement to
suit your company's own idea of usability. The following example shows
you how standard 1194.22 (o) in Section 508 of the US Rehabilitation
Act has been adapted for the SAP Accessibility Standard:
Section 508, 1194.22 (o):
A method shall be provided that permits users to skip repetitive navigation links.
SAP Accessibility Standard:
Wherever a large element or grouping element is used (e.g., trees, data tables, tabstrips, group boxes, menu areas, toolbars, controls), the user must be given the option to skip the element.
SAP believes that Section 508 does not go far enough in this instance and that such a method must always be provided whenever the alternative would involve making many repetitive navigation steps.
- Additional technology-specific standards
Other documents accompanying the standards
The SAP Accessibility Standard is a central document that consolidates all accessibility requirements that apply at SAP. This standard is then used as a basis for more specific standards relevant to the technology or technologies employed by a particular development team. Developers are therefore provided with the precise information they need for their project. Further support comes from additional guidelines that use screenshots and code examples to illustrate the requirements, making the efficient and focused development of accessible software even easier.
Finally, special checklists are available for testing in detail how successfully you have implemented a requirement. You can run both manual and automated tests.
Requirements in the SAP Accessibility Standard
The requirements in the standards are organized into the following categories:
- Perception
- Navigation and keyboard access
- Structure
- UI elements and controls
- System reaction
- Other
Note that the version of the SAP Accessibility Standard described in this book refers to Version 1.0 of the WCAG, since Version 2.0 was not available at the earlier press time.
In the following you will exemplary find the requirements in the category “Navigation and Keyboard Access”.
Requirements in the Category “Navigation and Keyboard Access”
1. Keyboard Access
It must be possible to access all elements on a screen and to activate their associated functions using a keyboard.
Note:
- Menus, menu items, status bar, and screen title
All menus and menu items, as well as the status bar and the screen title, must be accessible using a keyboard. - Functions provided by application development
Each function provided by application development (such as drag and drop or copy and paste) must be accessible using the keyboard.
2. Logical Order of Tab Chain and Reading Order
All UI elements must be included in the tab chain in a logical order. The tab chain is also determined by the reading order (such as left to right, and top to bottom). This general rule can be broken if the application requires a different tab order design for reasons of efficiency.
Note:
Note the following information about tab chains:
- Grouped elements
If two larger elements, such as group boxes, appear side by side on the screen, the tab chain must lead the user through all the elements in the first group box before navigating to the group box next to it. - Labels
Generally, labels do not belong in the tab chain. Instead, these elements must be defined in such a way that they are read automatically when a user navigates to the UI element (such as an input field or combo box) associated with the label. - Short description
If a UI element has a short description as well as a label, it must be possible to access the label, element, and short description with a single cursor movement (or equivalent key stroke). This ensures that the screen reader reads the information from the label, element, and description all at the same time. If two or more cursor movements (or equivalent key strokes) are required, make sure that the label is associated with the short description. If the label and short description cannot be associated with each other, there must be an alternative way of telling the user that the short description is related to the preceding label and element (such as a tooltip).
In the following cases, exceptions are acceptable:
- Data cells in tables
If a data cell in a table has a UI element in it (for example, an input field), the UI element must be in the tab chain and not the data cell itself. - Amodal help documentation
Content in amodal help documentation (displayed on a separate screen) does not belong in the tab chain, but must be accessible from the keyboard.
3. Visible Focus
The current focus must be visible as it moves between the interactive UI elements during user navigation.
Note:
- Focus after server round-trips
After a server round-trip not initiated by the user, the focus must stay on the same element and element state. This does not apply to elements that cause new screens to appear.
4. Skip Option for Large Elements
The user must be able to skip any large UI elements or grouping elements (such as a tree, data table, group box, menu area, or control).
Disclaimer
This document is for informational purposes only. Its content is subject to change without notice, and SAP does not warrant that it is error-free. SAP MAKES NO WARRANTIES, EXPRESS OR IMPLIED, OR OF MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
The information contained in this document represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP specifically disclaims any liability with respect to this document and no contractual obligations or commitments are formed either directly or indirectly by this document. This document is for internal use only and may not be circulated or distributed outside your organization without SAP's prior written authorization. © 2009 SAP AG
Note, that the text of the sections “Different Perspective on Accessibility” and “Internal Accessibility Standard at SAP” is taken from the book “Developing Accessible Application for SAP NetWeaver” (Galileo Press / SAP Press, ISBN 978-1-59229-092-5).
