Re: Error message summaries, alerts and focus

If the errors are appearing after a page reload it is not required that you
move the focus immediately to them. They should be a part of the new
reading order.

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


On Tue, Aug 8, 2023 at 1:41 AM Nick Bromley <nick@redkiteda.com> wrote:

> Thanks for your comments, Marc and Michael.
>
>
>
> The form is validated server-side, so error messages are displayed
> following page reload, and the form itself is a simple three-field sign in
> form, so moving focus I feel would not be too jarring.
>
>
>
>
>
> (Incidentally, I erroneously cross-posted this on WebAIM mailing list –
> nearly everyone has said pick one or the other approach, but not both).
>
>
>
> *From:* Marc Haunschild (Accessibility Consulting)
> <marc.haunschild@accessibility.consulting>
> *Sent:* Tuesday, August 8, 2023 6:16 AM
> *To:* Michael Livesey <mike.j.livesey@gmail.com>
> *Cc:* Nick Bromley <nick@redkiteda.com>; w3c-wai-ig@w3.org
> *Subject:* Re: Error message summaries, alerts and focus
>
>
>
> Hi Nick,
>
> As Mike already said: moving the focus can be a problem. If it’s something
> the user would expect, this might be okay. But that differs from user to
> user what they expect.
>
>
>
> Of course this should never happen while working on the form.
>
>
>
> Else it might fail focus oder and/ or meaningful sequence.
>
>
>
> --
>
> Mit freundlichen Grüßen
>
>
>
> Marc Haunschild
>
> https://Accessibility.Consulting
>
>
>
> Am 07.08.2023 um 20:15 schrieb Michael Livesey <mike.j.livesey@gmail.com>:
>
> 
>
> Hi Nick,
>
>
>
> This is an interesting issue and one we have also wrestled with. In my
> opinion role="alert" and switching focus to a div which behaves like an
> alert are mutually incompatible.
>
>
>
> Personally, I do not agree with the recommendation to move focus to an
> alert. For example, let's say there is a form, a person is entering text
> into a textarea or wysiwgy type field. Moving focus will fire the onChange
> event, this is, in my opinion, not desirable. Also, consider a form with
> hundreds of fields, shifting focus to an alert at the start of the form
> would be very disorientating.
>
>
>
> If you absolutely have to shift focus, I would suggest that role="alert"
> is not used. If anyone knows how to suppress the screen reader announcement
> in these situations I would be interested.
>
>
>
> On Mon, Aug 7, 2023 at 3:38 PM 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
>
>
>
>