Closed giacomo-petri closed 3 weeks ago
Call for review ends on February 21st.
🤔 @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.
CG: can you document any accessibility support issues related to passed example 8 before we merge this?
@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.
Replaced background note:
Certain
autocomplete
attribute values are appropriate only for specific form controls. However, despite some combinations ofautocomplete
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 certainautocomplete
attribute values to specific form controls. Mismatches betweenautocomplete
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 validautocomplete
attribute values, disregarding their contextual appropriateness.
@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
Call for review ends on May 8th
Call for review has ended. Merging.
Closes issue: #1967
Need for Call for Review: This will require a 1 week Call for Review
Pull Request Etiquette
When creating PR:
develop
branch (left side).After creating PR:
Rule
,Definition
orChore
.When merging a PR:
How to Review And Approve