"Autocomplete attribute has valid value" [73f2c2]: Add more failing examples

[Jym77]

While working on Alfa support for webauthn, we found out that there was a bunch of incorrect scenario we were not detecting 🙈 So adding some more failed examples to catch these.

Not that theHTML spec for the tokens states: (emphasise mine)

[T]he autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of just autofill detail tokens.

The "just" bit is my reasoning for failing case with extra tokens at the end. I haven't check if these cause actual problems with autofilling 😅 If they don't, we should rather update the Expectation to state that they are not problematic.

Closes issue(s):

• N/A

Need for Call for Review:
This will require a 1 week Call for Review (adding a bunch of examples).

---

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.

[tbostic32]

The additional tests look good to me, but I would want to get confirmation that they create actual problems before approving. Otherwise, there may be additional details we need to add into the background or accessibility support.

[Jym77]

The additional tests look good to me, but I would want to get confirmation that they create actual problems before approving. Otherwise, there may be additional details we need to add into the background or accessibility support.

Ah, yes. Haven't really checked that (not sure how to… 😅 )

If they do not create a problem, then we should instead update the rule (+note saying why we accept them), and have them as Passed/Inapplicable examples, I guess (currently, they are failing the rule as it is written). If they are inconsistent dependant on UA/AT combination, we should replace them with an Accessibility Support note.

[WilcoFiers]

Don't know that the test suite necessarily needs to be this extensive. I don't mind if they are though, so fine with me.

As for Trevor's suggestion, I'm not sure what there is to test about fail 6 - 9. They are missing a key token, so they couldn't possibly work. For 9 and 10 you could publish a page somewhere where you check if these can be autocompleted by the browser. We did test this at the time we wrote the rule, I have no reason to think this changed so for me that's not strictly necessary.

[Jym77]

Don't know that the test suite necessarily needs to be this extensive. I don't mind if they are though, so fine with me.

I recently figured out that Alfa was passing these examples, and getting a consistent implementation of the rule despite that problem 😅

[Jym77]

Call for review ends on March 23rd.

[Jym77]

Call for review has ended. Merging.