Accessibility refers to the possibility for everyone, including and especially people with disabilities, to access and use information and communication technology. It is an integral part of the SAP Fiori design system and SAPUI5.
Accessibility support is incorporated at two levels:
- Framework level: Many fundamental accessibility features are built into the core design elements up front and are available to app teams out of the box. This ensures consistency across all products.
- App level: Some accessibility features need to be added or adapted to reflect app-specific context. These need to be considered whenever you design an app.
This article outlines how accessibility requirements are handled in the SAPUI5 reference framework:
Accessibility Provided at Framework Level
Minimum contrast: Following the requirements of the international Web Content Accessibility Guidelines WCAG 2.1 (see References), SAP Fiori’s default theme was designed to fulfill the requirements for minimum color contrast. In addition, we provide high-contrast themes that support the required contrast ratio of 7:1 for texts. They can be chosen in the user settings. The individual theme choice is saved as a preference until the user changes it again.
Consistency of icons: A comprehensive icon library ensures consistent icon usage within a product and also across products. The icon library includes predefined descriptions. This enables the development teams not only to use consistent icons, but also to implement meaningful descriptions for tooltips as a textual alternative for graphical representation. However, in some cases you may need to adapt these descriptions to the specific use case.
For more information, see Iconography.
Keyboard focus visualization design: Focus visualization is very important for user efficiency. SAP Fiori uses a contrast ratio that makes the current focus stand out in all themes.
Layout adaptation for different devices: Since SAP Fiori can run on various devices, it comes with a responsive layout that adapts to the display resolution parameters of the individual device.
For more information, see Multi-Device Support: Responsive vs. Adaptive.
Support for text resizing: Users can adjust the font size themselves using the browser zoom. The responsive layout adapts to these manual adjustments automatically.
For more information, see Multi-Device Support: Responsive vs. Adaptive.
Keyboard navigation and control interaction: All standard UI elements and controls are designed to be keyboard-enabled. All suitable input channels (such as mouse, keyboard, or touch) are treated equally according to the capabilities of the device or the individual preferences of the user. For example, some users may prefer using the keyboard instead of a mouse, which lets them work faster.
For more information, see SAPUI5 keyboard support on SAP Help Portal.
Tab order of controls: According to the placement of controls on the screen, SAPUI5 supports keyboard navigation with a predefined tab order sequence. This includes the tab order for the floorplan, the sequence of accessing individual applications, and the navigation in the application itself. According to control containers and layout, the application needs to be designed to support this order (left-right-top-bottom for western languages, for example).
Standard messaging patterns (busy, errors, notifications): In SAP Fiori, a message system is implemented. This ensures that system messages appear at predefined locations with a consistent design.
For more information, see Message Handing.
Screen Reader Enablement
Screen readers retrieve visible and invisible textual information, as well as structural information from the user interface, in order to provide it as speech output or braille output to the end user. The SAPUI5 framework is technically prepared for screen reader support. This means that all the structural information and texts needed are handed over to assistive technology. Nevertheless, the actual structure, as well as the actual visible and invisible texts, need to be defined at application level.
Supporting Accessibility at App Level
Many requirements are already covered by the technology framework, but design aspects that are related to the individual purpose of the application still need to be implemented by the individual design teams. Here are some examples:
Status updates, messages, error handling: Although the shape and appearance of system messages is predefined, ensure that the message content is clear and easy to understand. For error messages, indicate the location of the error and how to fix it.
Labels, tooltips, and placeholders: Define meaningful labels. Use tooltips according to the guideline, and ensure that they are relevant. Define clear placeholders in input fields where appropriate. For more information on placeholders, see Mask Input and Input Field.
Initial focus position: To enable users to work through a task efficiently, always set an initial focus for the task. Set the focus to either the first logical interaction element or the first element in the task.
Structure and fast navigation: Ensure that the navigation within your application is logical and follows the task structure for the intended purpose. When designing apps with a large set of functions or information blocks, always form logical groups to help users navigate efficiently. You can form logical groups using a container, a toolbar, or other grouping elements. To enable faster navigation, SAPUI5 allows users to skip groups (with F6 or Shift+F6). Also, enable direct keyboard navigation to logical groups, such as working areas or navigation areas.
Keyboard shortcuts (hot keys): While some keyboard shortcuts are supported at framework level (such as Ctrl+A to select all items), others must be defined at application level (a common one is Ctrl+S to save the current object). Support for keyboard shortcuts in SAP Fiori differs from the default browser behavior: all keyboard shortcut commands are captured by the application except Ctrl-L, which is needed to jump to the browser address bar. From there, all browser keyboard shortcuts are available. Observe industry standards and de-facto standards.
Screen Reader Support
Although screen reader support is technically prepared at framework level, it is still the developer’s task to arrange the individual UI elements in relationships that are needed for a screen reader. This is done by using appropriate floorplans, layouts, and controls for the respective use cases.
Alternative texts: Images need alternative texts and descriptions, unless they are purely decorative. Also, the default texts for icons, image placeholders, and other graphical elements may not be available or suitable for your application use case. Always review these texts, and replace or redefine them where necessary.
Landmarks: Landmarks are used by assistive technologies (such as screen readers) to provide a meaningful overview of a page or specific parts of a page. Define landmarks when you use an object page, dynamic page, or panel, for example.
For more information, see the landmark options in the corresponding API documentation:
Changes That Impair Accessibility
Be aware that any changes in the framework definitions can impair accessibility support.
Custom controls: SAP Fiori and SAPUI5 comprise an extensive set of controls. These controls come with numerous features that support accessible implementation, including keyboard enablement, resizing behavior, or support for theme changes. If you think that your use case requires a custom control, think twice. A custom control needs to fit into the interaction concept, and all the features must be coded by the app team. This includes accessibility requirements, but also many other aspects, such as globalization and writing modes (left-to-right or right-to-left), security, performance, maintenance, or documentation. Before developing a custom control, always check if your use case can be handled by existing controls. However, it is important to use controls only for their intended purpose.
For more information, see the SAPUI5 documentation.
Custom colors: Change individual colors only in exceptional cases and after very careful consideration. Bear in mind that any color changes must also be applied to the different UI element states (such as active, hovered, or inactive buttons). Additionally, these changes may not work with theme changes or high-contrast modes of the underlying operating system. When changing a single color, you may need to create an entirely new theme to ensure that the appearance of your app remains coherent and consistent.
Fixed width or height: If you set a fixed width or height, your app will no longer be responsive and adaptive. Information might get lost if the user resizes the application window, zooms, or changes the device, for example.
Embedded third party objects: An application is only as accessible as each of its parts. Embedded objects like (third party) maps or PDF forms (see PDF Viewer) often have accessibility issues. You need to either fix these issues or provide an alternative, accessible alternative way to retrieve the information and complete the task.