How to Build Accessible Content in Mapp Engage (for Developers)

Introduction

This article provides technical guidance for developers and advanced users who work with custom HTML content in Mapp Engage, such as reusable templates, content blocks, or direct HTML input. It focuses on realistic accessibility practices for HTML email and reflects the technical constraints of email client environments.

Note
This How-To focuses on HTML/CSS implementation. Content-related guidance (for example, writing accessible copy or choosing fonts) is covered in separate accessibility documentation aimed at content and marketing teams.

Disclaimer
Accessibility requirements may vary by region. This document does not constitute legal advice. Mapp does not guarantee compliance with any specific legislation. Responsibility for accessible implementation lies with the organization using the platform.

Key Principles

When building accessible content, the following core principles apply:

Use semantic HTML wherever possible
Ensure visual content is perceivable by screen readers
Support keyboard-only navigation
Avoid behaviors that may cause confusion or discomfort
Build and test for robustness across clients and accessibility tools

1. Structure & Semantics

Note
Support for semantic HTML is limited and inconsistent across email clients. Apply these principles where supported and always test in relevant email environments.

Use semantic elements where supported
While rendering engines in email clients can be limited, you should still:
- Use real headings (<h1> to <h3>) to define structure
- Use <ul>, <ol>, and <li> for lists – avoid faking lists with <p> + dashes
- Use <strong>, <em> for emphasis – not just CSS
Declare document language
Use the lang attribute on the root container of your HTML snippet:
```
<body lang="en">
```
Avoid layout tables when possible
If tables are necessary for layout, mark them explicitly as presentational:
```
<table role="presentation" border="0" cellpadding="0" cellspacing="0">
```

2. Images & Media

Use meaningful alt text for content images
Screen readers read alt text aloud – keep it short but descriptive.
```
<img src="product.jpg" alt="Red waterproof backpack with roll-top closure" />
```
Decorative images should have empty alt text
If an image is purely decorative or part of the layout, use:
```
<img src="line.png" alt="" role="presentation" />
```
Avoid text-in-image for critical information
Important information should be provided as real text wherever possible. If images are unavoidable, ensure the text is available through alternative means.

3. Colors & Contrast

Do not rely on colour alone to convey meaning
Ensure sufficient contrast between text and background
Be aware that some email clients automatically modify colours (for example, Dark Mode)

Test contrast combinations using established accessibility tools and validate rendering across clients.

4. Links & Interactions

Use descriptive, unique link text
Avoid multiple “Click here” or “More” links. Instead:
```
<a href="report.pdf">Download the 2025 Trend Report (PDF)</a>
```
Ensure keyboard accessibility
All actionable elements (links, buttons) should be reachable using Tab and activatable with Enter or Space. Avoid relying on JavaScript that overrides native behavior.

5. Fonts, Layout & Responsiveness

Use readable, web-safe fonts
Avoid decorative or ultra-light fonts
Maintain a logical reading order when styles are removed or interpreted linearly
Use flexible layouts that adapt to different screen sizes

6. Avoid Common Accessibility Issues

Auto-playing or rapidly flashing animations
Content that depends on hover-only interaction
Missing text alternatives for icons or buttons

7. Testing & Debugging

Test HTML email content using:

Screen readers (for example, NVDA or VoiceOver)
Colour contrast tools
Multiple email clients and devices

Testing is essential due to inconsistent accessibility support across email environments.

8. ARIA Attributes

Note
ARIA attributes are not reliably supported in HTML email clients and should be used with caution. Do not rely on ARIA for core accessibility behaviour in email.

Use sparingly and only when necessary – incorrect use can reduce accessibility.

Examples:

<!-- Hide content from screen readers -->
<div aria-hidden="true">Decorative divider</div>

<!-- Provide label for icon link -->
<a href="..." aria-label="Go to cart">
  <img src="cart.svg" alt="" />
</a>

Avoid ARIA overuse – support varies between screen readers and email clients.

9. Recommended Fallbacks

Ensure basic readability when images, styles, or advanced features are not supported. Content should remain understandable in degraded rendering conditions.