Should title really be preferred over placeholder for the name? #168
Description
I question why the title attribute is being preferred over the placeholder.
The scenario at hand is that we have an input which has no label element, and no aria-label value, and no aria-labelledby attribute and we have a title attribute and a placeholder attribute.
The placeholder value is likely to be shorter and what sighted user sees and uses to know what belongs in the input. That strikes me as a more name-like source.
The title value is not automatically going to be seen, unless the user hovers the mouse over the field. That strikes me as more secondary-level, non-essential information. There is also a chance that the title will be more wordy, which strikes me as a description; not a name.
Currently the title is a source for the accessible description. So if the placeholder is preferred over the title, and both attributes are present, the AT user who is blind will get a similar experience to that of the sighted user: Namely he/she will see the placeholder first, and that might be all that is needed to know what is expected in the field. But if more information is needed, it can be obtained through the screen reader either on demand, or after hearing the name, depending on their screen reader settings.
Note that we had some discussion about this during today's ARIA concall because we want AccName to be in sync with HTML-AAM and vice versa. The conclusion from our meeting is that I would open an issue for this discussion here (done). We do not yet have ARIA WG consensus on whether or not placeholder or title should be preferred. In other words, the question I raise is mine as an individual and NOT as the co-chair of the ARIA WG. :)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
jnurthen commentedon Feb 22, 2019
My opinion is that
titleshould win overplaceholderfor backwards compatibility. There are plenty of sites which use both and currently get their accessible name fromtitle. Placingplaceholderabovetitlein the algorithm would break all of these sites.scottaohara commentedon Feb 22, 2019
Hi @joanmarie. Here are my thoughts on this:
As there were previous efforts to remove placeholder in the accessible name computation, which implementors did not fully embrace, it seems counter to reintroduce
placeholderin a higher placement in the algorithm than as a last resort.While the input remained empty, a
placeholderwould provide a visible label (potentially poor color contrast aside), that would only be consistently exposed to all prior to user entry. Thetitle, though only available on hover (or focus with Internet Explorer and Edge), would remain consistently available to the subset of people whom can access it via said manners.Additionally, there is precedent in author guidance to use the
titleattribute as a means to provide an accessible name when a visiblelabelcannot be used. e.g. WCAG technique H65.Here's where @jnurthen's point comes in, as in situations where such guidance was followed, while also using a
placeholderto appropriately provide a hint of expected entry, we'd get a less than ideal accessible name weretitleto come first. For example:Lastly, Mozilla made their intent clear in the bug they just worked on regarding this issue. Per Marco's comment:
I hope this helps to clarify the ordering. More than happy to continue talking this out though :)
joanmarie commentedon Feb 22, 2019
Ok, if everyone else thinks it's a better idea, I suppose I can live with it.
Thanks for the explanation!