Skip to main content

Accessibility of emails, forms and hosted pages

Zoltan Wagner avatar
Written by Zoltan Wagner
Updated over a week ago

Envoke follows WCAG 2.1 level A guidelines to display content that's visible to your audience.

This content includes:

  • Email messages

  • The email preferences page

  • Forms

  • The email archives page

Internal accessibility (the app / user interface) is limited due to the complex nature of the application using visual, drag and drop interfaces.

Default vs. user defined accessibility

The email editor provides options to create accessible email templates and messages but it's up to the users to utilize these accessibility options (for example to use ALT tags) and to design emails in an accessible manner (for example don't use images alone to convey meaning).

The form editor uses default field labels. If these are customized then it's the user's responsibility to supply appropriate and descriptive labels.

The email preferences page and the email archives page are accessible by default without additional input from users.

Accessibility details

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities.

Envoke's approach to following these guidelines are explained below.

For accessibility details related to forms check this article.


Provide text alternatives for non-text content

  • All default non-text content has a text alternative. It is user's responsibility to ensure their images have appropriate alt text and form elements have appropriate labels.

Provide captions and other alternatives for multimedia

  • This means audio / video and generally does not apply to Envoke. It's theoretically possible to embed multimedia in a landing page or in non-standard email HTML β€” in those cases it's the user's responsibility to ensure there are captions and appropriate descriptions in place.

Create content that can be presented in different ways, including by assistive technologies, without losing meaning

  • All default content meets this criteria. Appropriate ARIA tags are used when standard semantic HTML does not suffice. This primarily applies to forms. For accessibility details related to forms check this article.

Make it easier for users to see and hear content

  • We do not use colour as the sole means of conveying information in any default content. It is the client's responsibility to not use colour in this way. We have no default audio content β€” in rare cases where embedded by the client it is their responsibility to ensure necessary controls are available.


Make all functionality available from a keyboard

  • Forms and the email preference page are fully operable from the keyboard. Links in emails and the email archive page can be navigated using tabs and clickable using the keyboard.

Give users enough time to read and use content

  • Generally does not apply: there is no time sensitive or auto-scrolling content.

Do not use content that causes seizures or physical reactions

  • All default content meets this criteria. It's possible a client may use animated GIFs or similar media β€” in those cases it's their responsibility to not use inappropriate flashing or blinking content.

Help users navigate and find content

  • All default content is titled, respects standard focus order, and is reasonably short so that additional navigation tools are not required. It is the client's responsibility to add anchors to help the user navigate long emails.

Make it easier to use inputs other than keyboard


Make text readable and understandable

  • The language of all HTML documents is declared. The colours, fonts, and font sizes in default content are high contrast and legible. Appropriate readability is the client's responsibility if colours or fonts are changed.

Make content appear and operate in predictable ways

  • Generally does not apply: focus changes do not change context. Only when forms are in "validation" state do input changes affect context (displaying if the field has become valid or invalid). In this case behaviour is predictable and helpful.

Help users avoid and correct mistakes

  • Validation errors in forms or the email preferences page are identified and the error is described to the user in text. It is the client's responsibility to supply appropriate and descriptive labels to form fields.


Maximize compatibility with current and future user tools

  • All content is parsable and valid HTML. The name, role, and state of form elements can be programmatically determined. It is the client's responsibility to ensure titles are used for links where appropriate.

Did this answer your question?