2.5.3 Label in Name - aria-hidden on part of visual label

[joe-watkins]

Hello :)

I'd love to get a take from the working group on if folks feel this scenario is a failure of 2.5.3 Label in Name. It's a real head-scratcher. Does it pass the test steps found in F96?

The intent within the code is to try to avoid the double announcement of 'required' with a screen reader by hiding that in the visual label with aria-hidden and instead relying on that from the required attribute.

I've noticed that with some voice recognition software (iOS Voice Access & macOS Voice Control) if one says "Tap, First name required" it doesn't work as expected and fallbacks must be used. So the screen reader win may impact some voice recognition a bit.

<label for="first-name">
    First Name <span aria-hidden="true">(required)</span>
</label>
<input type="text" id="first-name" required>

Please excuse best practice / usability - strictly WCAG failure consideration here.

[mbgower]

IMO that is a technical failure of the test.

I also find it frustrating that the required attribute on the input causes redundancy with the label. I don't think it's technically a failure to not have the required attribute, so taking out the attribute and your aria-hidden is probably the simplest thing to do and not fail WCAG.

<label for="first-name">
    First Name (required)
</label>
<input type="text" id="first-name" >

I can't think of any negative to this (but I'm sure someone will contradict that!). The label is properly associated with the input and contains the word "required". So it is part of its accessible name and will be exposed.

My sense is that the required attributed is great for increasing accessibility where text at the top of the page might say "All fields are required except those marked as 'not required'." If a screen reader user was to miss that qualifier, if you had the required attribute on your inputs, then the user would always hear when something was required.

You may also be able to achieve a technical pass by keeping the required attribute and putting the "(required)" text outside the label element.

[JAWS-test]

I think that things that semantically do not belong to the label but are part of the <label> should be an exception according to 2.5.3, i.e. it should not be necessary that they are part of the Accessible Name. If this opinion is shared, this could be included in the Understanding (with exactly the example you mentioned, @joe-watkins).

I suspect that no one using voice input software will speak the "required" when trying to focus the input field.

[scottaohara]

You may also be able to achieve a technical pass by keeping the required attribute and putting the "(required)" text outside the label element.

even trying to do that though:

<label for=p>First name</label> (required)
<input id=p required>

I can make the above still visually resemble the provided example. Where the same issue would still exist of what's the perceived label - including the "(required)" text might still be spoken, and then result in the field not being accessed for this instance.

However, if that were to happen a prompt shows up and recommends I say "tap first name". Doing so, it works as expected for this revised example and the aria-hidden=true example. So in either case, I'd tend to agree with JAWS test's suggestion that maybe an exemption could be noted here?

[mbgower]

I'd tend to agree with JAWS test's suggestion that maybe an exemption could be noted here?

So I think you two are talking about some addition or modification at the least to this wording? Or maybe even an official exemption?

It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this Success Criterion (SC) by lessening predictability.

The challenge is going to be coming up with wording that overcomes the redundancy you want to eliminate, without exempting things one wishes to keep within scope. For example, there are several ways an author can indicate a required field:

1. only programmatic (through hmtl5 or aria)
2. as programmatic enhancements/redundancy to a label or form indicator (use of asterisk, use of label text or instruction text about required fields)
3. strictly label-based or instructional (asterisk with legend, "required" in label, properly surfaced instruction that "all fields are required", etc)
4. Maybe even just surfaced through errors

I don't think you can be successful using only 1? That would work for a blind user or others using AT that surfaced the programmatic equivalent, but everyone else needs something to understand there's a required field. So I think it has to involve at least one of the others.

In regard to the second and third option, I don't think one can categorically say either is the better way and I think either should pass. You could probably make a case that the fourth one is not meeting 3.3.2 Labels or Instructions but it would be debatable.

So, if not using specific programmatic required indicators is acceptable, then we have to be really cautious about exempting any part of the label (real or perceived) that could jeopardize an accessible and usable implementation of number 3.

Do either of you have suggestions on approach?

[JAWS-test]

@mbgower it is not about how to correctly label required fields, but only about whether the required indicator must be part of the AccName according to 2.5.3.

[detlevhfischer]

Proposed working group answer:
We intend to include an exception in the 2.5.3 Understanding text to clarify cases where additions to the label need not be present in the accessible name of the input:

(Draft addition to understanding text)

Additions to text labels that follow the label and are clearly visually and semantically separated, for example, by being set in brackets, need not be contained in the accessible name in order to meet the Success Criterion.

