From @devarshipant on March 19, 2018 19:30

Hi,

Some observations:

1. There are instances where a label is (or provides) an accessible name, E.g.

<label for="something">First Name</label>
<input type="text" id="something">

Here, First Name is a visible label and also the name. I think the Understanding section needs to mention that visible text label is the accessible name in many cases. And there are instances where visible text 'Matches' the accessible name.

2. The Failure (Accessible Name does not contain the visible label text) may not be one when text controls do not have a visible label. For example, a placeholder attribute (or an equivalent attribute like title) and aria-label could satisfy visible and programmatic aspects. E.g., Search textbox, Username, Password, Combobox Filters, Controls in Data tables.

From @mbgower on April 11, 2018 21:34

The Failure (Accessible Name does not contain the visible label text) may not be one when text controls do not have a visible label. For example, a placeholder attribute (or an equivalent attribute like title)

I wanted to clarify that placeholder text is not considered a replacement for a label in the HTML5.2 specification

The placeholder attribute should not be used as an alternative to a label.

or in aria:

Authors SHOULD NOT use aria-placeholder instead of a label as their purposes are different: The label indicates what kind of information is expected. The placeholder text is a hint about the expected value. See related aria-labelledby and aria-label.

Use of the TITLE attribute or accessible hover text for a label is allowed (but discouraged) in WCAG, and its value is taken into account in the accessible name specification. It does not stand as an example of a non-visible label, since it is visible (and so could potentially be found and announced by someone using speech recognition) , just not persistent.

