E-mail List Archives
Thread: Visual labels appears in the Dome after the form control
Number of posts in this thread: 3 (In chronological order)
From: Eilana Benish
Date: Sat, Nov 04 2023 12:26PM
Subject: Visual labels appears in the Dome after the form control
No previous message | Next message →
Hello everyone.
I have form that I'm testing.
My problem is that the form controls appear in the dome before the visual
label. When moving with the tab key, everything is fine, but when
navigating with the arrow keys, the screen reader cursor moves first to the
control and then to the visual label. These effects also when browsing the
form on mobile phone with VoiceOver and TalkBack screen readers.
Some of my colleagues saying that this is not a problem if I can navigate
the form with the tab key. But I disagree because when navigating with the
screen reader cursor, a screen reader user can become very confused when
trying to understand the form.
My question is, is this of violation of success criteria 1.3.2 Meaningful
Sequence (Level A)
https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html
What do you think?
Thanks
From: Birkir R. Gunnarsson
Date: Sat, Nov 04 2023 1:22PM
Subject: Re: Visual labels appears in the Dome after the form control
← Previous message | Next message →
Labels of text inputs and <select> dropdowns typically come before the
controls in the DOM order (and are displayed to the left), labels of
checkboxes and radio buttons typically are placed after the control.
This is a best practice, if the labels are connected to the inputs
you'd have a hard time calling it a 1.3.2 fail, though you could call
it as a usability concern.
In case you can't convince the designers to switch up the DOM order, I
have discovered a hack that changes the order for most screen readers.
The hack, use aria-owns on the <label> element with the id of the input.
<input id="foo" type="text">
<label for="foo" aria-owns="foo">First name</label>
This places the label text before the input in most screen readers I
have tested.
I don't condone hacks in general, but sometimes they may be necessary
as a last resort.
On 11/4/23, Eilana Benish < = EMAIL ADDRESS REMOVED = > wrote:
> Hello everyone.
>
> I have form that I'm testing.
>
> My problem is that the form controls appear in the dome before the visual
> label. When moving with the tab key, everything is fine, but when
> navigating with the arrow keys, the screen reader cursor moves first to the
> control and then to the visual label. These effects also when browsing the
> form on mobile phone with VoiceOver and TalkBack screen readers.
>
> Some of my colleagues saying that this is not a problem if I can navigate
> the form with the tab key. But I disagree because when navigating with the
> screen reader cursor, a screen reader user can become very confused when
> trying to understand the form.
>
> My question is, is this of violation of success criteria 1.3.2 Meaningful
> Sequence (Level A)
>
> https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html
>
> What do you think?
>
> Thanks
> > > > >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Sat, Nov 04 2023 1:36PM
Subject: Re: Visual labels appears in the Dome after the formcontrol
← Previous message | No next message
It's not a violation of SC 1.3.2 because the meaning of the content is not affected by the order of the form controls and labels.
As long as the form controls are programmatically associated with the text labels, there is no reason why screen readers cannot announce their name when navigating in browse mode. It's not the website author's fault if the screen reader vendors choose not to make their products do so.
This raises an interesting issue. If the form controls and labels are associated by means of "for" and "id" attributes, the names of the form controls are not announced in browse mode. However, if the form controls get their accessible names from "aria-label" attributes, the names are announced in browse mode.
Would it therefore be considered a "good" or even "best" practice to use both the "for" and "id" attributes (so clicking the label puts the focus in the form control) as well as an "aria-label" attribute that is identical to the visible text? Then the order of the form control and label would not matter.
I know it potentially introduces a maintenance issue if the visible label is changed because the "aria-label" attribute must also be changed, but are there any other reasons for not doing this? And I know it breaks rule 1 of ARIA (don't use ARIA), but it wouldn't be necessary if screen readers behaved better.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, November 4, 2023 7:23 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Visual labels appears in the Dome after the form control
Labels of text inputs and <select> dropdowns typically come before the controls in the DOM order (and are displayed to the left), labels of checkboxes and radio buttons typically are placed after the control.
This is a best practice, if the labels are connected to the inputs you'd have a hard time calling it a 1.3.2 fail, though you could call it as a usability concern.
In case you can't convince the designers to switch up the DOM order, I have discovered a hack that changes the order for most screen readers.
The hack, use aria-owns on the <label> element with the id of the input.
<input id="foo" type="text">
<label for="foo" aria-owns="foo">First name</label>
This places the label text before the input in most screen readers I have tested.
I don't condone hacks in general, but sometimes they may be necessary as a last resort.
On 11/4/23, Eilana Benish < = EMAIL ADDRESS REMOVED = > wrote:
> Hello everyone.
>
> I have form that I'm testing.
>
> My problem is that the form controls appear in the dome before the
> visual label. When moving with the tab key, everything is fine, but
> when navigating with the arrow keys, the screen reader cursor moves
> first to the control and then to the visual label. These effects also
> when browsing the form on mobile phone with VoiceOver and TalkBack screen readers.
>
> Some of my colleagues saying that this is not a problem if I can
> navigate the form with the tab key. But I disagree because when
> navigating with the screen reader cursor, a screen reader user can
> become very confused when trying to understand the form.
>
> My question is, is this of violation of success criteria 1.3.2
> Meaningful Sequence (Level A)
>
> https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html
>
> What do you think?
>
> Thanks
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.