E-mail List Archives

Search E-mail List Archives for

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

From: allyssa jessicon
Date: Fri, Oct 22 2021 9:40AM
Subject: Focus order vs Error message
No previous message | Next message →

Hi there,

I am having a situation where there is a small form which includes a radio
button to either Accept or Rejecte the Terms of Use and enter a Password in
the password edit field to submit a form. The form gives an error message
if user makes no selection and or provide invalid input, for i.e. wrong
password and the Error or the message will be displayed in a Window.

I am so confused in understanding where the focus should reach back to if
user makes no selection for both the Radio button and Password edit filed
and submit form. Please note that Submitting the form will open a window
where user has 2 options either close it or click OK button. I think the
focus should go back to the triggering elements because the user is not
interacting with the form fields and instead submitting the form directly.

I am okay to set the focus on any of the form field where user has missed
or entered invalid data, but please bear in mind that in this particular
scenario user is not making any selection in the form fields.

I would really like to know your thoughts on this against WCAG
violation/best practices.

Looking forward your valuable responses.


Thanks,
Alyssa.

From: glen walker
Date: Fri, Oct 22 2021 1:12PM
Subject: Re: Focus order vs Error message
← Previous message | Next message →

This is more of a UX question than a WCAG question, assuming you are
handling the error properly (3.3.1) and are handling the modal error dialog
properly (1.3.1, 1.3.2, 2.4.3, 2.4.6, and potentially others). You could
maybe use 2.4.3 for the focus issue but 2.4.3 just says the focus has to
make sense and not affect the usability. It doesn't dictate where the
focus should go.

One thing I noticed from a UX perspective is the use of a radio button to
accept the terms of use. That widget is usually a checkbox that is
unchecked by default. With a radio button, usually something is selected
by default, although browsers let you have nothing selected. If nothing is
selected, the problem is that once you choose a radio button, there's no
way to go back to the unselected state so it's a little frustrating for the
user. And the tab order for unselected radio buttons is a little wonky on
some browsers. Firefox lets you TAB to each radio button individually
until one is selected, and then you can only TAB to the radio group as a
whole - not each radio button individually. Chrome will TAB to the radio
group as a whole but puts the focus on either the first or last radio
button, depending on which direction you're tabbing. Once you select a
radio button, then TAB will go to the selected button. I'm not sure what
Safari on the Mac does. That's kind of a tangential topic and doesn't
really affect your focus question.

I also wasn't clear what happens with the error modal. You said the user
can either close it or click OK. What's the difference? Are you saying
there are multiple ways to close it? The user can press ESC or click OK or
[something else]? The error modal just lists the errors that occured but
doesn't have any interactive elements (except an OK button)? And what does
OK mean with an error dialog? Does it mean the user is ok with the
errors? Does it mean, "ok, I made a mistake and I'll go back and fix it"?
Again, these are just UX issues that are unrelated to your focus question.

My general rule of thumb is to not move the focus when possible. If a
dialog pops up, then you need to move the focus into the dialog. When the
dialog disappears, I like to keep the focus on the thing that caused the
dialog to appear. Sometimes that "thing" is no longer there so you have to
choose a different focus location but it sounds like in your case, the
submit button is still there. That's where I'd put the focus when the
dialog closes.


On Fri, Oct 22, 2021 at 9:40 AM allyssa jessicon < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi there,
>
> I am having a situation where there is a small form which includes a radio
> button to either Accept or Rejecte the Terms of Use and enter a Password in
> the password edit field to submit a form. The form gives an error message
> if user makes no selection and or provide invalid input, for i.e. wrong
> password and the Error or the message will be displayed in a Window.
>
> I am so confused in understanding where the focus should reach back to if
> user makes no selection for both the Radio button and Password edit filed
> and submit form. Please note that Submitting the form will open a window
> where user has 2 options either close it or click OK button. I think the
> focus should go back to the triggering elements because the user is not
> interacting with the form fields and instead submitting the form directly.
>
> I am okay to set the focus on any of the form field where user has missed
> or entered invalid data, but please bear in mind that in this particular
> scenario user is not making any selection in the form fields.
>
> I would really like to know your thoughts on this against WCAG
> violation/best practices.
>
> Looking forward your valuable responses.
>
>
> Thanks,
> Alyssa.
> > > > >

From: allyssa jessicon
Date: Sat, Oct 23 2021 1:33AM
Subject: Re: Focus order vs Error message
← Previous message | Next message →

Hello Glen,

Thank you for your valuable response. Just for your better understanding
the Modal contains an error message which explains what the user needs to
do before activating it, such as "Please make a selection in the radio
buttons to submit the form". As you said you will keep the focus on the
control which caused the Dialog to appear and would you stick to the same
if there is an Error validation happens in the form fields? Such as An
inline error additionally displays next to the Radio buttons after pressing
Submit button. Please note that the Dialog still opens and user can close
it and focus goes to the control which caused the error to appear, in this
case that would be Submit button but at the same time there's also an
inline Error validation appear next to the form field. What would you be
recommending for the focus to shift? I would agree on setting focus to
where the inline Error validation has taken place. Would you agree the same?

