[73f2c2] Autocomplete invalid - Accessibility note clarifies HTML spec's disallowed autocomplete values for specific form controls

[giacomo-petri]

• Included an accessibility support note to explain that discrepancies between form control types and autocomplete attribute values do not affect accessibility and meet the 1.3.5 SC, despite being disallowed by HTML specifications.
• Passing Example 8 was removed to avoid test cases that rely on the user agent or assistive technology used during testing.

Closes issue: #1967

Need for Call for Review:
This will require a 1 week Call for Review

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[giacomo-petri]

Call for review ends on February 21st.

[dd8]

I agree that Passed Example 8 should not be a pass:

• the normative wording of the SC mentions 'programatically determinable' but it's only the understanding document that talks about autocomplete
• Passed Example 8 has two incompatible programatically determinable meanings: one from input=tel, the other from autocomplete=bday-day (both of these are exposed via MSAA / IAccessible2 / UIA )
• The understanding document says the intent of the technique is for user agents to extract and present this purpose to users using different modalities

In this example some modalities convey the meaning as input=tel, and other modalities as autocomplete=bday-day. For example, VoiceOver with Safari announces this as "telephone number field", but somebody using AT to overlay icons on input fields might see a birthday cake icon next to the field (representing birthday day)

If this interpretation is correct, then I think this means the wording about "Thus, if the input possesses the suitable autocomplete ... regardless of type" probably needs to change.

Edit: ... and if this interpretation is correct, Passed Example 8 should probably be a fail rather removed completely

[Jym77]

🤔 @dd8 @giacomo-petri

Quickly browsing through the old issue this fixes, this looks like a case where UA + AT do not behave fully consistently. Moreover, in case of conflicting information (type="tel" vs autocomplete="bday-day"), the rule itself has no real way of deciding which of the two is the real "purpose" of the field and should be "programatically determined". So I think that always failing mismatching autocomplete would cause false positives (this was also the reason to remove that condition previously).

At the same time, I also agree that we shouldn't have a Passed Example like that. It is quite certainly failing the SC, as explained by Mark, so it shouldn't be a Passed Example (tools / methodologies that are smarter than the rule and correctly fail it should still have a consistent implementation).

It feels like we'd want to just discard the inappropriate autocomplete from the start, but we cannot exclude them from the Applicability given the nature of the rule which needs to check at invalid ones…

So, I think the only solution is to keep going as this PR does, maybe buffing up a bit the new note to explain that inappropriate autocomplete may or may not cause a fail of 1.3.5, and this rule doesn't care about them and simply checks validity.

---

We may want to add a rule checking that (valid) autocomplete are appropriate for their type. This would likely only have secondary mapping to 1.3.5.

[carlosapaduarte]

CG: can you document any accessibility support issues related to passed example 8 before we merge this?

[Jym77]

@giacomo-petri I'm removing Call for Review since it looks like #2161 (comment) needs action.

[giacomo-petri]

Replaced background note:

Certain autocomplete attribute values are appropriate only for specific form controls. However, despite some combinations of autocomplete attribute values and form controls not being allowed by HTML specifications, the input purpose is programmatically available, and autocomplete functions correctly. Thus, if the input possesses the suitable autocomplete value, it fulfills the Success Criterion 1.3.5 Identify Input Purpose, regardless of the input type.

with

Authors may assign inappropriate autocomplete attribute values. Moreover, HTML specifications restrict certain autocomplete attribute values to specific form controls. Mismatches between autocomplete attribute values and form control types may or may not lead to a failure of Success Criterion 1.3.5 Identify Input Purpose. However, this rule focuses exclusively on validating valid autocomplete attribute values, disregarding their contextual appropriateness.

[giacomo-petri]

@dd8,

I believe we've covered all the points discussed. We've received 4 approvals, but I'd appreciate your final review, especially considering your previous concerns with the earlier version.

Thanks

[dd8]

Perfect - that fixes it

[giacomo-petri]

Call for review ends on May 8th

[Jym77]

Call for review has ended. Merging.