Accessibility: The lost principle from a section of U’sX(user’s experience)
In this blog, we first try to define the aspect of the need for accessibility feature to be incorporated into the user interface design. We try to identify the whitespace in the Fiori design w.r.t accessibility for people with disabilities. In the end, we try to propose a solution to address the whitespace or the needs of the users with disabilities.
SAP Fiori is the path which defines the path towards a better UX – User Experience. The pillars of SAP Fiori paradigm are its five core principles. The principles cover the aspects necessary to ensure a good, if not better UX. The principles set the benchmark in terms of the solution adhering to the end user’s usage experience. However, in spite of having finally focused the attention to its actual users, we seem to have ignored a set of end users. The users who are differently abled are ignored and in many cases not at all accounted for. I hope to bring the attention also towards this set of users with this blog.
Accessibility refers to the design aspect of products, devices, services, or environments for people who experience disabilities. According to the definition, the design of the application should ensure that interface also supports users with disabilities. Ideally, if there is a common denominator in terms of simplistic design, we need to set the bar at the stage which caters to users who experience disabilities w.r.t machine interface. Even though, with the simplistic design we set the bar for a user with little or no knowledge of the machine/computer/mobile; we tend to ignore the aspect the accessibility.
The principles of Fiori UX are; simple, responsive, coherent, delightful, adaptive and role-based. All the principles ensure that the interface is prepared for changing device and expectations of the user. The principles ensure that users are not forced on a platform or device. They also ensure a better experience for the users, mainly in terms of the performance( predominantly, screen rendering speed ) and look & feel. The design aspect of the interface has to be deeper than just the look and feel. The actual design of the application is about how it works and it should consider all types of users. In the world of construction, each construction has defined parameters to ensure that the building is compatible for people with disabilities. Unfortunately, in the software world and esp. w.r.t user’s interface, it is more a nice to have feature. In fact, it’s nowadays not even talked about as a feature.
In the actual design phase, where we scratch out the wireframes, we need to start by identifying the users. We need to categorise the audience in terms of functional knowledge based users and physically challenged users. By identifying them at the early stage, we can use the opportunity to include some basic components into the interface design which will facilitate the users with disabilities. Some of the design options could be: To consider short-cuts for all buttons; Settings option on the application interface which will allow configuration to screen in terms of contrast/sizes or button etc..
As always, technology is available at our disposal but it’s the stakeholders who need to push for it. If the client does not push for it, then the architect has to push for it. If the architect does not do it, then the technical lead should do it. And if everyone ignores it then the developer need to fight for its inclusion. It’s not to patronize the actual task but to fulfill the actual purpose for which the solution is implemented. The motto should be : Maximum adoption and minimum interruption.
Please feel free to share your opinions and views on the article.
Sharath,
I would agree whole heartedly with what you have presented here. It's a shame when SAP does not agree. One such example is the Fiori - My Inbox, for tasks that launch the gui transactions, they are launched in web gui by default which is not accessible by any means.
Older technologies like UWL would check and if the user had the Accessibility flag on, it would launch the task in win gui given SAP's stance is that win gui is to be used for Accessibility and web gui is not Accessible at all.
Pointing out this missed feature in the Fiori - My Inbox through incidents and directly to the product manager have resulted in SAP's response of, "Oh Well, we're not doing that anymore". Sadly, this is an example of SAP's dedication to making their products Accessible, getting lost as technologies change.
Hi Roger,
Thank you for your support.
I have observed that in the urge to make the UI look cool and fast, SAP has simply ignored the needs of the people with disabilities. Its a sad and not a positive step towards adoption of SAP screens.
Regards,
Sharath
Hi Roger and Sharath
I actively work with several Public Sector customers who have both WCAG 2.0 AA and AAA legal compliance requirements. In fact locally in Australia we have a customer who has recently gone live with 110 custom Fiori app all built on SAPUI5 and all accessible to AAA level.
One of the primary struggles always with accessibility is raising awareness... i.e. getting executives, managers, project managers, product owners, designers, developers, testers, and users to understand that accessibility matters! So thanks for raising this issue yet again.
I've been reaching out to both the designer and developer communities via SCN and via experience.sap.com for some time now. My latest blog is here:
https://experience.sap.com/skillup/finding-dory-designing-for-diversity/
With respect to Fiori specifically... perhaps you haven't come across this document which has the collected learnings and guidance on Accessibility for Fiori so far.
SAP Fiori - Accessibility
While I would not suggest that everything is not by any means perfect yet... there is actually a huge amount that is built into SAPUI5 - the technology behind Fiori. As always with software it does depend on a combination of both the technology - device operating system, web browser, app tech, assistive tech - and the implementation.
On the technology side version matters hugely!!! For starters I would recommend that any customer serious about accessibility being on SAPUI5 1.36 to get the maximum built-in capabilities - for both Fiori apps and the Fiori Launchpad. Also one of the ongoing challenges of such fast moving innovation is not just the browsers but even much of the assistive tech don't yet consistently implement the ARIA guidelines.
However customers, partners, and independents need to be aware that the implementation is particularly important when it comes to:
While web development tech in HTML5 gives us an enormous amount of flexibility, it also gives developers flexibility to unintentionally override standard in-built accessbility capabilities. For instance, I've seen customers who have severely degraded Fiori accessibility just by poorly applied corporate theming alone.
That said of the existing OOTB Fiori apps, many were built prior to many of the SAPUI5 accessibility capabilities becoming available. New apps being built now for S/4HANA are built to SAP's Product Accessibility Standards. At SAP we work across several international standards and try to minimize implementation effort by covering what we can in the SAPUI5 framework. Most product owners will happily tell you that the older apps are planned to be remediated over time.
Where we can, we also provide extensibility and navigation options that help minimize issues. Such as the intent-based navigation in Fiori My Inbox which is a quick way to override legacy transactions in the inherited SAPGUI workflow configuration with more accessible and more usable equivalents such as Fiori apps and Unified Rendering controlled apps such as SAP Screen Personas, Web Dynpro ABAP, and SAPGUI for HTML.
It's also worth noting that in Fiori, accessibility is always "on" by default. Many legacy SAP apps & transactions as far back as SAPGUI for Windows also include accessibility features but may depend on certain parameters to be set in the User Master (such as ACCESSIBILITY_MODE = X) or made centrally by the user administrator (such as making the standard SAP High Contrast Black theme available to users) or via Unified Rendering settings.
If you are having specific issues, I would encourage to raise them via the usual support channels. And yes.... I'm aware that the new Support Launchpad site https://launchpad.support.sap.com/ has a long way to go. Some of the special features of the site have unfortunately been done in a way that breaks some many a number of the standard accessibility features in the framework. I've already been passing on complaints from my customers. So please use the "Share Feedback" option to raise your concerns and join us in the push to get this important site remediated asap.
If you simply want to check the accessibility compliance of a particular app or technology the dedicated SAP Accessibility group can assist with that. They have an amazing depth of passion and experience. I have always found them incredibly responsive in helping me and my customers work through issues. You can find more details on what they provide here: https://experience.sap.com/basics/accessibility-user-experience/
Thanks again for your interest. And please continue to help raise awareness among your own colleagues and business networks.
Rgds,
Jocelyn
Hello Jocelyn,
Thank you for taking time and sharing the complete info on the accessibility features supported within SAP. My intention was to bring this topic into discussion, which I found many stakeholders ignoring. I am pleasently surprised to be informed of the abundant of support from SAP, in this regard. Your reply could actually be a blog in its own right 🙂 .
I would definitely make use of this information and incorporate some of them in the future projects.
Regards,
Sharath