E-mail List Archives
Thread: Including non-interactive elements in the tab order
Number of posts in this thread: 9 (In chronological order)
From: Geethavani.Shamanna
Date: Mon, Feb 26 2024 7:42AM
Subject: Including non-interactive elements in the tab order
No previous message | Next message →
Hello all,
I am trying to convince some developers that including non-interactive elements (such as error messages) in the tab order is not best practice. The forms in question are validated in real-time and error messages are dynamically inserted into the tab order if a required field is left blank. The error message appears as the next tab stop following the unpopulated required field.
I came across a discussion in the archives about how including non-interactive elements in the tab order does not fail SC 2.4.3, Focus Order. In this instance, where error messages are included within the tab order, does this not fail SC 2.4.3?
Thank you.
Geetha
From: Patrick H. Lauke
Date: Mon, Feb 26 2024 10:00AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
On 26/02/2024 14:42, Geethavani.Shamanna wrote:
> Hello all,
>
> I am trying to convince some developers that including non-interactive elements (such as error messages) in the tab order is not best practice. The forms in question are validated in real-time and error messages are dynamically inserted into the tab order if a required field is left blank. The error message appears as the next tab stop following the unpopulated required field.
>
> I came across a discussion in the archives about how including non-interactive elements in the tab order does not fail SC 2.4.3, Focus Order. In this instance, where error messages are included within the tab order, does this not fail SC 2.4.3?
Relevant discussions/PRs:
https://github.com/w3c/wcag/issues/1572
https://github.com/w3c/wcag/issues/2655
https://github.com/w3c/wcag/pull/1643
I'd say in this case it's not a failure, but yes not great user experience.
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Mark Magennis
Date: Mon, Feb 26 2024 10:04AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
No this isn't a 2.4.3 failure but why would they want them to be focusable at all? What purpose would that serve? Is it to ensure that they are read when the user tabs through the form? If so, they should be included within the description of the form field that they relate to. Then they will be read when the field receives focus. This also avoids the possibility of any confusion about which field the error relates to, in case it isn't clear from the error message text alone.
Mark
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Geethavani.Shamanna < = EMAIL ADDRESS REMOVED = >
Sent: Monday 26 February 2024 14:42
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] Including non-interactive elements in the tab order
[You don't often get email from = EMAIL ADDRESS REMOVED = . Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hello all,
I am trying to convince some developers that including non-interactive elements (such as error messages) in the tab order is not best practice. The forms in question are validated in real-time and error messages are dynamically inserted into the tab order if a required field is left blank. The error message appears as the next tab stop following the unpopulated required field.
I came across a discussion in the archives about how including non-interactive elements in the tab order does not fail SC 2.4.3, Focus Order. In this instance, where error messages are included within the tab order, does this not fail SC 2.4.3?
Thank you.
Geetha
From: Dean.Vasile
Date: Mon, Feb 26 2024 10:17AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
Including non-interactive elements like error messages in the tab order generally isn't considered a best practice for accessibility. While it might not explicitly fail SC 2.4.3 (Focus Order), it can still pose usability challenges for users navigating the form, especially those who rely on keyboard navigation or assistive technologies.
It's important to ensure that users can navigate through interactive elements in a logical and predictable order. Placing non-interactive elements like error messages within the tab order can disrupt this flow and confuse users. It's usually better to keep error messages separate from the tab order and provide alternative methods for users to locate and address any issues with form validation.
Dean Vasile
617-799-1162
> On Feb 26, 2024, at 9:43 AM, Geethavani.Shamanna < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hello all,
>
> I am trying to convince some developers that including non-interactive elements (such as error messages) in the tab order is not best practice. The forms in question are validated in real-time and error messages are dynamically inserted into the tab order if a required field is left blank. The error message appears as the next tab stop following the unpopulated required field.
>
> I came across a discussion in the archives about how including non-interactive elements in the tab order does not fail SC 2.4.3, Focus Order. In this instance, where error messages are included within the tab order, does this not fail SC 2.4.3?
>
> Thank you.
From: tim.harshbarger
Date: Mon, Feb 26 2024 11:49AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
I think that some times people may misunderstand how screen readers work and they may assume that the screen reader needs to be able to tab to items to read them.
I typically try to explain that most people who rely on the keyboard can see and do not use a screen reader. Also, screen reader users have other mechanisms that allow them to access non-interactive elements.
If they are concerned that screen reader users will miss the inline validation messages, talk them through using something like aria-describedby to associate the error message with the field and use either role="alert" or an assertive live region to ensure the screen reader notifies the user immediately when the error message appears. That will end up being a better user experience for everyone.
Thanks!
Tim
From: Geethavani.Shamanna
Date: Tue, Feb 27 2024 3:21AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
They do use aria-describedby, and have considered using aria-live for dynamic error messages, although that presents its own challenges. Role="alert" is a good option. However, if a screen reader user is merely exploring the form, they will hear the alerts as they tab through each required field.
From: Dean.Vasile
Date: Tue, Feb 27 2024 6:15AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
What you are saying about roll equals alert is true.
I find that on Google forms all the time and it's very frustrating when all I'm trying to do is read through the form and it stops reading with an alert that the field is required. I'm finding that more and more on forms and I do find it very frustrating.
I would like them to find a better way such as alert me when there's an error when I hit the submit button and then take me to that field.
Dean Vasile
617-799-1162
> On Feb 27, 2024, at 5:22 AM, Geethavani.Shamanna < = EMAIL ADDRESS REMOVED = > wrote:
>
> They do use aria-describedby, and have considered using aria-live for dynamic error messages, although that presents its own challenges. Role="alert" is a good option. However, if a screen reader user is merely exploring the form, they will hear the alerts as they tab through each required field.
>
>
From: tim.harshbarger
Date: Tue, Feb 27 2024 10:05AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | Next message →
So I will offer a pro-screen reader tip. If your screen reader provides an application/forms mode and a document/browse mode, you can avoid having the error messages appear if you review the form using the document/browse mode. This is because tabbing through these types of forms in application/forms mode will trigger the events that validate the fields. This won't happen if you tab while in document/browse mode.
I do understand there are definitely many people who find inline validation annoying--whether or not they use a screen reader. However, keep in mind that from an accessibility viewpoint that if messages are popping up as the user tabs through the interface, some kind of approach needs to be used to inform screen reader users when those messages appear.
If the developers involved in the original question believe that they are not allowed to use live regions to inform screen reader users as the messages appear, then making those error messages part of the tab order is likely the only solution they could come up with for making the inline validation accessible.
Thanks!
Tim
From: Dean.Vasile
Date: Tue, Feb 27 2024 11:17AM
Subject: Re: Including non-interactive elements in the tab order
← Previous message | No next message
Tim
Thank you for that tip. I will actually try that out later today.
I never even thought to do that.
Dean Vasile
617-799-1162
> On Feb 27, 2024, at 12:06 PM, = EMAIL ADDRESS REMOVED = wrote:
>
> So I will offer a pro-screen reader tip. If your screen reader provides an application/forms mode and a document/browse mode, you can avoid having the error messages appear if you review the form using the document/browse mode. This is because tabbing through these types of forms in application/forms mode will trigger the events that validate the fields. This won't happen if you tab while in document/browse mode.
>
> I do understand there are definitely many people who find inline validation annoying--whether or not they use a screen reader. However, keep in mind that from an accessibility viewpoint that if messages are popping up as the user tabs through the interface, some kind of approach needs to be used to inform screen reader users when those messages appear.
>
> If the developers involved in the original question believe that they are not allowed to use live regions to inform screen reader users as the messages appear, then making those error messages part of the tab order is likely the only solution they could come up with for making the inline validation accessible.
>
> Thanks!
> Tim
>