PASS Examples for visible input labels with additions:

• First name (required). "First name" is sufficient as accessible name of the input, The inclusion of (required) would lead to a redundant output if the field is also programmatically marked up with the required attribute.
• First name(s) (all first names as shown on your identity card). "First names" is sufficient as accessible name of the input even though it differs from the exact string of the visible label, which includes the plural (s) in brackets.
• Telephone number (including international call prefix), "Telephone number" is sufficient as accessible name of the input,

[fstrr]

For the "first name (required)" example, I'd add in the aria-required="true" property.

[mbgower]

it is not about how to correctly label required fields, but only about whether the required indicator must be part of the AccName according to 2.5.3.

@JAWS-test With respect, I don't think that's an easy thing to separate. In the past, we would have failed an implementation like this, because 1.3.1 is failing to include the visual indicator "(required)" programmatically.

<label for="p">First name</label> (required)
<input id="p" >

Similar to @fstrr's comment, I feel there is a real problem with passing the first bulleted example in its current form. If it doesn't have aria-required set (which it doesn't technically need), then excluding the "(required)" from the accessible name would actually cause this construction not to surface the text indicator of a required field to AT.
I'm leery of creating holes in a SC to resolve problems with implementation decisions by an AT.

[detlevhfischer]

@fstrr For the "first name (required)" example, I'd add in the aria-required="true" property.
@mbgower If it doesn't have aria-required set (which it doesn't technically need), then excluding the "(required)" from the accessible name would actually cause this construction not to surface the text indicator of a required field to AT

Entirely agree - these were not full code examples, I assumed that the first input would have a required attribute.
I wonder whether you think my draft definition of "additional" content (visual and semantic separation from label proper) would work, though. I agree we don't want to create a loophole.

Also, we probably need something like:

If the additional information visually rendered as part of the label is an important instruction for the user, is must / should be provided not just visually but also as programmatically determinable description (e.g., via aria-describedby or title).

[mbgower]

I think this issue is raising a real problem with the SC, and we should tread carefully in how we attempt to resolve :) I wonder how many other situations there are where the label is potentially redundant to (or even in conflict with) a programmatically set name/role/value

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

Maybe this is orthogonal to label in name, but i think you see what I'm getting at.

[detlevhfischer]

@mbgower yes, it potentially opens a can of worms... but there are a number of situations where the strict adherence to the letter of 2.5.3 seems to have undesirable results.

[mbgower]

Returning to the Understanding document, I think there is 'okay' support for this construct in the existing language.

We can maybe fit this into the Punctuation and capitalization subsection of the Understanding document with the addition of a new paragraph something like:

Similarly, parenthetical text of labels may also be optionally left out of the accessible name for the same reason. However, where parenthetical information provides important context, such as an indication of a required field or guidance on input masks, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names, but in order to pass 1.3.1 Info & Relationships authors would need to surface the required attribute as well as the mask information programmatically (such as through aria-required and aria-describedby)

@joe-watkins @scottaohara @detlev would that work from your perspective?

[detlevhfischer]

@mbgower Yes, I think that would be useful. BTW is 'input mask' still in use? It has a dated feel somehow, but I am not a native speaker. Would it be too restrictive to constrain that to additional info in parentheses, though? If not, there should be examples what is and what is not "clearly separated visually and semantically". For example, what about an informal style like

<label for="userID">User name - or simply use your email-address</label><input id="userID" type="text" autocomplete="username">

would the hyphen qualify?

[mbgower]

@joe-watkins @scottaohara @detlev
I'm returning to this stale issue.
Putting this guidance into the section on symbols didn't make a lot of sense to me when i went to make a revision for this. I have added the information into the part on accessible name and description.
Please review and provide feedback.
#2725

[alastc]

@mraccess77 Could you take a look through, after the discussion in the meeting?

[alastc]

From the WCAG meeting today, we've approved the change, but would like a review from ACT prior to merging. Pinging @WilcoFiers as I can't find the account for Kathy, could you pass this on please?

[scottaohara]

did this get a chance to be reviewed?

[mbgower]

@scottaohara I have added PR #2725 as a draft in the WCAG 2 project, so it should be reviewed shortly.

@kengdoj this was approved at a WCAG meeting almost a year ago, but i believe held up because we were waiting for an ACT review prior to merge. Are you able to review and comment on the PR?