[73f2c2] Autocomplete invalid - Pass example 8 is a fail, and justification is inconsistent

[tombrunet]

Current text:

This autocomplete attribute value only has the required token "bday-day". It remains programmatically identifiable even though it is inappropriate for the control's type attribute value "tel".

<label>Birthday day<input name="bdayday" type="tel" autocomplete="bday-day"/></label>

This example should be a failure since bday-day must be a numeric input type and is not allowed for type="tel". It also fails in this basic checker:
https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.w3.org%2FWAI%2Fcontent-assets%2Fwcag-act-rules%2Ftestcases%2F73f2c2%2F35d0948a2cb309923e9a7cc5dd99a8ffc975088b.html

The description seems to indicate that it's a pass because the value can be programmatically accessed, however, that's true for all of the fail examples. The only distinction that I can make is that "bday-day" is valid for other input types, but not this type.

As-is, this forces a tool that is correctly identifying appropriate values based on input type to pass something that is a failure.

[WilcoFiers]

Right, so this is something that was changed a while back. Previously we would require type to be allowed. The issue is that autocomplete works perfectly fine, even if HTML spec the type isn't allowed. For the type=tel example, this is used quite a lot to trigger the number input on mobile devices. It's unfortunate that it has to work that way, but browsers implemented at that way, and as far as i can tell, even though it's not valid HTML, there's no negative impact to accessibility that I'm aware of.

[tombrunet]

Okay, so 1.3.5:

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

The Input Purposes page has a note that: "The list of input type purposes is based on the control purposes defined in the HTML 5.2 Autofill field section". Unfortunately, that link is no longer valid, but it's fairly clear that it's trying to point to the valid values from the HTML 5.2 spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill), which is what establishes all of those tokens. The spec that specifies those tokens as valid tokens says that those tokens aren't valid for type="tel".

If we ignore the spec, then where does the list of valid tokens come from? At that point, any token is good enough. https://www.w3.org/WAI/WCAG21/Techniques/html/H98 even alludes to this by saying "If the autocomplete field is used to describe a "custom" taxonomy, rather than that described in the specification, this rule may produce incorrect results."

I'm fine with accepting that some tools might let this slide because it doesn't create a barrier in practice, but by the terms of the standard, it's a failure. By including this testcase as a pass, we flag tools as inconsistent. If we want to let this scenario slide despite the standard, the testcase should be removed.

[Jym77]

Validity on the type was removed in #1583.
Discussed in #1562.

The rule has a Background note:

Many browsers provide auto-filling suggestions even when the control's type attribute value is not appropriate for its autocomplete attribute value. The same happens when the autocomplete property is queried. However, the autocomplete property is not programmatically identifiable if the requirements for the optional tokens are not met.

The rule has previously been approved by the TF, which seem to indicate they didn't have problem with this bit. @tombrunet can you raise the issue to the TF? The CG is in agreement that we shouldn't test appropriateness, and that this example is needed precisely to ensure tools don't do it too as the CG feels this isn't a WCAG failure.

[mbgower]

even though it's not valid HTML, there's no negative impact to accessibility that I'm aware of.

Philosophically, this puts us in an odd situation where we are beginning to pass things we know are failures just because as far as we know, they don't cause accessibility issues.

While I can see not wanting to fail something like this (given it causes no known issues), it seems to me not having the test case is a better approach than having something we know is wrong Pass.

Until 4.1.1 Parsing goes away in 2.2, I think this would fail that, would it not? Once we get to 2.2, this rules could just be removed, but until then I wonder if it has to stay a fail for that reason.

Speaking of which, @alastc isn't it jumping the gun to have updated the 2.1 information when 2.2 isn't even at PR yet? I also thought that this should only be taking place on the 2.2 material; the 2.1 and 2.0 stuff should remain in place, no?

https://www.w3.org/WAI/WCAG21/Understanding/parsing.html

Understanding Success Criterion 4.1.1: Parsing
Success Criterion 4.1.1 Parsing (Level ): This criterion has been removed.
Intent NOTE
This criterion has been removed from WCAG 2.2.

[alastc]

Speaking of which, @alastc isn't it jumping the gun to have updated the 2.1 information when 2.2 isn't even at PR yet?

Ah, *!£$, correct, that shouldn't have gone live in the understanding doc yet. I'll amend the understanding doc so that only shows for 2.2.

[Jym77]

Until 4.1.1 Parsing goes away in 2.2, I think this would fail that, would it not? Once we get to 2.2, this rules could just be removed, but until then I wonder if it has to stay a fail for that reason.

