UX accessibility: an aspect of design that mostly takes a backseat. The thing is, design and accessibility can and should live harmoniously. Your design process may be slightly longer, but your users will thank you.
Legally, the issue of online accessibility is murky. While laws exist for physical spaces, digital spaces operate by standards. Standards are not laws, and companies are not required to implement them. However, lawsuits are on the rise, and the courts often find for the plaintiff.
The best businesses can do is follow standards known to create accessible experiences, but building accessible websites and apps should not be about avoiding lawsuits. It should be about wanting to create the best experience for all your users.
Break down the elements of your notifications and find the challenges ahead of time; this will eliminate the backtracking required when you design first and account for accessibility last.
Notifications require the same considerations as any other feature, plus additional considerations because they can have simple and complex content. Creating an accessible notification experience starts with knowing what elements need careful attention.
Determine which elements need to go into a notification design and implementation:
Also consider the amount of time a notification remains on screen. Some users need more time to read or to navigate (via keyboard) to the notification.
All these things need UX accessibility attention. While it can seem initially overwhelming, learning how to build out an accessible notification or notification system can create interesting and useful learning opportunities.
There’s a lot to keep track of when it comes to accessibility; the great news is there are plenty of tools and guidelines for designers and developers. These tools and resources can be used to verify not only the UX accessibility of notifications, but also all the parts and features of a web app.
Companies generally do QA (quality assurance) in one of two ways: there’s a whole QA team that focuses just on this, or the job falls to designers and developers to check their work before a feature release. Either way, the people who do QA need to know how to build UX accessibility checks into their workflow.
Perhaps basic, but remember — test your feature(s) on:
Internet Explorer is still supported, for now. A lot of industries still rely on Internet Explorer because of legacy applications and code, so it’s important to make sure Internet Explorer users have a valid UX accessibility experience. This is especially true for notifications, which might need a custom solution to function on Internet Explorer.
Make sure elements retain their focus state everywhere. Since in-app notifications can be complex and allow you to include surveys and forms, these will require special QA attention. Forms often require users to:
Keyboard users need to be able to navigate and select within these elements. Check whether or not a notification has a proper tab order as soon as it appears. Confirm users can navigate with arrow keys and make selections with the spacebar.
Check that the amount of time a notification displays on screen before disappearing (and hopefully going into an inbox for a user to check later) is long enough to fully read and for keyboard users to navigate to.
If the notification contains media, like images, you’ll also need to check that the alt text also can be read by a screen reader. You’ll also need to simulate content failing to load in order to check that the alt text is displayed in a way that is easy to see. This way, the context of the missing content won’t be lost.
In addition to making sure your colors are contrasted enough in the design process, browsers have different color management and will render color saturation differently. Check your frequently visited websites on Firefox. You’ll likely notice that colors are very saturated on Firefox compared to Chrome or Safari. You’ll want to consider this in the design process to avoid color issues that might not arise until QA.
Depending on the webkit being used, devices can render font size differently than expected. If you’re only checking your feature on one particular device or on one particular browser, you might not be aware of this. Plenty of people discover this issue when doing QA or viewing a released feature with a different method.
Notifications should have an inbox where users can find, read, and respond to them. This allows all users to come back to your messaging and interact with it when it’s convenient for them. MagicBell provides that inbox and is completely customizable through our SDK.
Designers can have complete control. Include fonts, colors, and media accessible for everyone. Design a sidebar inbox, or create a fully separate page for notifications. Developers can remain in control of tab order and implement a UX accessibility friendly experience with elements that have Aria labels and alt text.
To find out how to give your users a great notification experience, schedule a demo today.
Here are a few related articles!
We’ll break down the implications of the constant flow of notifications to app users. We delve into the negative effects on individuals in the form of alert fatigue and the subsequent negative implications for apps and their notification success.