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

[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 https://github.com/act-rules/act-rules.github.io/pull/2161#issuecomment-1959659500 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

[giacomo-petri]

Call for review ends on May 8th

[Jym77]

Call for review has ended. Merging.