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> 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
>
>
>