WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus order vs Error message

for

From: allyssa jessicon
Date: Oct 23, 2021 1:33AM

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