E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Nick Bromley
Date: Mon, Aug 07 2023 4:49AM
Subject: Error message summaries, alerts and focus
No previous message | Next message →

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

From: Patrick H. Lauke
Date: Mon, Aug 07 2023 4:58AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

On 07/08/2023 11:49, Nick Bromley wrote:

> Is this really an appropriate pattern? Can this duplicated announcement be
> avoided while maintaining the shift in focus?
I would strongly suggest doing *either* live region announcement, *or*
moving focus...not both.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Jeevan Reddy
Date: Mon, Aug 07 2023 5:48AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

Hi Nick,
Though the error summary announces twice by some screen reader and browser
combinations, but it helps a lot for keyboard users by simply activating
desired error takes to the field to correct it.

Hopes this helps.

Thanks
Jeevan

On Mon, Aug 7, 2023, 4:20 PM Nick Bromley < = EMAIL ADDRESS REMOVED = > 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
>
> > > > >

From: glen walker
Date: Mon, Aug 07 2023 7:39AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

To add on to what Patrick said, in addition to the uk.gov error summary
pattern, if you look at their error message pattern,
https://design-system.service.gov.uk/components/error-message/, and
validation pattern,
https://design-system.service.gov.uk/patterns/validation/, they don't say
anything about announcing the error message when it appears. That is, they
are not recommending the use of aria-live. So gov.uk is not doing both a
live region and moving the focus.

The error summary pattern also recommends putting the summary at the very
top of the page. I'm not sure that's always the best idea. If the main
purpose of your page is a form, then it makes sense. But if you have a lot
of information on your page and a form is only a small part of it, and that
form is further down the page, having the error summary at the top and
seemingly unrelated to the page might be confusing. On the other hand, if
you have some pages that put the summary at the top (in situations where it
makes sense) and other pages that put the summary near the form, then you
have an inconsistent pattern/location and that also might be confusing.

They also recommend pre-pending the page <title> with "error". That's an
interesting idea.

On Mon, Aug 7, 2023 at 4:58 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

>
> I would strongly suggest doing *either* live region announcement, *or*
> moving focus...not both.
>
> P
> --
> Patrick H. Lauke
>
>

From: Nick Bromley
Date: Mon, Aug 07 2023 8:13AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

They don't expressly state in their design system they use aria-live regions, but they do add role=”alert” to their error message parent divs on the site.

Gov.uk usually do extensive user testing of their design patterns so I’d be interested to hear what feedback this produced.



Nick

- - -

Nick Bromley

Director & Accessibility Consultant

Red Kite Digital Accessibility Ltd

-------

To add on to what Patrick said, in addition to the uk.gov error summary

pattern, if you look at their error message pattern,

https://design-system.service.gov.uk/components/error-message/, and

validation pattern,

https://design-system.service.gov.uk/patterns/validation/, they don't say

anything about announcing the error message when it appears. That is, they

are not recommending the use of aria-live. So gov.uk is not doing both a

live region and moving the focus.



The error summary pattern also recommends putting the summary at the very

top of the page. I'm not sure that's always the best idea. If the main

purpose of your page is a form, then it makes sense. But if you have a lot

of information on your page and a form is only a small part of it, and that

form is further down the page, having the error summary at the top and

seemingly unrelated to the page might be confusing. On the other hand, if

you have some pages that put the summary at the top (in situations where it

makes sense) and other pages that put the summary near the form, then you

have an inconsistent pattern/location and that also might be confusing.



They also recommend pre-pending the page <title> with "error". That's an

interesting idea.



On Mon, Aug 7, 2023 at 4:58 AM Patrick H. Lauke < <EMAIL REMOVED> >

wrote:



>

> I would strongly suggest doing *either* live region announcement, *or*

> moving focus...not both.

>

> P

> --

> Patrick H. Lauke

>

>

From: Steve Green
Date: Mon, Aug 07 2023 9:57AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

The GOV.UK Design System philosophy is that JavaScript will not be used unless it is unavoidable (such as in an accordion) or at least improves the user experience.

https://design-system.service.gov.uk/patterns/validation/#client-side-and-server-side-validation says “Only add client side validation if you find a user need for it.”

However, within the gov.uk website you will find all sorts of different coding techniques because the website has been built by many different development teams over many years. You therefore can't use the website as an oracle.

The design pattern at https://design-system.service.gov.uk/components/error-message/ does not use client-side validation and assumes the page will reload after an error.

From a user experience perspective I agree with Patrick's advice to either use a live region or move the focus, but not both, when doing client-side validation. However, are we sure this conforms with WCAG SC 4.1.3? The error message cannot be "programmatically determined through role or properties" in the absence of a live region. Or does SC 4.1.3 not apply since the focus is being moved to the error message?

Steve Green
Managing Director
Test Partners Ltd

From: Patrick H. Lauke
Date: Mon, Aug 07 2023 10:26AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

On 07/08/2023 16:57, Steve Green wrote:
> Or does SC 4.1.3 not apply since the focus is being moved to the error message?

This.

Once you move focus to something, it's not a "status message" in the
SC's sense https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages

--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Nick Bromley
Date: Mon, Aug 07 2023 10:44AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

