Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understanding Label in Name #352

Open
michael-n-cooper opened this issue Jun 12, 2018 · 27 comments
Open

Understanding Label in Name #352

michael-n-cooper opened this issue Jun 12, 2018 · 27 comments

Comments

@michael-n-cooper
Copy link
Member

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

From @awkawk on March 2, 2018 15:22

The 2.4.12 Label in Name (A) SC has draft Understanding content that can be viewed at Understanding Label in Name.

Please review the Understanding document and submit a comment on this issue for any changes that are needed to the content.

Copied from original issue: w3c/wcag21#788

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

  1. 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.
@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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">

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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?

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.
@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

From @mbgower on April 17, 2018 5:3

Thanks @jake-abma

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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

placeholder

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.

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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,
@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Jun 12, 2018

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>

@alastc

This comment has been minimized.

Copy link
Contributor

@alastc alastc commented Jan 2, 2019

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

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented Jan 2, 2019

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?

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Jan 2, 2019

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?

@detlevhfischer

This comment has been minimized.

Copy link
Contributor

@detlevhfischer detlevhfischer commented Jan 2, 2019

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Jan 2, 2019

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.

@detlevhfischer

This comment has been minimized.

Copy link
Contributor

@detlevhfischer detlevhfischer commented Jan 3, 2019

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Jan 3, 2019

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

@detlevhfischer

This comment has been minimized.

Copy link
Contributor

@detlevhfischer detlevhfischer commented Jan 3, 2019

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Jan 3, 2019

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

@alastc

This comment has been minimized.

Copy link
Contributor

@alastc alastc commented Jan 8, 2019

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>

@mbgower

This comment has been minimized.

Copy link
Contributor

@mbgower mbgower commented Apr 12, 2019

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!!

@michael-n-cooper

This comment has been minimized.

Copy link
Member Author

@michael-n-cooper michael-n-cooper commented Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.