Accessibility in messaging
Learn the tools and best practices for creating inclusive and accessible messages in Airship.
Accessibility ensures all users, including those with disabilities, can receive and understand your communications, interact with your brand, and engage with your products or services. The evolving landscape of accessibility regulations and legislation coming into effect, such as the European Accessibility Act, amplifies its importance.
This guide will help you create accessible content for those with a wide range of abilities, including those with visual, hearing, physical, and cognitive disabilities.
While Airship provides tools to support accessible message creation, you are responsible for ensuring your content meets applicable accessibility requirements and standards, such as the Web Content Accessibility Guidelines (WCAG), a set of internationally recognized technical standards for accessible content.
Understanding your audience
To build accessible content, it’s essential to understand the diverse ways your audience may interact with information due to varying abilities and conditions.
Consider the following for each area of disability:
Disability type | Considerations |
---|---|
Visual | Visual disability can range from mild vision loss, including color vision deficiencies, to total blindness. Your users may rely on screen readers to listen to text, adjust text size and colors, or use refreshable Braille. |
Hearing | Users with hearing impairment rely on transcripts and captions for audio content. They might need media players that allow adjustment of caption size and colors and have controls to stop, pause, and adjust volume independently. |
Physical | Physical disability can affect muscle control, movement, or sensation. Users often rely on keyboard support for interaction and need large clickable areas, sufficient time to complete tasks, and visible indicators of focus. |
Cognitive | Cognitive disability may affect how people understand information, hear, move, see, or speak. Such users benefit from clearly structured content, consistent labeling, predictable interactions, various navigation options, and settings to turn off distracting elements. Simpler text, supported by images, is also beneficial. |
Accessibility best practices
Creating accessible content doesn’t require perfection. Starting with small, thoughtful choices and improving over time can make a big difference in the short and long term. The following best practices apply across all messaging channels.
Content structure and flow
How you organize and present your content significantly impacts accessibility. Well-structured content helps users navigate and understand your messages more effectively.
Follow these best practices for content structure and flow:
Best practice | Implementation detail |
---|---|
Break content into clear sections | Use headings, bullet points, and lists to improve scanability and comprehension for all users, especially those relying on screen readers or keyboard navigation. |
Use built-in heading styles | Use built-in headings such as Heading 1, Heading 2, and Heading 3 in visual composers or H1, H2, and H3 in HTML to structure your content visually and logically. Don't rely on bolding or increasing font size to create visual headings, as screen readers will not recognize these as headings. |
Maintain heading order | Organize heading levels hierarchically. For example, Heading 3 should always follow Heading 2, which should always follow Heading 1. This helps users of assistive technologies navigate and understand the document's structure. |
Maintain a sequential hierarchy | Don't skip heading levels, where Heading 3 follows Heading 1 without Heading 2 in between, as it breaks the structure and can confuse screen reader users. |
Readability and clarity
Clear, readable text benefits everyone, but it’s especially crucial for users with cognitive disabilities, visual impairments, or those using screen readers. Consistent formatting and simplicity can go a long way.
A good rule of thumb is to write short and clear sentences. Aim for a seventh-grade reading level to ensure content is easy for everyone to understand, including those using screen readers or who have cognitive processing difficulties.
Follow these formatting best practices for readability and clarity:
Element | Best practice |
---|---|
Font size | Select a body text size of at least 14 pixels with proportionally larger headings for adequate readability. |
Line and paragraph spacing | Line-height should be around 1.5. Paragraph spacing should match the height of one line. |
Text alignment | Avoid justified text, which creates uneven word spacing that can be difficult to read for people with dyslexia or cognitive disabilities. |
Emphasis | Use bold, italic, and uppercase sparingly, as overuse of those can make content hard to read, especially for people with dyslexia or visual impairments. |
Links and buttons | Clearly label link and button text in a way that describes what happens next. This helps screen reader users and those navigating with a keyboard know what to expect. Avoid ambiguous phrases. For example, instead of "Click here", use "Click here to register". |
Symbols and emojis | While playful, special characters and emojis may be confusingly interpreted when read aloud by screen readers. For example, 👍🏽 might be read as "Thumbs up, medium skin tone", or 😂, which is typically used to express laughter, might be read as "face with tears of joy." Use them sparingly and ensure they don't replace clear, descriptive text. |
Images and color
Visual design choices directly affect accessibility. From color contrast to image descriptions, these elements must work for users with varying visual abilities and those using assistive technologies.
Follow these best practices for images and color:
Alt text for images: Provide concise, descriptive alternative text (alt text) for every meaningful image:
- In ScenesA single or multi-screen in-app experience cached on users’ devices and displayed when users meet certain conditions in your app or website, such as viewing a particular screen or when a Custom Event occurs. They can be presented in fullscreen, modal, or embedded format using the default swipe/click mode or as a Story. Scenes can also contain survey questions., use the Alternative text field for the Media or List element.
- Use the
alt
attribute when providing HTML for email, Message CenterA place in your app where you can display persistent rich messages, including HTML, video, etc. Similar to email, Message Center represents both the medium (the in-app inbox) and the message type (the messages you send to the inbox). messages, landing pages, or In-App AutomationsMessages cached on users’ devices and displayed when users meet certain conditions within your app, such as viewing a particular screen or opening the app a certain number of times.. When using the WYSIWYG editor, use the Alternate Text field for images. - The alt text should accurately describe what is in the image or its function, avoiding generic marketing jargon.
- Keep it short, yet specific, ideally 125 characters or less.
- Avoid introductory phrases like “image of” or “picture of”, as screen readers already announce an image.
- Reflect any essential text that appears in the image within the alt text.
- If an image functions as a link or call to action, describe the intended action, for example, “Shop the Fall Collection”.
- For decorative images such as a patterned or scenic background used purely for style, leave alt text fields blank when configuring your message so screen readers know to skip them. In HTML, leave the value empty:
alt=""
.
Avoid images of text: Do not embed text within images whenever possible. Screen readers cannot read text in images, and users cannot easily adjust font size or color. If text must remain in an image, ensure it has high contrast, a large font size of at least 18 pt (24 px) non-bold and 14 pt (18.66 px) bold, and descriptive alt text.
Light and dark modes: Design your content to adapt appropriately for light and dark modes. This allows users to choose the display setting that’s most comfortable for their eyes, reducing strain and improving readability. When creating your content, ensure that:
- Text and background colors have sufficient contrast in both light and dark environments.
- Images and graphics are legible and don’t rely on color alone to convey information, as colors can appear differently or be inverted in dark mode.
- The visual experience remains consistent and user-friendly, regardless of the user’s preferred display setting.
Color contrast: Ensure sufficient color contrast for all text against its background. This helps users with low vision or those viewing content in challenging conditions.
These contrast ratio minimums are according to WCAG 2.2 AA :
Content type Minimum contrast ratio Standard text (body, buttons, links) 4.5:1 Large text (at least 18 pt (24 px) non-bold and 14 pt (18.66 px) bold) 3:1

