Product Accessibility

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

As part of the initiative to make the Emarsys platform accessible and inclusive, the Design System Team made the webcomponents 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 as well. 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. If you are not sure what semantic element to use for a specific use-case, consult with the Design System Team.

You MUST use the <button> or <a> HTML tags for buttons. While the .e-btn CSS class of the UI kit can format almost any element into a button visually, it does not mean accessibility. In order to make your buttons keyboard focusable and "clickable", you must use the aforementioned tags.

You MUST use the <a> tag if the button navigates to an external page, or to another service within Emarsys. It MUST have an href attribute present.

You MUST use <button> tag for all other use-cases, and 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 we made all current components of the Design System accessible by default, it is not true for deprecated components. Please refer to the Migration page for information on how to replace specific deprecated components.

Navigation

You MUST make it possible to navigate between the pages and views of your application with keyboard only. For this, you SHOULD use buttons, the <a> HTML tag, 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 in your application is accessible by "tabbing" (pressing the Tab and Shift+Tab keys).

You MUST NOT create focus traps (parts of the UI where the tab chain loops, and that you cannot escape by pressing Tab), unless they are modal (the user is not supposed to interact with the rest of the UI until they take an action within the modal, e.g. dialogs).

Visual elements and labels

You MUST add a descriptive alternative text to your images with the alt attribute of the <img> tag. This description also MUST be translated.

You MUST provide a descriptive label for all inputs. The label MUST be properly associated with the form input with the <label> HTML tag and the for attribute. (Note: some Design System components like the <e-checkbox> already has this built in with the label attribute).

You MUST provide a descriptive label for all visual-only elements (e.g. icon-only buttons) with the <e-tooltip> component. If the purpose of the element is absolutely clear for people who can see the element (e.g., the graphics contain the text as an image) you can use the aria-label attribute for screen-readers only.

Sections

You SHOULD should wrap individual, more distinct parts of your application (e.g., editor and preview pane in the VCE, or the available blocks pane and the program visualization in AC editor) in a <section> HTML tag instead of a <div>. You SHOULD also add an aria-label attribute to the sections that is a translated string describing the purpose of the section (e.g., "Editor toolbar"). This will allow people using screen readers to quickly navigate between sections.

Custom components

You MUST implement accessibility for your own custom components that are are not built from already accessible Design System components. More complex interactive elements should be usable with the arrow keys after they receive focus. If you have a complex, custom UI component, consult with your UX team on how to make it accessible.