RE: Error message summaries, alerts and focus

We have previously explored how we can help users avoid errors, but we didn’t want to use client-side validation. It’s a simple sign-in form, so the expected data formats are well established. The input fields conform to 1.3.5 Input Purpose so we can harness browser autofill too.

 

 

From: Nicholas Pappas <nwpappas@gmail.com> 
Sent: Monday, August 7, 2023 4:04 PM
To: Nick Bromley <nick@redkiteda.com>
Cc: w3c-wai-ig@w3.org
Subject: Re: Error message summaries, alerts and focus

 

Rethinking the pattern may be appropriate.

 

The first rethink is around preventing the errors in the first place -- can the inputs be designed in a way that avoids an error to begin with?

 

Presenting errors after a form submit provides the same information in a way that is easier to parse. Making multiple errors and dealing with multiple focus shifts can quickly disorient a user -- even a single one can, given that the user did not expect the focus to shift and now must reorient to what's happening and how to re-enter the read order. By presenting errors after the submission you create two very distinct modes: Completion Mode and Revision Mode. This distinction makes clear the state of the conversation between the user and the system, allowing the user to be more certain of the intended inputs and outputs.

 

--
When you do things right, people won't be sure you've done anything at all.

 

 

On Mon, Aug 7, 2023 at 7:38 AM Nick Bromley <nick@redkiteda.com <mailto:nick@redkiteda.com> > wrote:

When presenting a user with an error message summary outlining, for example, missing data in a form, it’s common for the message text to be injected into a div with role=”alert” so it is announced automatically by screen readers.

 

Gov.uk (among others) recommends you also move keyboard focus to this error message summary <https://design-system.service.gov.uk/components/error-summary/> , because the user can easily tab to the start of the form (assuming the summary appears at the top of the form, that is) and more easily correct errors. However, this then results in screen readers duplicating the announcement: once due to the alert and once due to the shift in focus. In some cases, a screen reader may read the message more than twice.

 

Is this really an appropriate pattern? Can this duplicated announcement be avoided while maintaining the shift in focus?

 

- - -

Nick Bromley

Director & Accessibility Consultant

Red Kite Digital Accessibility Ltd