Skip to main content

Screen Reader Support

Screen readers retrieve textual and structural information from the user interface to provide speech or braille output. This mainly depends on properly structured front-end code, the use of semantic elements (or ARIA attributes), and extensive labeling.

The SAP Engagement Cloud Design System provides accessible components to help product teams meet accessibility requirements.

Foundations for good screen reader support:

  • Make the structure valid and logical — ensure the HTML and DOM structure is nested properly and uses elements correctly.
  • Use semantic elements — use native HTML semantic elements instead of generic ones.
  • Label everything — use native HTML attributes like alt, for, placeholder, etc.
  • Use ARIA roles and attributes — complement native HTML with ARIA roles and attributes when needed.

Structure​

A logical, linear HTML structure helps screen readers parse the page properly.

  • Use page templates from the Structure section in the Design System for an accessible frame.
  • Use Design System components and avoid custom CSS that overrides semantics.
  • Handle dynamic content (JavaScript-driven updates) carefully — screen readers won't read content that updates without a page reload unless explicitly marked.

Semantic Elements​

Using semantic elements helps screen readers understand content and context.

  • Use Design System components for built-in accessibility support.
  • Use semantic HTML elements — article, button, label — instead of non-semantic elements like div and span.
  • Use heading elements properly (h1, h2, h3, etc.) to create a logical document outline.

Labeling​

Many HTML elements provide native support for labeling non-textual content.

  • Alternative text — for non-decorative images, icons, etc., provide a textual description via the alt attribute. If empty, screen readers skip the image.
  • Label for — <label> elements use the for attribute to associate with a form element's id.
  • Placeholders — <input> elements can use placeholder to hint at expected data (e.g. "Type search query here"), but do not replace labels with placeholders.

ARIA Roles​

ARIA roles describe elements semantically, enabling screen readers to present them correctly. Only use ARIA when necessary — native HTML semantics are preferred.

Landmark Roles​

Landmark roles mark important page sections that users may want to navigate directly to.

RoleElementDescription
main<main>Primary content of the page
banner<header>Site header
navigation<nav>Navigation links
contentinfo<footer>Footer information

Dynamic Content Updates​

Dynamic content that updates without a page reload should be marked as live regions using aria-live.

AttributeDescription
aria-live="assertive"Present to the user immediately
aria-live="polite"Present at the next graceful opportunity
aria-atomicPresent the entire changed region as a whole
aria-relevantDefines which updates matter (additions, removals, text, all)
aria-busyPrevents announcements while updates are still in progress

The Notification component in the Design System supports dynamic content updates.

Best Practices​

  • Keep the flow as linear as possible to make focus order and reading easier.
  • Group and nest elements logically (e.g. action icons in a toolbar).
  • Provide alt texts for images and tooltips for icon buttons.
  • Provide subtitles or transcripts for audio and video.
  • Avoid using contextually visible text unnecessarily (reduce helper tooltips).
  • Avoid dynamic content updates when not necessary (e.g. prefer inline changes over dialogs).
  • All interactive elements must be focusable by the screen reader.
  • Use semantic elements (ul, button, label) instead of generic elements (div, span).

Testing​

Screen reader software:

Browser developer tools:

Check for:

  • Missing content: labels, alt text, missing translations
  • Incorrectly read content: acronyms, pronunciation, duplications
  • Dynamic content: popup messages, dialogs, etc.