Given what I understand of the discussion that lead to the removal of 4.1.1, a wrong autocomplete attribute was never intended to be a failure for it (Parsing it to take very literally, and validation of the HTML/DOM is not part of it).

[mbgower]

@Jym77 my colleague @tombrunet made a similar point to me, so I think my comments on 4.1.1 are off base (but the question on 1.3.5 remains).

[tombrunet]

To be clear, I'm not arguing that a tool shouldn't be allowed to ignore this scenario, even though I'm not convinced as to why it should be ignored. I was told that this is being allowed because mobile developers mis-use type="tel" to popup a keypad on mobile. It seems like for this example at least, type="number" would be the right answer.

In any case, I don't believe our tool should be flagged as inconsistent because we flag this as an error when the SC specifically points to HTML5 spec, and HTML5 spec clearly says it's not allowed.

Even if the browsers let it work, there's no spec that indicates that it should work. We trigger it as a fail because we don't want to have to incur support and fixpack deployment costs because some future browser decides that was a bug (since it's not allowed by spec) and fixes it.

[giacomo-petri]

Even if the browsers let it work, there's no spec that indicates that it should work. We trigger it as a fail because we don't want to have to incur support and fixpack deployment costs because some future browser decides that was a bug (since it's not allowed by spec) and fixes it.

We do the same. Another common scenario is autocomplete="street-address" which expects a "Multiline" as control group, while usually an input type="text" is used.

To be clear, I'm not arguing that a tool shouldn't be allowed to ignore this scenario

Same here; could be great having this clarified somewhere in 1.3.5 WCAG understanding (I know it's not ACT rules responsibility).

[Jym77]

To be clear, I'm not arguing that a tool shouldn't be allowed to ignore this scenario

Same here; could be great having this clarified somewhere in 1.3.5 WCAG understanding (I know it's not ACT rules responsibility).

We could at least escalate an issue to WCAG to ask whether these are 1.3.5 violations or not.
If they are indeed violations, then we should definitely drop the example (even if we do not change the rule) since Passed Examples cannot fail the associated SC. And we may discuss changing back the rule (or adding another rule).
If they are not violations, we may discuss further what to do…

[alastc]

This example should be a failure since bday-day must be a numeric input type and is not allowed for type="tel".

Assuming you mean pass/fail of WCAG, it would only fail if the purpose isn't programmatically available. If it has the appropriate autocomplete that's generally going to pass unless something blocks that.

The thing that could block that would be if it were not 'accessibility supported', i.e. doesn't work in the AT you're testing with.

However, as Wilco said: "The issue is that autocomplete works perfectly fine, even if HTML spec the type isn't allowed."

it's fairly clear that it's trying to point to the valid values from the HTML 5.2 spec

It is saying that is the original source, but the list of values is from the appendix of WCAG. That was included in the spec to prevent changes elsewhere undermining the SC.

We could at least escalate an issue to WCAG to ask whether these are 1.3.5 violations or not.

If the purpose is programmatically provided, and practically works in AT (is accessibility supported), then it is a pass.

[mbgower]

If the purpose is programmatically provided, and practically works in AT (is accessibility supported),

This could get messy when we get into 'he said/she said' disputes over where a problem stems from. Suppose something like this is failing/buggy in one AT but not another. What then?

[Jym77]

Suppose something like this is failing/buggy in one AT but not another. What then?

Then, we fill in an Accessibility Support note which is precisely here to document these problems.
And we try to avoid test cases hitting it, since it is equally valid to pass or fail them (depending on the UA/AT that were used for the test).
And the TF is reviewing rules yearly to check, among other, if these discrepancies still exist or if the buggy UA/AT has been fixed.

See also #1939 for more discussion about managing the Accessibility Support notes (which is not yet a very good process).

[dd8]

After testing Passed Example 8 in VoiceOver I think this is a fail:

<input name="bdayday" type="tel" autocomplete="bday-day"/>

The SC says:

The purpose of each input field collecting information about the user can be programmatically determined

The understanding document says

The intent of this Success Criterion is to ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present this purpose to users using different modalities

The problem is both type and autocomplete can be programmatically determined, so results will be inconsistent between different modalities:

• autocomplete=bday-day is surfaced through the MSAA / IAccessible / UIA APIs.
• type=tel is also surfaced through the MSAA / IAccessible / UIA APIs

In VoiceOver this field is announced as "telephone number field" which doesn't match the autocomplete purpose. Cognitive AT using the autocomplete to display icons next to the input field will render an icon for bday-day (e.g. a birthday cake to show day of birth is expected)

That means different modalities expose different purposes, so some users get the wrong information. That seems like a failure to me.