WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus order vs Error message

for

From: Jonathan Cohn
Date: Oct 23, 2021 2:58PM

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 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
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
> Sent: Saturday, October 23, 2021 11:42 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Focus order vs Error 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.
> > > >
> > > >