If you’re building a dynamic website, there are plenty of valid reasons to interrupt your users. You might need to tell someone if their session is about to timeout, for example, or you might want your content to refresh periodically in order to show more up-to-date information.
Those features can be useful — but they can also create accessibility issues for people with disabilities. Today, we’ll explain how web developers can provide updates that improve user experiences (including the experiences of folks who use assistive technologies).
Why Live Website Changes Aren't Great for Accessibility
Most assistive technologies are designed to work well with static websites. Screen readers are the most obvious example — they read content aloud or send the text to a user’s refreshable braille display, one word at a time.
So, what happens if you send an unexpected notification to the user? The screen reader must stop announcing the content, read the notification, and wait for the user to take action. That can be disorienting for screen reader users, particularly if they’re trying to read a longer piece of content.
And if your website reloads by using an automatic mechanism like a meta refresh with time limits, that’s an even worse experience — when the page reloads, the screen reader may start at the beginning of the page, which is an unexpected change of context for the user.
When your website is actively refreshing, sending unnecessary notifications, or interrupting the user in other ways, you’re also introducing a barrier for people with attention disorders (and for anyone who prefers a clean, straightforward experience).
What WCAG Says About Interrupting Users
The Web Content Accessibility Guidelines (WCAG) are the international standards for digital accessibility. As you might imagine, WCAG has a success criterion that directly addresses interruptions — appropriately titled “Interruptions.”
Here’s the full text of Success Criterion 2.2.4:
Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency.
This is a Level AAA criterion, which means that most websites do not need to meet this requirement in order to meet their conformance goals (and to comply with laws like the Americans with Disabilities Act).
However, Level AAA requirements are still worth your attention. Setting compliance aside, web accessibility is about creating better experiences for users — and this is a great example of how following WCAG makes your website much easier to use.
Related: WCAG Level
Tips for Implementing Realtime Updates, Refreshing Content, and Other "Interruptions"
If you’ve got dynamic content, you may have legitimate reasons to interrupt the user. It’s possible that your website simply won’t work well with screen readers; if the interruptions are truly essential, WCAG contains exceptions for those features.
But that’s not an excuse to ignore the best practices! Interruptions are only essential if your website could not function without them.
For example, if you’re building a banking website, you must automatically log users out after a certain period of idle time. You need to send them a notification before the logout occurs, and that’s going to be interruptive — but the alternative would be to suddenly log them out without notice, which is much worse.
When implementing any feature that might interrupt users, follow these tips:
- Determine whether the feature is essential.
- Give the user the option to turn off all unessential notifications, updates, or alerts.
- Provide clear instructions for disabling those unessential interruptions. You could include those instructions in your site’s accessibility statement, or just insert a toggle switch somewhere on the page.
- Dynamic content is much more likely to have keyboard accessibility issues, so test your content with a keyboard alone (no mouse) before publishing.
If you’ve got highly complex or dynamic content, you may also need WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup. We strongly recommend working with an accessibility partner when using ARIA; while it’s a useful tool, it can actually introduce serious accessibility issues when misused.
At the Bureau of Internet Accessibility, we’re ready to help organizations find sustainable, long-term accessibility strategies that improve compliance with laws like the ADA, Section 508 of the Rehabilitation Act, the Accessibility for Ontarians with Disabilities Act (AODA), and other non-discrimination laws.
To learn more, contact us to speak with a subject matter expert or get started with a free WCAG 2.2 AA compliance summary of your website.
