Resolve "Form control has accessible name" feedback

[maryjom]

Form control has accessible name
This issue is to resolve comments found in the survey results.

Charu Pandhi

• Will there be a separate rule for 3.3.2: Labels or Instructions? cuz form can have an accessible name and can still fail 3.3.2 for e.g. with aria-label. Should we make that clear?

answer: This is now explained in the background section.

Kathy Eng

• For Trusted Tester, Pass Example 2 would be inapplicable because it is disabled. Disabled input elements do not receive keyboard focus, cannot be selected, and cannot be modified.

answer: Leaving as is, disabled input elements can still be called up and navigated to using form tools in assistive technologies. "disabled" is a state, it does not change the role of the element. I think that makes it applicable for 4.1.2.

• Did not find form elements for examples with explicit roles (Pass 5, Fail 3,4,5,6) so TT results would be inapplicable.

Answer: This seems like a limitation of the tool that you are using, not an issue with the rule.

Trevor Bostic

• I would suggest making failed examples 3 and 4 use input examples. The div + role combo just adds confusion I think.

David MacDonald

• Wondering about this
  <input aria-label="last name" disabled />

Should this also pass
<input aria-label="" disabled />

OR this
<input disabled />

I'm thinking that a disabled control wouldn't need an accessible name unless that name was visually presented in which case it would be 1.3.1... but I'm open to discussing this.

I've seen examples of an offscreen <select> which was used by javascript to feed values into a quantity <span> which seemed to work OK with AT.

<button aria-label="decrease quantity by 1"> - </button><span id='dynamic-from-select'>Quantity 2</span><button aria-label="Increase quantity by 1> + </button>
(offscreen)
<select disabled>
<option>1</option>
<option>2</option>
...</select>

answer: See my comment to Kathy.

Kasper Isager

• There is an open issue 826

Wilco Fiers

• There's an open issue for combobox. The ARIA working group has proposed a fix to combobox, which means it will required an accessible name. I don't think this needs to be resolved.
• The second note in applicability says: "This means WCAG 2.1 does not require it to have an accessible name." I'm not convinced this is true anymore. An argument can be made that the "value" part of "Name, role, value" requires that options have an accessible name. I'm OK leaving that ouf ot the rule, but this sentence should probably be removed.
• Passed example 2 would be improved by adding a visible label as well
• Passed example 3 would be improved by adding one or two non-empty options
• Passed example 6 may pass the rule but it does not satisfy the success criterion. It would be better to remove it.
• Failed example 7 seems unnecessary. Could potentially be removed
• Inapplicable example 2, 3 and 4 are still focusable, and arguably might still fail SC 4.1.2. They should be disabled

[WilcoFiers]

Awaiting assignment by ACT-R CG.

[WilcoFiers]

There's a PR for it here, awaiting reviewers: act-rules/act-rules.github.io#1357

[WilcoFiers]

Pr merged, ready for another survey.

[maryjom]

@WilcoFiers Apologies, seems I missed creating the survey for this but put a "surveying" label on it and then didn't actually create one. Not sure what happened. So we'll have one more survey to complete!

New Survey on Form control has non-empty accessible name due 6 August.

[WilcoFiers]

Closing, the PR for this is here: w3c/wcag-act-rules#28