Screen Reader Support

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

In Emarsys, the Emarsys Design System provides accessible components, helping product teams achieve the accessibility requirements.

The foundations for good screen reader support:

• Make the structure valid and logical: make sure 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”, etc.
• Use ARIA Roles and Attributes: complement native HTML attributes and semantics with ARIA roles and attributes.

Structure

Making sure that the HTML / DOM structure follows a linear logic and nested properly helps screen readers to parse the site properly.

• Use the page templates from the Structure section in our Design System Documentation site for an accessible frame.
• Use Design System components, and avoid using custom CSS.
• Dynamic Content: JavaScript and updating parts of the page without reloading has to be handled properly, otherwise the screen reader won’t read them. It's easier to only use dynamic content when necessary.

Read more:

• HTML: A good basis for accessibility - MDN

Semantic Elements

Using semantic elements help screen readers understand the content and context of the UI better.

• Use Design System components, as they provide built-in support for accessibility.
• Use semantic HTML elements like “article”, “button”, “label” instead of non-semantic elements like “div” and “span”.
• Use heading elements properly (“h1”, “h2”, “h3”, etc.)

Read more:

• Semantics - MDN

Labeling

Many HTML elements provide native support for labeling non-textual content like images and illustrations (e.g. with “alt” attribute) and giving elements context (e.g. “labelfor” attribute).

• Alternative text: for non-decorative non-textual content, like images, icons, etc, a textual description should be provided.
  • alt attribute for images: description for the image. Screen readers use this info to describe the image. It’s displayed when the image fails to load. If empty, screen reader will skip image.
• Contextual text:
  • "label for": <label> elements can use the for attribute to point towards the id of a form element (e.g. text input).
• Hinting:
  • "placeholders": <input> elements can use the placeholder attribute to display a text for empty fields, which can be a hint to expected data, e.g. “Type search query here”.

Read more:

• • HTML: Text alternatives - MDN

ARIA Roles

ARIA roles describe elements semantically, allowing screen readers to present elements properly.

ARIA supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. E.g. ARIA enables accessible JavaScript widgets, form hints and error messages, live content updates, etc.

Only use ARIA correctly and when necessary.

Read more:

• ARIA Roles - MDN
• Using ARIA - MDN

ARIA Landmark Roles

A landmark is an important section of a page. The landmark role is an abstract superclass for the aria role values for sections of content that are important enough that users will likely want to be able to navigate directly to them, like “main” and “navigation”.

Examples:

• role="main" for <main>.
• role="banner" in <header>.
• role="navigation" for <nav>.
• role="contentinfo" for <footer>.

Read more:

• ARIA Landmark role - MDN
• Using ARIA Landmark roles

Dynamic Content Updates

Dynamic content which updates without a page reload is generally either a region or a widget. Simple content changes which are not interactive should be marked as live regions. A live region is explicitly denoted using the aria-live attribute.

In our Design System, the Notification component supports Dynamic Content Updates.

Technical details:

• aria-live: indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
  • aria-live="assertive": present to the user immediately.
  • aria-live="polite": present to the user at the next graceful opportunity, such as at the end of speaking the current sentence.
• aria-atomic: present the entire changed region as a whole.
• aria-relevant: defines which updates are important inside the live region.
  additions, removals, text, additions text, all.
• aria-busy: prevent announcements while updated are still being made in the live region, so the user is not interrupted multiple times. Use the ariaBusy JS property to change the value to false when update is complete.

Read more:

• ARIA Live Regions - MDN

Best Practices

• The flow is as linear as it can be, to make supporting focus order and reading easier.
• Elements are grouped and nested logically (e.g. action icons are put in a toolbar).
• Non-textual content like images and icons have alt texts, icon buttons have tooltips.
• Audio and video have subtitles or transcripts.
• Avoid using contextually visible text when not necessary (e.g. reduce the number of helper tooltips).
• Avoid using dynamic content updates when not necessary (e.g. dialogs).
• All interactive parts of the interface can be focused by the screen reader.
• Semantic elements are used (ul, button, label) instead of generic elements (div, span, etc.).

Testing

• Software for testing:
  • macOS: built-in VoiceOver
  • Windows: JAWS (ask office IT for license)
• Development tools in browsers:
  • Chrome Lighthouse
  • Firefox Accessibility Inspector

Check for:

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