E-mail List Archives
Thread: Status Messages
Number of posts in this thread: 3 (In chronological order)
From: Hays, Terri
Date: Mon, Apr 22 2019 11:16AM
Subject: Status Messages
No previous message | Next message →
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)
From: Mallory
Date: Mon, Apr 22 2019 11:48AM
Subject: Re: Status Messages
← Previous message | Next message →
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.
cheers,
Mallory
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)
>
>
> > > > >
From: Jim Homme
Date: Tue, Apr 23 2019 7:24AM
Subject: Re: Status Messages
← Previous message | No next message
Hi Terry,
I'm sure this is not normal UX practice, but if it were me, I would do it this way, since it sounds like you are trying to ensure that nobody misses a message. I would make it so that all messages load in a short page that shows the message and instructions about how to get back to the page where they came from. I'd probably load the new page in its own tab. I'd also investigate controlling focus, in case that is necessary. Without having tested the idea, though, PC screen readers should stay where the user parked them. VoiceOver on Mac will try to find the nearest focusable item.
I hope I'm understanding what you are saying correctly.
==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions