title-Attribute as name for control element and formfields

[ThomKoeh]

Dear experts,

does a graphical control element violate WCAG, when its only label is a title-Attribute?
does a form element (for example an input field) violate WCAG if its only programatic label is a title-Attribute.
I need a clear statement.

kind regards
Thomas

[patrickhlauke]

yes it violates labels and instructions, as for a keyboard user the title tooltip never shows (assuming you have no other visible label nearby)

[ThomKoeh]

Thanks for your answer. How is it with graphical controls and formfields that have a visible label nearby, which is not associated directly with the field?

[detlevhfischer]

@patrickhlauke wrote:

yes it violates labels and instructions, as for a keyboard user the title tooltip never shows (assuming you have no other visible label nearby)

Maybe one can add that there are graphic controls that are considered (by many) conventional, often aided by its visual layout context, meaning they would not require an additional text label to meet 3.3.2 Labels and instructions (think of loupe placed after a search field, or an down/up arrow icon in a sortable table heading). What in terms of graphic symbols is conventional enough to stand without label has been argued about as long as I can remember, though. If I recall correctly the majority consensus in an issue I opened six years ago ( #867 ), cases where title is the sole provider of the accessible name as in

<button title="search"><img src="loupe.jpg" alt=""></button>

...would be considered sufficient to meet 1.1.1, and due to a graphic's conventional meaning potentially also 3.3.2.

[ThomKoeh]

@detlevhfischer Thanks for your answer and the link to the older issue.

It seems to me that the title-attribute as sole provider of an accessible name or alternative text does not violate the guidelines.
Im ok with that, although the title-attribute is not equally supported by different combinations of browsers and screenreaders.

I would appreciate a clear statement on whether it is accepted or not. It would be very helpful for evaluation and for advising customers.

[patrickhlauke]

the title-attribute is not equally supported by different combinations of browsers and screenreaders

do we have a breakdown/list of where it fails? because per spec, title does indeed count as the fallback accessible name for something labelable if there is nothing else. so those browser/SR combinations would be ignoring/not supporting the spec.

as for the aspect of "but there are cases where just an image is acceptable as label", the thing is there is that visually, even for keyboard users, there IS a visible label. which then makes it fine. the problem is if a form field (e.g. for text entry) only relies on title under the "well, the user will see the tooltip once they hover over it" idea, and then that would fail, in the absence of anything else (like an icon/image) for keyboard users.

How is it with graphical controls and formfields that have a visible label nearby, which is not associated directly with the field?

if there is something that can be considered a label, it does not necessarily need to be programmatically associated with the field, as long as the field's accessible name still contains that visible label in some other way (like aria-label or, indeed, title). so

<label for="foo">First name</label> <input type="text" id="foo" name="foo">

and

<span>First name</span> <input type="text" name="foo" aria-label="First name">

are functionally the same and pass.