Design System Accessibility

Decorative background image
Discover / SAP Design System / Product Standards / Design System Accessibility

Intro

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: the framework level, where fundamental features are built in, and the application level, where teams must address app-specific context.

Accessibility Provided at Framework Level

Many fundamental accessibility features are built into the core design elements and are available to app teams out of the box. This ensures consistency across all products.

Visualization

Minimum contrast: Following the requirements of our SAP Product Standard for Accessibility, SAP Fiori's default theme is designed to meet minimum color contrast requirements. High-contrast themes are also provided, supporting the required contrast ratio of 7:1 for text. These can be selected in the user settings and are saved as a preference until changed.

More information:

Consistency of icons: A comprehensive icon library ensures consistent icon usage within and across products. The library includes predefined descriptions, enabling development teams to use consistent icons and to implement meaningful tooltip descriptions as textual alternatives for graphical elements. In some cases, these descriptions may need to be adapted to fit a specific use case.

For more information, see Iconography.

Keyboard focus visualization: Focus visualization is essential for user efficiency. SAP Fiori applies a contrast ratio that makes the current focus indicator visible across all themes.

Layout adaptation for different devices: SAP Fiori can run on various devices. Therefore, it includes a responsive layout that adapts to the display resolution parameters of individual devices.

For more information, see Multi-Device Support: Responsive vs. Adaptive.

Support for text resizing: Users can manually adjust the font size using browser zoom. The responsive layout automatically adapts to these adjustments.

For more information, see Multi-Device Support: Responsive vs. Adaptive.

Keyboard Support

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 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).

Messaging Patterns

Standard messaging patterns (busy, errors, notifications): SAP Fiori includes a message system that ensures system messages appear at predefined locations with a consistent design.

For more information, see Message Handling.

Screen Reader Enablement

Screen readers retrieve visible and invisible textual information, as well as structural information from the user interface, and order to provide the end user with speech or braille output.

The SAPUI5 framework is technically prepared for screen reader support, meaning that all the structural information and texts needed are handed over to assistive technology at the framework level. The actual structure, as well as the actual visible and invisible texts, needs to be defined at the application level.

Changes That Affect Accessibility

Changes to framework definitions can impair accessibility support. The following are common areas of concern.

Custom Controls

SAP Fiori and SAPUI5 include an extensive set of controls with built-in support for accessible implementation, including keyboard enablement, resizing behavior, and theme changes. When evaluating whether a custom control is necessary, it is important to verify that no existing control can fulfil the use case.

A custom control must fit into the interaction concept, and all accessibility requirements, as well as other aspects such as globalization, writing modes (left-to-right or right-to-left), security, performance, maintenance, or documentation must be addressed and coded by the application team. Controls should only be used for their intended purpose.

For more information, see the SAPUI5 documentation.

Custom Colors
Individual colors should only be changed in exceptional cases and following careful consideration. Any color changes must also be applied consistently across the various UI element states, such as active, hovered, and inactive, and may not be compatible with theme changes or the high-contrast modes of the underlying operating system. In some cases, a color change may require the creation of an entirely new theme to maintain visual coherence and consistency.
Fixed Width or Height
Setting a fixed width or height removes responsive and adaptive behavior. Content or information may be lost or obscured when a user resizes the application window, applies zoom, or switches devices.
Embedded Third-Party Objects

An application is only as accessible as each of its parts. Embedded objects such as third-party maps or PDF forms (see PDF Viewer) may introduce accessibility issues. These issues should be resolved directly, or an accessible alternative means of accessing the information and completing the task should be provided.

For more information on accessibility in PDF documents, see PDF Accessibility (Product Standard Portal, Accessibility).

Supporting Accessibility at App Level

Many requirements are covered by the technology framework, but design aspects related to the specific purpose of an application must be addressed by the individual design teams. Here are some examples:

Understanding

Status updates, messages, error handling: Although the shape and appearance of system messages is predefined, message content should be clear and easy to understand. Error messages should indicate the location of the error and provide guidance on how to resolve it.

Labels, tooltips, and placeholders: Labels should be meaningfully defined. Tooltips should follow the guideline and remain relevant to the context. Where appropriate, Mask Input and Input Field.

Keyboard Operation

Initial focus position: Setting an initial focus position enables users to work through a task efficiently. The focus should be set to either the first logical interaction element or the first element in the task.

Structure and fast navigation: Navigation within an application should be logical and reflect the task structure for its intended purpose. For applications with a large number of functions or information blocks, logical groupings aid in more efficient navigation. Logical groups can be formed using containers, toolbars, or other grouping elements. SAPUI5 allows users to skip between groups using F6 or Shift+F6 and supports direct keyboard navigation to logical areas such as working areas or navigation areas.

Keyboard shortcuts (hot keys): Some keyboard shortcuts are supported at the framework level (such as Ctrl+A to select all items), while others are defined at the application level (such as Ctrl+S to save). 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. Application-level shortcuts should respect industry and de-facto standards.

For more information on keyboard shortcuts in SAP Fiori applications, see Fiori Keyboard Interaction (wiki).

Screen Reader Support

Although screen reader support is prepared at the framework level, it remains the development team's task to arrange individual UI elements in the relationships required by a screen reader. This is done by using appropriate floorplans, layouts, and controls for the respective use cases.

Alternative texts: Images require alternative texts and descriptions unless they are purely decorative. The default texts for icons, image placeholders, and other graphical elements may not be available or suitable for your application use case and should be reviewed and redefined where necessary.

Landmarks: Landmarks are used by assistive technologies to provide a meaningful overview of a page or specific parts of a page. Landmarks should be defined when using an object page, dynamic page, or panel.

For more information, see the landmark options in the corresponding API documentation: