WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus order vs Error message

for

From: glen walker
Date: Oct 22, 2021 1:12PM

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