SAP has a huge number of user interfaces across its products, for example more than 14.000 in the next generation ERP software SAP S/4HANA. The accessibility of these user interfaces needs to be considered as part of the product development, managed, and communicated to customers and partners. Learn how SAPs framework for accessibility drives and supports that, how we got everybody onboard, the internal processes we have put in place to succeed and how we met the unique challenges in a huge global product are tackled.
I am the expert for accessibility for SAP S/4HANA.
There are two main reasons why SAP cares about accessibility:
Social responsibility: as a global market leader for business applications, SAP also has a responsibility to offer adequate user interfaces to users with various types of disabilities. This also contributes to the United Nations Sustainable Development Goals.
“Help the world run better and improve people’s lives”
Source: SAP, https://www.sap.com/corporate/en/vision-purpose.html
Legal compliance to stay competitive. Many of our customers want to and have to use accessibility compliant software. Customers might be required by law to use accessible software, or they have made commitments to the social partners, or at least they have to give preference to accessible software when they evaluate different vendors.
Additionally, accessibility also offers opportunities:
- Extend the number of users
- Accessibility features improve the usability of software for all users
Some quotes from the SAP fact sheets:
- SAP provides comprehensive solutions to meet essential business needs and to run your business better, faster and simpler
SAP serves >437,000 customers in >180 countries
- SAP S/4HANA is the Intelligent ERP for all organizations across 25 industries
The numbers marked in bold above lead to the first part of the challenge:
14000 users interfaces in scope of SAP S/4HANA
So SAP needs to test and manage the accessibility of all these UIs. That is a pretty big elephant already.
The second part of the challenge is that there are factors which increase the accessibility effort for each of these UIs:
- Test environment: testing combinations of operating systems, browsers and screen readers increases the effort by 10x
- External and customer standards: there are multiple accessibility standards such as WCAG, US Section 508 or BITV. In addition, some customers have their own standards. Test effort thus increases by 5x
- Organizational complexity: SAP has a huge development organization with multiple lines of business, acquired companies which bring their own methods and labs in multiple countries. I estimate that this increases the effort 2x
- UI Technology Diversity: there are at least 15 major UI technologies in ise at SAP, with more variants such as frameworks used with a technology. Because of higher training effort and infrastructure costs, this increases the effort 5x
All these factors combined: 500x
Accessibility test effort for SAP S/4HANA = 14000 UIs x 500
Conclusion: that is not just a big elephant – it is a herd of elephants. It would take literally take thousands of years to complete the accessibility testing. SAP obviously can not do it that way.
The factors above are rough estimates, but that does not matter: even if the effort would be “only” hundred years, it is still not working.
Mitigations – Slicing the Elephant
Fortunately, we have mitigations in place for each of the factors in the equation above.
SAP S/4HANA has standardized its test environment to this combination:
- OS: Windows 10
That’s a no-brainer, this is the most used operating system
- Browser: Chrome (latest)
Chrome has replaced Internet Explorer as the most used browser in our user base, so we switched to that. In addition, Chrome supports accessibility features of SAP UI5 better than Internet Explorer.
- Screen Reader: Jaws (latest)
Reason for using Jaws: Jaws is the only screen reader which can be scripted in a way that it supports the SAP Gui client. Thus it is the dominant screen reader in the SAP user base which are mostly enterprise users.
SAP occasionally did tests with other OS, browsers and screen readers. The major differences are mostly issues caused by the OS, browser or screen reader themselves, and there is nothing SAP could do to fix that. But There are usually only minor differences in the test results for the SAP software itself. So our decision that testing with multiple test environments is not worth the effort, one test environment is sufficient to achieve a good accessibility test quality.
This mitigation reduces the effort factor from 5x to 1x
External & Customer Standards
External accessibility standards are consolidated into one SAP internal standard for accessibility. This is one of the product standards which are valid for all SAP products. There is a team of product standard owners who continuously adopt the product standard to changes in the external standards or new regulations such as the EU accessibility standard. Kudos to my colleagues there, that is a big achievement.
The product standard accessibility consists of 130 requirements to check. It makes sure that people with vision, hearing, or motion impairments can use SAP software. Main areas considered there are:
- screen elements have labels and tooltips
- UI can be completely controlled by keyboard
- UI works fine when enlarged by 200%
- Sufficient color contrasts, support for high contrast modes
- UI can be used with a screen reader
The big lever to reduce the effort here is that the internal standard can be mapped to the external standards automatically. This means that we only need to evaluate the accessibility status according to our internal SAP standard and can then report it in any of the external standards.
Customer accessibility standards: Customers often have their own standards, especially when they try to compare multiple vendors. The customer account or sales team needs to translate between the SAP internal standard and the customer standard – this makes the process scale.
This mitigation reduces the effort factor from 5x to 1x
The setup shown above counters the impact of organizational complexity.
- Product standard owners
A central team; they create the product standard as explained in the previous section. This is valid for all SAP products. Equally important is that they also provide guidelines, trainings and internal consulting.
They also maintain the template for the so-called accessibility status documents. This template reflects the requirements of the product standards. It is used to record the results of an accessibility test.
- Accessibility test lab
These are experts who can reliably evaluate the accessibility of a user interface. They report the test results in the accessibility status documents. The accessibility test lab is a SAP-wide service unit .
- Development Teams
The product standard expert is responsible for the product standard in his team, including accessibility. He reports on the compliance of his product to the requirements of the internal accessibility standard. This format is understood and shared across all of SAP. This common format allows to combine the accessibility status of multiple software layers or components into one status with ease.
The developers are doing the actual work of creating the user interfaces, using the guidelines published by the product standard owners and their local expert. They have at least some basic education on accessibility testing so they can fix most of the accessibility issues before the test by the accessibility test lab. Depending on the size of the product, teams might have additional accessibility experts.
The experts then take the status documents of their UIs and create the accessibility documents for the customers. As mentioned earlier, the mapping to the external standard formats can be done automatically.
This mitigation reduces the effort factor from 2x to 1x
UI Technology Diversity
The mitigation again is standardization – using fewer UI technologies. This allows:
- Better accessibility support by the technology
- More code checks
- More test automation
Some of the UI technologies have been completely removed from S/4HANA. However, we can not get rid of all existing UI technologies, at least not at once.
But the good news here are:
- 95% of the UIs are already using standardized UI technologies, so the remaining UI technologies do not have much impact on the effort
- For some use cases, the UIs are only configured or generated, so it is sufficient to test the UI runtime or generator instead of each individual UI.
Taking this all together, this reduces the effort from 5x to 1x
Number of UIs
The numbers above are for S/4HANA 1809 FPS2.
From the ~14.000 UIs in scope of SAP S/4HANA, we can subtract the UIs which are unchanged compared to SAP ERP – the accessibility status and the documents are available there.
From the remaining 1800 UIs which are specific for SAP S/4HANA, ~800 are accessible by their technology, either a framework or generator as explained earlier.
This leaves us with ~1000 UIs which are relevant for individual accessibility tests. Even after coming down to 1000 test relevant UIs, these can not be tested each shipment. The solution is to reuse results unless an update is required. Roughly 90% have been tested already.
100 UIs remain as a test backlog. They have either not been tested yet, or a test found accessibility issues. SAP S/4HANA Development is working hard to reduce the backlog further each shipment.
The combination of all the mitigations above reduces a herd of elephants by factor 6363 into manageable slices. Mission accomplished.