Skip to main content

Product Accessibility

info

TL;DR All elements in your product should be accessible with keyboard only, and all functions of your product can be used with keyboard only.

As part of the initiative to make the SAP Engagement Cloud platform accessible and inclusive, the Design System Team made the web components of the UI Kit keyboard accessible. While these components are already accessible, you must also make sure that the entirety of your application is accessible. Please follow the guidelines below.

✅ Use Semantic HTML Elements​

You MUST use semantic HTML elements to support keyboard navigation and screen readers. Most of HTML is accessible by default — don't break it.

You MUST use the <button> or <a> HTML tags for buttons. While the .e-btn CSS class can format almost any element into a button visually, it does not provide accessibility. To make buttons keyboard focusable and activatable, you must use these tags.

  • Use <a> if the button navigates to an external page or another service within SAP Engagement Cloud. It MUST have an href attribute.
  • Use <button> for all other cases. It MUST have the type attribute: type="submit" if it submits a form, or type="button" otherwise. This prevents accidental form submissions.

✅ Replace Deprecated Components​

You MUST replace non-accessible, deprecated components. While all current Design System components are accessible by default, this is not true for deprecated ones. Refer to the Migration page for details on replacing specific deprecated components.

✅ Navigation​

You MUST make it possible to navigate between pages and views of your application with keyboard only. Use buttons, the <a> tag, and the <e-tab-bar>, <e-step-bar>, and <e-layout-back-button> components.

✅ Tabbing and Tab Chain​

You MUST make sure that every interactive element is accessible by tabbing (Tab and Shift+Tab).

You MUST NOT create focus traps — parts of the UI where the tab chain loops and cannot be escaped — unless they are modal (e.g. dialogs, where the user must take action before interacting with the rest of the UI).

✅ Visual Elements and Labels​

You MUST add a descriptive alt attribute to all images. This description MUST also be translated.

You MUST provide a descriptive label for all inputs, properly associated with the <label> tag and the for attribute. (Some Design System components like <e-checkbox> already have this built in via the label attribute.)

You MUST provide a descriptive label for all visual-only elements (e.g. icon-only buttons) using the <e-tooltip> component. If the purpose is absolutely clear visually (e.g. the graphic contains the text as an image), you may use aria-label for screen readers only.

✅ Sections​

You SHOULD wrap distinct parts of your application (e.g. editor and preview pane) in a <section> tag instead of a <div>, and add a translated aria-label attribute describing the purpose of the section (e.g. "Editor toolbar"). This allows screen reader users to navigate directly between sections.

✅ Custom Components​

You MUST implement accessibility for your own custom components that are not built from already-accessible Design System components. Complex interactive elements should be usable with arrow keys after they receive focus. Consult with your UX team for complex custom UI components.