Autocomplete attribute has valid value updates #1567
Conversation
Co-authored-by: Jean-Yves Moyen <[email protected]>
Co-authored-by: Jean-Yves Moyen <[email protected]>
…ub.io into autocomplete-TF-feedback
…es/act-rules.github.io into autocomplete-TF-feedback
…es/act-rules.github.io into autocomplete-TF-feedback
ajanec01
requested review from
Jym77,
WilcoFiers,
carlosapaduarte,
annethyme,
EmmaJP,
HelenBurge and
nitedog
recognize, not recognise
| [web page]: #web-page-html 'Definition of web page (HTML)' |
There was a problem hiding this comment.
As above. Please undo this. Don't want an autocomplete fix to be in the file history.
There was a problem hiding this comment.
Sorry, not sure how that's happened.
There was a problem hiding this comment.
@WilcoFiers I managed to get rid of the change in embedded-image file but I'm not sure what is happening here. There is literally no change at all. Do you have any suggestions?
There was a problem hiding this comment.
I managed to reverse the updating with origin commit which has caused an issue but there was too much fiddling around with it so decided it would be clearer/ easier to cancel the pr and start from the beginning.
| @@ -37,21 +38,17 @@ Each test target's `autocomplete` [attribute value][] is a [space separated][] l | |||
| 3. An optional token of either "home", "work", "mobile", "fax" or "pager", only if the last token is "email", "impp", "tel" or "tel-\*"; then | |||
| 4. A required token from the [correct autocomplete field][]. | |||
|
|
|||
| ## Expectation 2 | |||
There was a problem hiding this comment.
You still have some failing examples that now pass the rule. Can you take those out and add in a passed example showing this should no longer be failed?
There was a problem hiding this comment.
Will add an example with an incorrect type. Which failed example is now passing? I've looked through them again and I'm not sure which ones you mean.
I've also checked the examples with optional tokens and if they are in the wrong order, querying the autocomplete returns an empty string, which is in line with what we currently have.
Co-authored-by: Wilco Fiers <[email protected]>
…es/act-rules.github.io into autocomplete-TF-feedback
|
|
||
| The `aria-disabled` state is used on `input` elements which are not part of [sequential focus navigation][] and are not otherwise [operable](https://www.w3.org/TR/wai-aria-1.2/#dfn-operable). If this is not the case, this rule may be inapplicable on elements that are still [operable](https://www.w3.org/TR/wai-aria-1.2/#dfn-operable) and require a valid `autocomplete` attribute to satisfy success Criterion [1.3.5 Identify Input Purpose][sc135]. | ||
| Mainstream user agents tend to provide autofill suggestions for `input` elements with or without an [appropriate field name for the form control][]. As such, the assistive technologies should be able recognize the purpose of a control even when the `autocomplete` [attribute value][] is inappropriate for the control's `type` [attribute value][]. |
There was a problem hiding this comment.
I'm not sure what is the assumption here…
"mainstream user agents tend to provide…" is not an assumption, it's a fact
"the AT should be able to…" is also not an assumption.
That should either be moved to the background or phrased in a way that mak the assumption obvious (even though I agree that the "This rule assumes that…" formulation is a bit heavy, I like it before it make it easy to spot the actual assumption and easier to write something which is actually an assumption).
…es/act-rules.github.io into autocomplete-TF-feedback
Applying suggestions from the previous CG call.
autocomplete="off"is not a failure by changing the applicabilitytype? #1562 (Firefox, Safari, and Chrome do not care iftypevalue is appropriate)Closes issue(s):
No need for final call.
How to Review And Approve