WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Status Messages


From: Mallory
Date: Apr 22, 2019 11:48AM

Hi Terri,

tldr: the <title> tag sounds like it may help for your particular concern.

Since we've got other users as well as fully blind ones who we'd worry will miss important messages (including low-vision screen magnification users who can easily miss little status messages as well as deaf-blind Braille-only users and fully-sighted users who hyper-focus on parts of content in order to successfully process whatever the task is), I think new messages which appear only on a new page load make sense to be both near the top (as far as DOM source order) as well as visually placed near the top and left (in left-to-right language pages) of the viewport, so that while it may not automatically read, it should be one of the first things people run into. If it has a focusable in it, that can help: keyboarders will come across it early, and especially with screen magnification this can keep a message from getting missed.

However for error-y things I've tried putting the problem/idea/message in the page title and the h1 if that is sensible. For example, someone is on a form page called "Personal Details - Step 1 - Insurance company name" and they've submitted the first form in a series of little forms and a new page (with a problem) appeared, the page title may be adjusted to "Personal Details problem: address undeliverable - Step 1 - Insurance company name" and the h1 of the page, assuming it's located in a sane area where all users end up there to get to the task-part of the page also mentions this.

This area can really be dependent on the general page structure, type of content and what the usual user flow is for the tasks on those pages. It wouldn't surprise me if while what I said above could work in a lot of places, your particular application needs to be different because of however it's set up, or whatever it is people are doing. That can make having some kind of site-wide policy that works everywhere difficult.

But I keep in mind: what's the first thing some people hear? What's the first thing some people see? Where do people tend to jump to when they're: starting a task, in the middle of a task, or thinking they may be done with a task? And that should help your team figure out what works. That and some user testing of the solutions.


On Mon, Apr 22, 2019, at 7:17 PM, Hays, Terri wrote:
> Hi - I have a question regarding how to handle informational messages.
> We have multiple scenarios where an action is taken by a user and an
> informational message is loaded (the entire page reloads with the new
> message) or the user is directed to a new page where an informational
> message is displayed. These messages vary from notifying the user that
> their physical address is undeliverable to letting the user know their
> message was successfully sent.
> In both instances the page reloads completely so I don't think it's a
> direct failure of WCAG 4.1.3, but we feel it is important to relay this
> information to the screen reader users. Since the page does a
> complete refresh, Aria role=status doesn't work and role=alert seems to
> be more geared to error messages. One idea we had was to force focus
> to the message so that the screen reader will read it immediately on
> page load, but this would cause the user to bypass the menu and the H1
> (which could create an issue with WCAG 2.4.3 - focus order).
> Thoughts? Any recommendations would be greatly appreciated.
> Terri Hays
> Accessibility Compliance Team (ACT)
> > > > >