and aria-label could satisfy visible and programmatic aspects ( E.g., Search textbox...

If a "search" button appeared after an input with no label, then I agree that aria-label="search" is a possible solution; however, the chances for the engine getting confused between whether the user wants to activate the search button or reposition to the search input field seems heightened (depending on how the user references the control with different speech affordances such as "move to" or "select").

So my take would be that issues with missing labels (or sub-par workarounds) will likely fail existing WCAG 2.0 requirements -- and so need to be rectified, regardless of the new Label in Name SC.

From @mraccess77 on April 11, 2018 23:44

In my opinion a title attribute could not be used as the sole source of a visible label under SC 3.3.2 because most user agent implementations don't expose it on keyboard focus. I would imagine that finding a title attribute for speech input user would be difficult and it would not be visible on mobile. Title attributes could be used to meet SC 1.3.1 or 4.1.2 if the provide they same meaning as what is covered with presentation.

From @mbgower on April 12, 2018 14:43

@mraccess77 yes, especially given that many speech users have mobility issues (i.e., are using the speech control to compensate for an inability to use a pointer and/or keyboard), title with only user agent behaviour seems like a sub-par solution. I just wanted to flag that I think TITLE is part of the accessible name formula, and so enters into the discussion for meeting this SC.

From @devarshipant on April 13, 2018 15:23

I wanted to clarify that placeholder text is not considered a replacement for a label in the HTML5.2 specification.

You are correct--spec does say so. Correct me if I am mistaken here--the value of placeholder attribute becomes the accessible name if no other primary accessibility attribute exists (label, aria-label etc.). In that case, and functionally too, placeholder is no different than the title.

So my take would be that issues with missing labels (or sub-par workarounds) will likely fail existing WCAG 2.0 requirements -- and so need to be rectified, regardless of the new Label in Name SC.

The approach could be sub-par if the end user expierence is not great. There could be instances where the placeholder by itself gives the meaning of the control, not merely the hint. It is unorthodox, but does the following fail WCAG 2.1?
<input type = "text" placeholder = "enter social, xxx-xx-xxxx">

From @awkawk on April 13, 2018 15:30

It is unorthodox, but does the following fail WCAG 2.1?
<input type = "text" placeholder = "enter social, xxx-xx-xxxx">

If someone found that the placeholder text was exposed by the accessibility API even after text was entered into the control it might be regarded as passing 4.1.2, but as soon as someone filled it in there would be no label available so unless there was a redundant text label it would fail 2.4.6 in WCAG 2.0. This is not encouraged, obviously.

From @mraccess77 on April 13, 2018 15:36

In my opinion placeholder text is fallback content just like the src attribute might be on an image without alt and therefore fallback content should not be considered as part of the accessible name. I would fail this for both visual labels and programmatic labels because the visual label goes away when the field has data.

From @mbgower on April 13, 2018 16:1

Correct me if I am mistaken here--the value of placeholder attribute becomes the accessible name if no other primary accessibility attribute exists

There are no occurrences of placeholder in the Accessible Name and Description Computation's latest editors' draft; there are many references to title. So on top of both the warnings about its usage cited earlier, and observations about its visual disappearance -- either of which I think is reason to not consider it as an acceptable solution for this SC -- I don't think it is technically correct to say it would be considered part of the accessible name. @michael-n-cooper, perhaps an explicit note about it might be considered for the next editor's draft of the Computation?

From @devarshipant on April 13, 2018 17:0

There are no occurrences of placeholder in the Accessible Name and Description Computation's latest editors' draft; there are many references to title. So on top of both the warnings about its usage cited earlier, and observations about its visual disappearance -- either of which I think is reason to not consider it as an acceptable solution for this SC -- I don't think it is technically correct to say it would be considered part of the accessible name?

Agreed. Sorry, but I am only questioning -- why does title attribute get preferential treatment over placeholder? Title attribute disappears too. And it's implementation is widely misunderstood w.r.t how screen readers process it.

This is how I arrived at this conclusion where placeholder gets calculated as the acc name. It checks out with JAWS and NVDA, but I don't know if vendors are reading the Acc Name algorithm to calculate placeholder. Or reading it at all.

HTML 5 says "User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control)."

Hint = "value of placeholder"

Tie that in with the following Acc Name Cal:

G. Otherwise, if the current node is a Text node, return its textual contents. [1]

Text Node = "value of placeholder on the input element"

To my mind the hint that user agents give (which is the value of the placeholder) is the innertext being computed in G.

1. Text Node: Type of DOM node that represents the textual content of an attribute or an element. A Text node has no child nodes.

From @mbgower on April 13, 2018 23:15

why does title attribute get preferential treatment over placeholder? Title attribute disappears too.

Title is not considered a great implementation; I can't find it right now but there's a note somewhere cautioning against its use. That said, the way user agents display the value of the title attribute is not visibly persistent but it is visibly consistent: hovering your mouse over the item will always redisplay the value. In the case of placeholder, once the input field has any value populated, the ability to view the value of placeholder is lost.

From @jake-abma on April 16, 2018 17:4

@mbgower got some for you:

https://www.w3.org/WAI/tutorials/forms/labels/#using-the-title-attribute

https://html.spec.whatwg.org/#the-title-attribute

http://www.html5accessibility.com/tests/title-usage.html

http://w3c.github.io/html/dom.html#the-title-attribute

https://developer.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/

From @mbgower on April 17, 2018 5:3

Thanks @jake-abma

From @devarshipant on April 17, 2018 13:58

That said, the way user agents display the value of the title attribute is not visibly persistent but it is visibly consistent: hovering your mouse over the item will always redisplay the value.

Great points. However, the number of controls and meaningful context around the controls makes a difference when recommending title or placeholder.

Here is a mock up showing Log in page using placeholder text.

1. Would it pass if only title attributes were used?

2. Would it pass using placeholder (sufficient context is provided)?

In the case of placeholder, once the input field has any value populated, the ability to view the value of placeholder is lost.

It can be viewed on pressing the escape key. But you are correct, it is not as helpful as title.

From @lseeman on April 22, 2018 16:55

Can we add that

1. having the visible labels provides support for people with learning and cognitive disabilities?
2. using the most common terms in the label helps people with a limited vocabulary understand the label,

From @ITakora on May 1, 2018 16:4

Can you please tell me if this would be a good or bad practice for this criterium?
<button aria-label=”Close”> X </button>

The button X question was also asked here: https://twitter.com/stevefaulkner/status/1080436758679035904

Looks like the understanding document doesn't answer this question. (https://www.w3.org/TR/WCAG21/#label-in-name).

It hinges on whether the "X" is regarded as text. Text is defined as "sequence of characters that can be programmatically determined, where the sequence is expressing something in human language".

Is the "X" expressing something in human language, or is it just a symbol?

as mentioned on twitter (https://twitter.com/patrick_h_lauke/status/1080442831179796480), i'd go even further and ask about punctuation, brackets, etc. i.e. would <button aria-label="Close">[Close]</button> or <button aria-label="More">More ...</button> fail?

Why should it fail if aural output is without punctuation?

Because aural output has nothing to do with whether or not the visible text (or image of text) is present in the accessible name or not, which is the nominal criterion to decide whether this would pass or fail?

Practically, it depends here if we expect voice users to speak the punctuation (i.e. if a user said "open square bracket close close square bracket" or similar, which likely wouldn't trigger the button if its accessible name set by aria-label is just "close"), or not. But just going by the letter of the SC, the examples would possibly fail because the visible string (if we count the punctuation etc. marks as also being part of the string) is not present in the actual accessible name.

Granted, but in the cases quoted, my understanding was that regarding the acccessible name, the visible label (with punctuation) would be replaced by the content of the aria-label attribute, which is without.

and that's the point: is this a failure? According to the letter of the SC, yes (as the accessible name now doesn't match the visible text - if by text we also mean the punctuation). But in practical terms, I would argue that no, it's not (as voice users would likely not say the punctuation out loud, so it would make no difference in real-world usage).

as an aside: Eric Wright did some testing for the "X" close https://twitter.com/ewaccess/status/1080626915160002560 ... it seems that, at least in Dragon 15, both "click close" and "click X" work at least

On the punctuation / spacing aspect, should this example fail?

<a href="tel:08005551000" aria-label="0 8 0 0. 5 5 5. 1 0 0 0">0800 555 1000</a>

Hi Gang, I just reviewed this discussion and I'm happy to say that the most recent version of the Understanding document (adopted by the WB) addresses all these points and also they are re-addressed in some techniques. A summary of where I ended up in the rewrite:

Placeholders

Placeholders are included in the accessible name calculation. They are also a likely candidate to be used as a string by a speech-input user in the event there is no other candidate label. I have included language to this effect in the Understanding doc, with lots of cautionary language around it.

Title

Title is also in the accessible name calculation. The Understanding doc does not specify that a title value serves as a visible label, but it does indicate that using title to programmatically provide a name (or reinforce a label) is acceptable.

Punctuation and symbols

Both tackled. The X close button example is covered by this. In that scenario, the X is not a word but a symbol. We don't treat it as meaningful text, and thus providing an aria-label of "close" is fine and not a failure of Label in Name.
Punctuation is also not regarded as meaningful in the context of a label for speech input users since such users would not normally include punctuation when invoking a command. So it is not considered a failure if a name matches the label but leaves out the punctuation.

@michael-n-cooper I just had a glance at the current version of the Understanding doc, and although it looks like all the main content is there, all the subheadings have been stripped out of the Intent section. Is that a glitch? I wanted to direct folks over to the updated version, but without those subheadings, it's a tougher slog!!

This issue looks to be inactive, so I'm closing it. Please re-open if necessary.