Does Maglr comply with the Web Content Accessibility Guidelines (WCAG)?
Yes, but you have to take into account some design rules when it comes to creating digital content with our editors. In this article, we will write down a few additional steps and points of attention for the designers that work with Maglr Pro. If you want to learn more about the WCAG, please visit: https://www.w3.org/WAI/standards-guidelines/wcag/
Accessibility Guidelines (WCAG 2.0) are used to improve the readability of content. The goal of WCAG is that everyone is able to perceive, understand, navigate, and interact with digital content. Creating publications and content with the Maglr platform can be configured to be more compliant with the WCAG guidelines. In the Pro editor, you can change and structure elements to be more accessible with the built-in Accessibility Checker.
The most important rule is that you have to describe all elements in your page that are of value to your audience, search engine, and screen reading software. For example, an image cannot be 'seen' properly by a person with a visual impairment or search engines. But when the alt- and meta description of that element is filled in correctly, both can now better understand what the element is and what purpose it serves in the context of the publication.
Another general rule of thumb for accessibility in Maglr is to keep your page simple in terms of structure and design. Don't create a complex layered page with content that is too complicated, as it could be confusing for viewers that are reading the publication with screen reading software or other assistive technology.
Maglr Pro & Accessibility
With the Maglr platform, we allow our users to create interactive publications without technical limitations. When you publish a project with pages that are made in the Pro editor, a lot is already set up automatically according to the accessibility guidelines. However, there are some points of attention that rely upon the responsibility of the user.
At Maglr, we have developed an Accessibility Checker to increase the accessibility of your publications by:
- Creating hierarchy through headings and rearranging the order of all elements
- Adding descriptions to (interactive) elements for clarification
- Hiding ‘decorative’ elements for assistive technology
In order to create the best possible experience for your viewers, each created or placed element in the Maglr Pro editor has its own accessibility options. You will find the best practices on each type of element below. For the surrounding navigation environment, no further action is necessary. Maglr has automatically made this environment accessible by default. All content that is placed here is automatically picked up by screen reading software in the correct order.
Accessibility options per element in Maglr Pro:
While texts don't require an additional description, it's very useful for both screen reading software and search engines to determine the type and importance of heading text. Users can quickly read your page by only reading aloud the headings. From there they could jump to the specific heading a start reading further from there. Quite the same how you visually scroll through a story. The same for search engines. If you set the headings correctly a search engine can better determine the topic/importance of your story.
You can set a heading level for each heading, starting with h1 (most important) and going up to h6 (least important). Be sure to use the heading element for headings, and applying a heading level through the Settings menu in the Objects tab on the right side of the editor. There is only one rule. Per scene only one H1 heading is allowed.
- Text / element order:
Open the Accessibility Checker (under Options at the top bar), to make sure your text and other elements are picked up by screen reading software in the correct order. The Pro editor is not a strict website builder. On the canvas you can freely move around texts and put them in a specific layered order. Where the reading order looks visually correct for you, the order in the code can be completely different.
When you open the Accessibility checker for the first time, we order elements based on their visual position on the page. You can manually adjust the reading order by dragging the element to the correct position. This does not change anything to your design. In the background we tell screenreaders not to follow the default position of elements, but follow our adjusted reading order.
Also, we advise using bigger font sizes voor default texts (18px minimum), since they are harder to read for visually impaired viewers.
Images need a clear (alt) description of what the image is about. If the image doesn't provide any useful information, you can simply hide it from screen readers. When you are not hiding decorative images, a screenreader could tell the reader an image is available which can be confusing if it doesn't have any important information.
- Buttons and links:
When you use buttons or create links a screenreader will read aloud the name/text of the link. A default value like : "Read this article about horses" will directly tell what's happening when I click that button. A value like: "Click here" is not telling anything. Use the accessibility description to better describe what happens when I would click that button.
Next to a description, you can upload a subtitle srt.-file for your local video (uploaded through Maglr) through the settings menu in the object tab on the right side of the editor. For YouTube/Vimeo, you can upload your subtitle files through these platforms.
Be sure to provide a clear description as to what the audio element is about. For page audio (set through the page tab in the configuration panel on the right side of the editor) it is not possible to apply a description. Be sure to never add vital audio files through this option.
Slideshow elements only have one description to describe what the slideshow is about. It is not possible to apply a description per image, so be sure to describe the contents of the entire slideshow to provide context to the reader.
Add a description to the chart that explains what that chart is displaying. A description can't always tell the whole story, but make sure the general message is communicated.
Make sure to provide a clear description for all possible form items for your viewers. This includes input fields, but also success or error messages. Especially for error messages, let your viewers know what they missed or should enter instead.
You are responsible for your own code here, so be sure to provide a clear description of the embedded content. It is advised to keep the complexity of this code to a minimum.
- Groups (& pop-ups):
Element groups can only be described when a click action is applied to them. The description should tell the viewer where they are being directed towards. You should add a description on the button but also on the group itself.
When you have a scenario where multiple groups are toggled, choose the group (from the side panel) with the informative content. So in case you have a group with textual content and a second group containing a semi-transparent background, the focus should be set on the group with content. As soon as the group opens and the focus is set on the group with the correct content a screenreader will start reading aloud these specific elements.
Also make sure to add a close button with the correct description (close this popup story, or; Go back to main story). When a user opens a pop-up using the keyboard controls, we trap the tab focus inside the group. It's possible to use the ESC key and close through group or use the TAB key to select the close button.
If groups are only decorative, you can hide them (including all elements!) from screen readers. It is also advised to keep the complexity of your groups (groups inside of groups/pop-ups inside of pop-ups) to a minimum.
Color contrast can be very important for people who are blind, have bad sight or in any way are visually impaired. Especially text and background colors are important, so make sure they can be distinguished by all viewers. Note: also check the colors of the surrounding navigation environment through its settings in the dashboard.
- Pages and scenes:
Both pages and scenes should receive a name that explains the content that can be found on them. By setting these names according to the page contents, visitors using screen readers are more able to easily navigate through them.
Animations can cause epileptic seizures, so keep in mind not to use fast and/or repeating animations that can possibly trigger those reactions. It's impossible for visitors to stop animations in Maglr publications, so don't use too many animations and make sure that they don't last longer than 5 seconds.
Points of attention for users
When you are done with the design of a page, we recommend using the Accessibility Checker to further optimise the page before publishing. This built-in module allows you to configure the following components:
- Determine reading order
All elements in the Pro editor are freely-positioned onto the canvas. Use the Accessibility Checker to bring structure to your page and to help assistive technologies to know in which order they should read the page.
- Hide decorative elements
If a decorative element on the page does not have any value to provide context, you can hide the element for assisitive technology. This element will then be skipped by screen reading software so that readers only will receive the necessary information.
- Use headings
Mark titles with different headings (h1, h2) so readers can quickly scan through the important information. Header tags provide structure and context to your page as well.
- Describe elements
Elements added to the canvas must be provided with a description. Its purpose is to describe visual elements such as images, videos, graphs and slideshow to visitors who are unable to see them. Descriptions should at least state what the element is trying to convey to the person seeing the page.
- Subtitles for videos
Always try to add subtitles to your videos. It is needed to provide content to people who are deaf and hard-of-hearing.
Limitations to WCAG
Because of the way how the freeform canvas in the Pro editor works to create digital content, there are some limitations when it comes to WCAG. There are accesibillity rules we cannot automatically implement to pages. Therefore, in case a publication needs to fully comply with the Accessibility Guidelines (WCAG 2.0) the following items should be paid extra attention to:
- Limited page zoom possibilities
Text elements in the Pro editor are absolutely positioned on the canvas, meaning that these element types cannot be enlarged via zoom settings. Therefore, it is recommended to use a font size of at least 18px, where it is not necessary for readers to zoom in on the texts.
- Color contrast
The WCAG recommends minimum levels for color contrast between text and background, based on a mathematical formula. Color contrast is important as it affects some people's ability to perceive the content visually. Because Maglr Pro is a design tool for digital content, we do not have any restrictions for the use of any color combinations. Therefore, you must be able to correctly assess this yourself or use a Color Contrast Checker.
- Complex constructions
The Pro editor allows you to create interactive pages where visitors can click and interact with content through popups or hidden layers. But for visually impaired visitors, it can be hard and complicated to navigate or understand this type of interaction. Technically, we can identify popups and hidden layers for assistive technology to help readers understand. But if you're creating a popup within a popup, you're creating a digital maze for your visitor to navigate through. Therefore, it is recommended to keep this type of complexity to a minimum to optimise your page and make it accessible to all viewers.
Within the accessibility guidelines, it is possible to use animations in your publication. However, we recommend that you don't overdo it. Keep it clean and simple, whereas you want your content to comply with the WCAG.
If you take into account the limitations mentioned above and always double-check your content with the Maglr Accessibility Checker, it is perfectly possible to create publications that comply with the current WCAG regulations.