WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Visual labels appears in the Dome after the formcontrol

for

From: Steve Green
Date: Nov 4, 2023 1:36PM

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 REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, November 4, 2023 7:23 PM
To: WebAIM Discussion List < <EMAIL 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 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.