Keep Reading
If you enjoyed the post you just read, we have more to say!
There are many challenges when designing and developing for accessibility.
It can be overwhelming to read about all the app accessibility rules and regulations, and more often than not, it gets marked as a “to-do” item for later when design and development teams have more time to focus on it. But it will be harder to go back to a wireframe or codebase and “fix it” to be accessible after the fact.
Making features like notifications accessible not only means more people can use and enjoy your product, the Web Content Accessibility Guidelines 2.0 (WCAG) introduces accessibility compliance that is legally required in many regions. Contrast, readability, and easy navigation are examples of accessibility that need to be considered starting at the design phase. If you are in a position where you know your app could be more accessible, don’t let yourself get overwhelmed. Make a plan to tackle app accessibility piece by piece, feature by feature.
We’re going to take a look at some key factors of accessibility and how they relate to notifications.
Readability challenges in app accessibility
Of course, visual design and branding are important, but visual design can’t take priority over accessibility. Thoughtful, intelligent decision-making about visual elements like colors and fonts will bring harmony to design and accessibility. Good design should take accessibility into account from the start.
To build solid design and branding into a feature like notifications, there are a few challenges to keep in mind throughout the design phase.
Poor color contrast
Proper color contrast can be a quick win to ensure the accessibility of a website or app. This is as simple as making sure there is enough contrast between the luminance of text or elements against their background colors. A dark font against a light background, like black text against a white backdrop, provides excellent color contrast.
Some facets of design to keep in mind for accessible notifications are:
- Text should always be readable against background colors and images (think about dark mode).
- CTAs should stand out from other content.
- Borders around or between elements (like buttons) should be clearly visible.
Illegible fonts
Text needs to be readable—that’s pretty much the whole point. It seems easy enough, but there are a few factors that can mess up your perfectly laid font plans, even if you’ve already considered app accessibility in the design phase. Fancy, custom brand fonts with lots of specialized curves and kerning may be hard to read for some people. For example, serif fonts can be harder to read for those with dyslexia—sans serif fonts are more accessible for everyone.
It’s also important to keep backup fonts in mind. If you’ve carefully planned out the use of a custom font and it fails to load, a default font (like Helvetica or Arial) will load. This backup font should be tested to make sure it’s still legible within your design and color choices.
Also, consider that users might zoom in on your website, causing the text to resize. In this scenario, the text could collapse on itself or run over other elements. If this happens inside an in-app notification box, users could receive a notification that is cut off and not scrollable.
Finally, keep an eye on how font sizes scale across mobile and desktop devices. Designers often work in pixels, and developers work in responsive units like ems and rems. These responsive units allow the text to scale when it needs to, like if someone zooms or changes the width of their browser. Adjusting and testing font sizes across various devices is a start to creating more accessible text.
Operability challenges in app accessibility
Ever tried to navigate a website without a mouse or trackpad, using only the keyboard instead? Or tried to navigate a mobile device with accessibility settings turned on? If so, you might know that without a mouse or trackpad, you need to navigate a website in alternative ways, like with a keyboard. Without proper code architecture, this can pose problems for app accessibility in notification systems, which rely on pop-ups and badges to alert users and identify an element that needs attention.
Unordered navigation
A tab index order is something for developers to be aware of—it’s what makes elements on a website selectable without the use of a mouse or trackpad. Websites and apps need to have a proper structure to navigate around and find elements, like menu options and notification inboxes.
Depending on the complexity of a website’s structure, the tab index order can get botched. This means that elements could be out of order or missed completely when using the tab key. Elements like pop-ups, modals, or toasts need to interrupt that order and be easily tab-able by the user no matter where they are focused on the site.
The tab index order is important because, on top of helping non-mouse users navigate, it tells screen readers what needs to be read aloud. If things are focused out of order, the messaging gets mixed up or missed. For example, if a user hears a notification sound, they expect to be able to tab right to that notification. If the next thing they hear isn’t the notification’s content, it could be a very confusing user experience.
And the order of the content isn’t the only thing to watch out for here. The timing of the content also needs to be taken into account. A toast notification (or pop-up modal) will typically have a preview of the full message, usually in text format. These are often displayed quickly and disappear after a few seconds.
To address app accessibility, notifications need to remain on-screen long enough for users to absorb or interact with the content, regardless of whether they use a mouse or keyboard.
Small touch targets
On any touch devices, “touch targets” are elements a user needs to physically touch to interact with the website or app, for example, a menu option for notifications. These touch targets need to be at least 44px x 44px to be large enough for app accessibility. This is important because physical motor constraints can make small targets hard or impossible to hit.
Some touch targets in notification systems would include:
- The icon and badge users click on to see their notifications
- A close button
- CTAs inside the notification
While accessible touch targets are imperative on touch devices, it’s a good habit to make them an accessible size, even on non-touch screens. Not every product has both a website and a native app for mobile phones and tablets—web apps are common practice. Web apps are responsive versions of their desktop counterparts, scaled for mobile device sizes. Maintaining at least a 44px x 44px touch point standard across all desktop and mobile designs is an easy win for app accessibility.
App accessibility with rich content design
With advancements in the types of notifications that can be sent, like rich push notifications, content is not limited to text. Sending media in notifications like images, GIFs, and videos requires additional accessibility considerations.
Failure to load
There’s a variety of reasons media content might not load—the issue could be on the user’s end, like internet connectivity, or it could be on your end, like server issues. When content doesn’t load, there needs to be associated text, such as alt text, that loads instead as a backup for the pop-up to be accessible.
Adding alt text attributes to elements is something developers will have to incorporate into the code. This alternate text gives users essential information in the case that media doesn’t load. Plus, it provides a way for those who can’t rely on sight to receive a message by reading the alt text with screen readers.
Content that plays, like videos and GIFs, could partially load and get stuck on the first frame. If the video or GIF is delivering the main message to the user, this is problematic to get the message across. If the message is contained in a video, it’s important to remember not everyone relies on sound. Videos should have accompanying captions so the message can be received by everyone.
To achieve app accessibility, the notification needs to be designed in a way where the main message doesn’t rely on rich media content. Including contextual text elements inside notifications ensures the message is clear to the user.
Flashing content and animations
The most serious accessibility consideration is flashing, flickering content and animations—content that could trigger seizures in users.
Rich media sent through notifications like videos, GIFs, and animations should avoid this jarring content. Even still, images that use a combination of certain colors and patterns can have the same effect as flashy animations. For instance, geometric patterns in extremely contrasting colors (like black and white) can have an adverse effect on people because they appear to be moving.
In-app notifications, specifically, can have custom animation effects for toasts or pop-up modals. These custom animations are used to grab a user’s attention, but they should be subtle and unobtrusive. According to WCAG, flashing animations should not take up more than 25% of 10 degrees of a user’s visual field.
Integrate accessibility with a fully customizable notification inbox
MagicBell is an inbox for your notifications with default settings or completely customizable options to enhance the experience to match your brand.
Building a custom notification system requires a lot of design and development effort, especially when you consider the myriad rules, regulations, and challenges that go into making it accessible. With a ready-to-go inbox suited to manage notifications for your users, you can dedicate design and development time to tackle issues like accessibility.
Schedule time for a demo of our inbox or simply try it yourself.
Related articles: