RE: 1.4.13 Content on Hover

I was coming here to say exactly what Steve just said :
Description

When a button invokes a function on an input field, has a clear text label, and is rendered adjacent to the input field, the button also acts as a label for the input field. This label helps users understand the purpose of the field without introducing repetitive text on the Web page. Buttons that label single text fields typically follow the input field.

Note: The field must also have a programmatically determined name, per Success Criterion 4.1.2<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#ensure-compat-rsv>.

Effectively it does not need a repetitive visual label but it must serve the screenreader user by other means. And that accessible name could use ARIA to reference the text on the button.


From: Steve Green <steve.green@testpartners.co.uk>
Sent: Thursday, September 14, 2023 2:17 PM
To: Guy Hickling <guy.hickling@gmail.com>; WAI Interest Group discussion list <w3c-wai-ig@w3.org>
Subject: RE: 1.4.13 Content on Hover

CAUTION: This email originated from outside of the organization.

Technique G167 is specifically for meeting SC 3.3.2: Labels or Instructions. It does not claim to be sufficient for any other success criteria. However, it states “The field must also have a programmatically determined name, per Success Criterion 4.1.2”, which addresses your concerns.

Steve

From: Guy Hickling <guy.hickling@gmail.com<mailto:guy.hickling@gmail.com>>
Sent: Thursday, September 14, 2023 2:24 AM
To: WAI Interest Group discussion list <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: RE: 1.4.13 Content on Hover

I do not believe Technique G167 is good for blind people. Firstly, though, if you take SC4.1.2 literally on its own, without the Techniques which are not normative, then an input field must have its OWN programmatically determinable name. Saying a separate  button has a name doesn’t pass 4.1.2. For that reason, if a developer places a text label in front of a field, but does not connect it to the field using the <label> element, then we would all fail it, would we not? So how does placing the text label after the field (whether it is in a button or not) improve things in any way? Just because a button follows a field does not mean they are directly related. Certainly assistive tech such as screen readers don’t make the connection because they don’t announce the “submit” label (of the following button) while on the field, so there clearly is no programmatically determined label for the field. It is also arguable that 3.3.2 is not satisfied, since while the label exists on the screen, it has not been “provided” to screen reader users, not at the time they land on the field.

In fact, we do sometimes see input forms of several fields and, somewhere in the middle of the form, there is a button for some extra purpose or other – but it is not related to whatever happens to be the previous field in the form.

Blind people are the ones most affected by unlabelled fields, as they cannot quickly see what’s going on from the surrounding screen. The example in G167 is excellent for visual displays, but takes no account of the difficulties for blind people. When a blind user tabs onto the field it will be announced as just an unexplained “input” with no label. On hearing that, the first thing a blind user will do will be to backtrack to look for text before the field, assuming it is just one of those many programmatically-unlabelled fields developers leave around. But they won’t find anything. Some users, but not all, may wonder if there is something after the unknown field – but we can see they have already wasted time looking before the field first. There is a reason why SC4.1.2 was created.

The only reason people are happy with the idea of an unlabelled input field in this Search scenario is due to Technique G167. I think that is just as unhelpful as already said of the Example 3 in H65. (Basically, they agreed a perfectly good normative SC, then tried to change the meaning of it in the supporting technique documents!) G167 should never, to my mind, have been created. Fortunately, in practice, wherever I find websites where the developers have made a serious attempt at accessibility (particularly in public sector websites for instance), I usually find that the developer has either added a <label> hidden for screenreaders, or added an aria-label. So, it seems not many are actually following G167 in practice. And I don’t think it should be encouraged.

(In all of this, of course, Search fields are slightly different from the norm, in that they generally occur in page headers, and users get used to there being a button following; it’s a common pattern. So they may look beyond the field more readily in the page header. But that is evading the general issue – the principle for all input fields should surely be that unlabelled fields should not be allowed in any circumstance.)



Kevin Prince

Product Accessibility & Usability Consultant



E kevin.prince@fostermoore.com

Christchurch

fostermoore.com

This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.