Buttons and links
Interactive elements like buttons and links are critical touch points in your messages. Making them accessible ensures all users can navigate and complete desired actions successfully.
Follow these best practices for buttons and links:
Best practice | Implementation detail |
---|---|
Write clear, action-oriented button labels | Use button labels that precisely describe their intended action. For example, "Submit order" is preferable to "Submit". Keep the labels concise to prevent truncation. |
Include content descriptions for buttons | Provide a concise and descriptive content description, sometimes called an accessibility label or alt text, for each button. Screen readers read this description aloud, which helps users understand the button's purpose and action, especially when the visual label is short or ambiguous. For example, an "Add" button might have a content description "Add item to cart". |
Make buttons and links easy to select | Ensure your buttons and links are large enough and spaced sufficiently apart, especially for mobile users with motor disabilities. This reduces errors and improves everyone's experience. We recommend a minimum button size of 44 x 44 pixels. |
Use appropriate HTML elements |
|
Video
Video content requires special consideration to be accessible. These elements, from captions to playback controls, ensure your videos reach the widest audience possible.
Follow these best practices for video:
Best practice | Implementation detail |
---|---|
Provide closed captions | Include closed captions with your videos to assist users who are deaf or hard of hearing, those watching in sound-off environments, or non-native speakers. Airship does not automatically generate captions. You are responsible for adding them. |
Provide accessible playback controls | Ensure embedded videos include controls like play, pause, mute, and seek so all users can operate the video as needed. |
Avoid auto-play | Do not set videos to play automatically. Auto-play can be jarring or disorienting for users relying on screen readers, those with motion sensitivity, or anyone in a quiet environment. Let users choose when to play a video. |
Avoid flashing or strobing content | Do not include videos with flashing or strobing effects, especially at high frequencies, as they can trigger seizures in users with photosensitive epilepsy. |
Applying accessibility in Airship
This section provides accessibility information for specific message types.
Email, Message Center, and landing pages
Understanding how to apply accessibility principles when creating content for email, Message CenterA place in your app where you can display persistent rich messages, including HTML, video, etc. Similar to email, Message Center represents both the medium (the in-app inbox) and the message type (the messages you send to the inbox). messages, landing pages, and In-App AutomationsMessages cached on users’ devices and displayed when users meet certain conditions within your app, such as viewing a particular screen or opening the app a certain number of times. ensures that your messages will meet all user needs.
WYSIWYG editor: The Audit tab in the WYSIWYG editor helps you spot accessibility issues, such as missing alt text for images, missing links for buttons and menus, and image URLs that aren’t properly linked. Additionally, you can set font sizes, adjust spacing, and set proper heading levels. See Accessibility audit in Styling and formatting in the WYSIWYG editor.
Custom HTML: If you are working with custom HTML, use the following conventions, elements, and attributes:
Semantic HTML: Employ HTML elements for their intended purpose. For example, use
<p>
for paragraphs and<h1>
for primary headings, rather than styling generic elements. Most HTML elements have built-in accessibility support.Language attribute: Specify the content’s language in the
<html>
tag. For example,<html lang="en-us">
. This allows screen readers to pronounce the message correctly, preventing mispronunciations if the content isn’t in the user’s default language. In the WYSIWYG editor, the language value can be set in Settings.ARIA attributes: Accessible Rich Internet Applications (ARIA) attributes can provide additional context to assistive technologies for elements that lack inherent meaning, like
<div>
or<span>
. ARIA should only supplement, not replace, semantic HTML. Incorrect use of ARIA can do more harm than good, so use it only when native HTML elements cannot meet your needs.Descriptions of commonly-used ARIA attributes:
ARIA attribute Description aria-label
This attribute adds an accessible name to elements without a visible text label, such as icons. aria-labelledby
This attribute connects an element to an existing visible label, helping assistive technology name parts of your content. aria-hidden="true"
This attribute hides purely decorative elements used for style, such as sparkles or check marks, from screen readers, creating a cleaner experience. Using alt=""
for decorative images is generally preferred overaria-hidden="true"
for images.role="presentation"
This attribute informs assistive technologies to ignore layout-only elements, such as tables used for visual alignment in emails, preventing them from being interpreted as data tables. aria-live="polite"
This attribute announces dynamic content updates that don't require user interaction, such as success messages or notifications. For a full reference, see ARIA states and properties (attributes) in Mozilla’s Web technology for developers.
Scenes
When configuring ScenesA single or multi-screen in-app experience cached on users’ devices and displayed when users meet certain conditions in your app or website, such as viewing a particular screen or when a Custom Event occurs. They can be presented in fullscreen, modal, or embedded format using the default swipe/click mode or as a Story. Scenes can also contain survey questions., use the following settings and tools to provide accessibility in your content:
Tool or setting | Best practice | Configuration resource |
---|---|---|
Alternative text | Use this field to add descriptive alt text for all images in your Scene screens, especially if the image has an associated action. See Images and color above. For configuration information. | List and Media in Configuring Scene content |
Content description | Use this field to provide descriptive text to be announced by assistive technology, such as screen readers. For buttons, the content description overrides the announcement of the label text. Use it when a button label does not fully express its purpose. In the Question and NPS content elements, the Question field functions as the content description, so it is not configured separately. | Button or Button Group, Custom View, Email, SMS, and Text Input in Configuring Scene content |
Mark as heading | Use this property to specify the content of a text field as a heading for navigation using assistive technology. This helps you create a clear and logical heading structure in your content. | Text in Configuring Scene content |
Light and dark mode colors | Apply sufficient color contrast for all text and interactive elements to ensure readability in both Light and Dark modes. You can set values manually or create Color SetsA named pair of hexadecimal color values supporting device Light and Dark modes. Color sets can be selected for any color field in a scene and when configuring the default appearance of Scenes and In-App Automations. Dark mode is supported for Scenes only. in your brand guidelines and apply them to button, text, and input styles you can select when configuring your Scenes. Use the Light/Dark mode preview tool to verify dynamic color adaptation. |
|
Video controls, mute, and autoplay | In the design properties for video in the Media element, two settings are enabled by default: Show video controls displays player controls, information, and options at the bottom of a video, and Muted loads the video in muted state. Also, Autoplay is disabled by default. | Media properties in Configuring Scene content |
Text and color preview tools | As you create or review your Scenes, a device preview displays its appearance, and you you can apply various tools to adjust the preview. Use the Text scale tool to see how content will appear on devices using text size accessibility features. Use the Light/Dark mode preview tool to verify dynamic color adaptation. | Preview tools in Configuring Scene content |
Testing your messages for accessibility
Creating accessible messages is an ongoing process, and testing is critical. While automated tools can identify many issues, manual review ensures that what you send looks and works as intended.
Automated tools cannot reliably detect issues such as:
- Logical focus order of interactive elements
- Full keyboard operability without a mouse
- Meaningful description in alt text
- Proper use of headings to organize content
- Clearly labeled and understandable links and buttons
- Sufficient size and spacing of touch targets
- Text contrast on background images
- Overall clarity and helpfulness of instructions or labels
Even if your message passes automated checks, also complete the following steps manually:
- Review any flagged issues carefully, especially those that might require human judgment.
- Perform testing using tools like screen readers, keyboard-only navigation, and browser zoom to simulate different access needs.
Combine automated checks with thoughtful manual reviews to create more inclusive and usable campaigns for every recipient.
Continuous improvement and feedback
Accessibility is not a one-time review. It’s a continuous practice. We are committed to helping you create accessible content and continually improve our platform’s accessibility features. If you have feedback about the accessibility of Airship or messages sent from Airship, please reach out to your Account Manager or contact Support .
Categories