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.)