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.
Perceivable
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.
Operable
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
Generally does not apply: all content is accessible with a single pointer and does not require multi-touch or complex gestures for successful interaction. It is the client's responsibility to supply appropriate labels and alt text to their content where applicable (https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=253#input-modalities)
Understandable
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.
Robust
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.