On Saturday, October 23, 2021, glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> This is more of a UX question than a WCAG question, assuming you are
> handling the error properly (3.3.1) and are handling the modal error dialog
> properly (1.3.1, 1.3.2, 2.4.3, 2.4.6, and potentially others). You could
> maybe use 2.4.3 for the focus issue but 2.4.3 just says the focus has to
> make sense and not affect the usability. It doesn't dictate where the
> focus should go.
>
> One thing I noticed from a UX perspective is the use of a radio button to
> accept the terms of use. That widget is usually a checkbox that is
> unchecked by default. With a radio button, usually something is selected
> by default, although browsers let you have nothing selected. If nothing is
> selected, the problem is that once you choose a radio button, there's no
> way to go back to the unselected state so it's a little frustrating for the
> user. And the tab order for unselected radio buttons is a little wonky on
> some browsers. Firefox lets you TAB to each radio button individually
> until one is selected, and then you can only TAB to the radio group as a
> whole - not each radio button individually. Chrome will TAB to the radio
> group as a whole but puts the focus on either the first or last radio
> button, depending on which direction you're tabbing. Once you select a
> radio button, then TAB will go to the selected button. I'm not sure what
> Safari on the Mac does. That's kind of a tangential topic and doesn't
> really affect your focus question.
>
> I also wasn't clear what happens with the error modal. You said the user
> can either close it or click OK. What's the difference? Are you saying
> there are multiple ways to close it? The user can press ESC or click OK or
> [something else]? The error modal just lists the errors that occured but
> doesn't have any interactive elements (except an OK button)? And what does
> OK mean with an error dialog? Does it mean the user is ok with the
> errors? Does it mean, "ok, I made a mistake and I'll go back and fix it"?
> Again, these are just UX issues that are unrelated to your focus question.
>
> My general rule of thumb is to not move the focus when possible. If a
> dialog pops up, then you need to move the focus into the dialog. When the
> dialog disappears, I like to keep the focus on the thing that caused the
> dialog to appear. Sometimes that "thing" is no longer there so you have to
> choose a different focus location but it sounds like in your case, the
> submit button is still there. That's where I'd put the focus when the
> dialog closes.
>
>
> On Fri, Oct 22, 2021 at 9:40 AM allyssa jessicon <
> = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi there,
> >
> > I am having a situation where there is a small form which includes a
> radio
> > button to either Accept or Rejecte the Terms of Use and enter a Password
> in
> > the password edit field to submit a form. The form gives an error message
> > if user makes no selection and or provide invalid input, for i.e. wrong
> > password and the Error or the message will be displayed in a Window.
> >
> > I am so confused in understanding where the focus should reach back to if
> > user makes no selection for both the Radio button and Password edit filed
> > and submit form. Please note that Submitting the form will open a window
> > where user has 2 options either close it or click OK button. I think the
> > focus should go back to the triggering elements because the user is not
> > interacting with the form fields and instead submitting the form
> directly.
> >
> > I am okay to set the focus on any of the form field where user has missed
> > or entered invalid data, but please bear in mind that in this particular
> > scenario user is not making any selection in the form fields.
> >
> > I would really like to know your thoughts on this against WCAG
> > violation/best practices.
> >
> > Looking forward your valuable responses.
> >
> >
> > Thanks,
> > Alyssa.
> > > > > > > > > >
> > > > >

From: glen walker
Date: Sat, Oct 23 2021 9:41AM
Subject: Re: Focus order vs Error message
← Previous message | Next message →

Some of your questions are spurred by the UX that was chosen. When I code
a form, I generally don't display error messages in a separate dialog. I
display them on the page in two places. First, as close to the form
element that is in error as possible and second, as a list of errors at the
top of the form. I like for the list to have links to each form element
that is in error to make it easier to navigate to the error.

Also, the error(s) need to be announced when displayed, typically with
aria-live, and each error needs to be associated with its respective form
element, typically with aria-describedby.

When the form is submitted and the errors are displayed, I often move the
focus to the first element that is in error rather than leaving the focus
on the submit button. Other options would be to move the focus to the list
of errors displayed before the form, or to leave the focus on the submit
button. Those are all UX decisions and any of them would be great for
accessibility.

From: jeffgutsell
Date: Sat, Oct 23 2021 2:20PM
Subject: Re: Focus order vs Error message
← Previous message | Next message →

Would you ever use the Output element as the container for error messages? I have experimented with the 3 main Windows browsers and Safari on iOS. They all seem to use this as a live region.

Jeff Gutsell

From: Jonathan Cohn
Date: Sat, Oct 23 2021 2:58PM
Subject: Re: Focus order vs Error message
← Previous message | Next message →

Well, I can't answer your first question, but the output element does have a default role of "status" which means it will be a live region with value of value of polite and an implicit .
For divs with role = status the ARIA documentation recommends using a aria-controls be set to make an explicit connection. The output element does automatically create a relationship with a form, but I expect a more explicit relationship with a input element would be required.
https://w3c.github.io/aria/#status
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/output


Jonathan
Best wishes,

Jonathan Cohn



> On Oct 23, 2021, at 16:20, = EMAIL ADDRESS REMOVED = wrote:
>
> Would you ever use the Output element as the container for error messages? I have experimented with the 3 main Windows browsers and Safari on iOS. They all seem to use this as a live region.
>
> Jeff Gutsell
>
>
>

From: glen walker
Date: Sat, Oct 23 2021 2:59PM
Subject: Re: Focus order vs Error message
← Previous message | No next message

That's why I love this distribution list - I'm always learning something
new. Honestly, I had never heard of the output element. I suppose it
makes sense since there's an input element. Looks like an output element
has a default role of "status", and "status" has an implicit
aria-live="polite" and aria-atomic="true". So, yes, an output element is a
live region. Having an output element is probably more semantic than a div
with aria-live but I'm not sure any screen readers say anything different
for an output element. I guess the only advantage is that you don't have
to type aria-live and aria-atomic.

On Sat, Oct 23, 2021 at 2:20 PM < = EMAIL ADDRESS REMOVED = > wrote:

> Would you ever use the Output element as the container for error messages?
> I have experimented with the 3 main Windows browsers and Safari on iOS.
> They all seem to use this as a live region.
>
> Jeff Gutsell
>
>