In the example I'm working with, there's no client-side validation. With server-side validation, would you not also just pick one or other approach? I have thought about not moving focus, but there are a few UI controls that appear before the start of the form so these would need to be manually bypassed each time an error is triggered (it's a relatively simple sign-in form with three input fields).



We have a related issue in that, on MacOS, once we move focus to the error message div, it's bouncing straight off to the first input field in the form, where VoiceOver automatically starts reading its details and autofill options, cutting off the alert almost immediately. I'm not sure if this is some JS timing issue, a Safari quirk, or something else.





---

The GOV.UK Design System philosophy is that JavaScript will not be used unless it is unavoidable (such as in an accordion) or at least improves the user experience.

https://design-system.service.gov.uk/patterns/validation/#client-side-and-server-side-validation says “Only add client side validation if you find a user need for it.”

However, within the gov.uk website you will find all sorts of different coding techniques because the website has been built by many different development teams over many years. You therefore can't use the website as an oracle.

The design pattern at https://design-system.service.gov.uk/components/error-message/ does not use client-side validation and assumes the page will reload after an error.

From a user experience perspective I agree with Patrick's advice to either use a live region or move the focus, but not both, when doing client-side validation. However, are we sure this conforms with WCAG SC 4.1.3? The error message cannot be "programmatically determined through role or properties" in the absence of a live region. Or does SC 4.1.3 not apply since the focus is being moved to the error message?

Steve Green

Managing Director

Test Partners Ltd

From: Steve Green
Date: Mon, Aug 07 2023 11:20AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | Next message →

With server-side validation, the error message is not a status message because it is not a change of content. Or it could be regarded as a change of content that is part of a change of context i.e. the new page loading. Either way, it does not meet the definition of a status message. A live region would therefore not be appropriate.
https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages

I’ve no idea about the macOS issue.

Steve


From: Nick Bromley < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 7, 2023 5:45 PM
To: = EMAIL ADDRESS REMOVED =
Cc: Steve Green < = EMAIL ADDRESS REMOVED = >
Subject: Re: Error message summaries, alerts and focus

In the example I'm working with, there's no client-side validation. With server-side validation, would you not also just pick one or other approach? I have thought about not moving focus, but there are a few UI controls that appear before the start of the form so these would need to be manually bypassed each time an error is triggered (it's a relatively simple sign-in form with three input fields).

We have a related issue in that, on MacOS, once we move focus to the error message div, it's bouncing straight off to the first input field in the form, where VoiceOver automatically starts reading its details and autofill options, cutting off the alert almost immediately. I'm not sure if this is some JS timing issue, a Safari quirk, or something else.


---
The GOV.UK Design System philosophy is that JavaScript will not be used unless it is unavoidable (such as in an accordion) or at least improves the user experience.
https://design-system.service.gov.uk/patterns/validation/#client-side-and-server-side-validation says “Only add client side validation if you find a user need for it.”
However, within the gov.uk website you will find all sorts of different coding techniques because the website has been built by many different development teams over many years. You therefore can't use the website as an oracle.
The design pattern at https://design-system.service.gov.uk/components/error-message/ does not use client-side validation and assumes the page will reload after an error.
From a user experience perspective I agree with Patrick's advice to either use a live region or move the focus, but not both, when doing client-side validation. However, are we sure this conforms with WCAG SC 4.1.3? The error message cannot be "programmatically determined through role or properties" in the absence of a live region. Or does SC 4.1.3 not apply since the focus is being moved to the error message?
Steve Green
Managing Director
Test Partners Ltd

From: Nick Bromley
Date: Tue, Aug 08 2023 2:32AM
Subject: Re: Error message summaries, alerts and focus
← Previous message | No next message

Ah yes, of course.



So I’ll see if just placing focus on the error message on page reload will give a decent experience across our browser-SR test combination



The mac issue needs additional investigation.



Thanks



From: Steve Green < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 7, 2023 6:20 PM
To: Nick Bromley < = EMAIL ADDRESS REMOVED = >; = EMAIL ADDRESS REMOVED =
Subject: RE: Error message summaries, alerts and focus



With server-side validation, the error message is not a status message because it is not a change of content. Or it could be regarded as a change of content that is part of a change of context i.e. the new page loading. Either way, it does not meet the definition of a status message. A live region would therefore not be appropriate.

https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages



I’ve no idea about the macOS issue.



Steve





From: Nick Bromley < <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 7, 2023 5:45 PM
To: <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED =
Cc: Steve Green < <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED = >
Subject: Re: Error message summaries, alerts and focus



In the example I'm working with, there's no client-side validation. With server-side validation, would you not also just pick one or other approach? I have thought about not moving focus, but there are a few UI controls that appear before the start of the form so these would need to be manually bypassed each time an error is triggered (it's a relatively simple sign-in form with three input fields).



We have a related issue in that, on MacOS, once we move focus to the error message div, it's bouncing straight off to the first input field in the form, where VoiceOver automatically starts reading its details and autofill options, cutting off the alert almost immediately. I'm not sure if this is some JS timing issue, a Safari quirk, or something else.





---

The GOV.UK Design System philosophy is that JavaScript will not be used unless it is unavoidable (such as in an accordion) or at least improves the user experience.

https://design-system.service.gov.uk/patterns/validation/#client-side-and-server-side-validation says “Only add client side validation if you find a user need for it.”

However, within the gov.uk website you will find all sorts of different coding techniques because the website has been built by many different development teams over many years. You therefore can't use the website as an oracle.

The design pattern at https://design-system.service.gov.uk/components/error-message/ does not use client-side validation and assumes the page will reload after an error.

From a user experience perspective I agree with Patrick's advice to either use a live region or move the focus, but not both, when doing client-side validation. However, are we sure this conforms with WCAG SC 4.1.3? The error message cannot be "programmatically determined through role or properties" in the absence of a live region. Or does SC 4.1.3 not apply since the focus is being moved to the error message?

Steve Green

Managing Director

Test Partners Ltd