WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Placeholder and Accessible Name Computation

for

From: Mallory
Date: May 9, 2019 4:06AM

I have seen pages suggesting that single-input search fields with the submits labelled "search" are practically (but not technically) labelled by the submits. Sometimes the control you click to reveal the field is the submit button.
I dislike the pattern for other reasons, but that argument generally about one input + submit does stick in my head.

I have seen these which are verbosity-overloads:
```<form... role="search">
<fieldset>
<legend>Search</legend> (visually hidden)
<label for="searchID">Search</label> (hidden visually)
<input type="search" id="searchID" placeholder="find your [x] on [website.com]" title="find your [x] on [website.com]">
<button aria-label="Submit search">[picture of a circle with a tail]</button>
</fieldset>
</form>```

The mismatch with the placeholders/titles is really common for some reason.

_mallory


On Thu, May 9, 2019, at 7:34 AM, Detlev Fischer wrote:
> Tangential to this discussion is the case, which I see more often, of
> the search field made visible once a search button has been activated,
> a field which has no further label and may not be anywhere near the
> search button, and which may have a placeholder (more Ofen just a text
> cursor). You could argue that since it is only brought about after the
> user action and intent of searching, it wouldn't require a label as
> much as other fields. But I just throw this in to contemplate.
>
> Sent from phone
>
> > Am 09.05.2019 um 05:08 schrieb Birkir R. Gunnarsson < <EMAIL REMOVED> >:
> >
> > That discussion doesn't make sense to me. They even talk about what
> > hapens if an element has title, placeholder and a non-empty value
> > attribute. I thought an input could never have both a visible
> > placeholder and a value and the placeholder attribute should not be
> > exposed by a screen reader as the input's accessible name when it is
> > not visible.
> > For one thing it creates a major inconsisency between the visible and
> > screen reader experience, for another, the recommended use of the
> > placeholder attribute makes it unsuitable for the element's accessible
> > name, for a third, an input with placeholder only text fails WCAG
> > 3.3.2 (visible label) except in the rare cases where the field is
> > sufficiently labeled visually by an adjacent control (e.g. a search
> > input labeled by a search button).
> > I just don't like where this discussion is going, oh no precious, not
> > at all, Gollum.
> >
> >
> >> On 5/8/19, glen walker < <EMAIL REMOVED> > wrote:
> >> That sentence in step D has always bothered me.
> >>
> >> "Otherwise, if the current node's native markup provides an attribute (e.g.
> >> title)"
> >>
> >> Why is the TITLE attribute given as an example in step D as a text
> >> alternative? If you continue through the calculation to step I (eye), you
> >> finally get to the lonely tooltip attribute, which is also the TITLE
> >> attribute. So it's a bit confusing on when the TITLE attribute should be
> >> used. Step D or step I?
> >> > >> > >> > >> > >>
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > > > >
> > > > >