-
Notifications
You must be signed in to change notification settings - Fork 292
Add note about transaction-amount
to 1.3.5 understanding
#4362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add note about transaction-amount
to 1.3.5 understanding
#4362
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
<p>When the user agent and assistive technology support for other metadata formats matures, metadata schemes like the <a href="https://www.w3.org/TR/adapt-symbols/">WAI-Adapt: Symbols Module</a> may be used in addition or instead of the HTML autocomplete attribute to identify the purpose of input fields. They can also support automated adaptations that identify and match author-provided input labels to defined vocabularies or symbols that are used instead for labelling inputs.</p> | ||
<p class="note">Even though the normative wording of this Success Criterion mentions <q>information about the user</q>, the list of <a href="https://www.w3.org/TR/WCAG21/#input-purposes">Input Purposes</a> includes a few values that may not strictly be interpreted as directly relating to a user – most prominently, <code>transaction-amount</code>. In this specific case, authors are required to identify the input fields for transaction amounts when it's a transaction that users are carrying out for themselves.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"for themselves" seems a little awkward. TF would like someone to wordsmith this
reviewed on TF. Lowercased SC, removed reference to 2.1.
Discussed on TF call. Request to @dbjorge or @WilcoFiers tp provide a constructive example? What is a situation where |
I agree, transaction amount is not about the user and is more dangerous to be required as it could autofill. |
we (well, I) originally tried to remove transaction-amount and transaction-currency altogether from the list, but that proposal was voted down...so this tries to square the circle as a result... |
Wilco has offered several already in past discussions. For example, #3539 (review) |
Okay, for Understanding can we limit |
auto-population (if it even happens) is a side effect that's orthogonal to the SC though
how would you specify this? and as an author, how would you do this (in HTML for instance) |
For the one you reference, commenters did not find it persuasive:
Can you please point to one that got support? We're trying to find some kind of example which we can give that allows us to say, effectively, "ignore |
That seems a little shaky . The understanding document talks about it quite a bit:
The only technique we have published for this is H98: Using HTML 5.2 autocomplete attributes Perhaps we could add in guidance that we recommend that It would still be great to think of an example where there is demonstrable benefit. |
unless i'm misreading the HTML spec, you can't set
would be invalid (as it's "wearing the autofill expectation mantle"). you could set |
It's still a side effect of the original ask of the SC, which is to programmatically identify purpose. It'd theoretically be just as valid to use some other form of standardised (or widely supported) metadata (like RDF or similar) ... you'd pass the SC's requirement, but won't get autofill behaviour in browsers... Or, to put another way: if your browser fails to autocomplete somehow, it's not a failure of the SC. hence, the autocomplete/autofill behaviour you get when using (I'll save everybody my lengthy rant at the time about how this weird repurposing/piggybacking on one specific HTML attribute was perhaps not the best idea, and how the whole concept of "using technologies with support for identifying the expected meaning for form input data" was always a chicken-and-egg problem) |
Discussed (but not resolved) on backlog call 5/23. |
At the last backlog call, I said I'd look at this again and possibly suggest a counter-proposal. However, while looking at this, I think the core "problem" we have is: In the normative SC 1.3.5, it starts with (emphasis mine):
Emphasis in the normative SC on the "information about the user". At first, I thought I could leverage this to basically say that that trumps the fact that but then ... and here's the rub ... in the actual input purpose list section, it says:
emphasis on "purposes that MUST be captured". this suggests that regardless of the apparent scope limitation of 1.3.5's normative language, THIS says that everything listed in section 7 there MUST be indicated. Remind me, is section 7 normative, or informative? I think we had this discussion before, and landed on it being normative. In which case, regardless of what the SC says, only way around that would be to make a change to the prose at the start of section 7 to soften that "MUST be captured" ... but i doubt there's any more appetite to do that? |
Discussed on backlog call 5/30. @patrickhlauke has revisited, but we are still left with the problem that the issue cannot be resolved by a note to understanding. He has offered to try and write up the dilemma with a little more detail. |
Changing the interpretation of the scope of 1.3.5 beyond applicability to information about the user seems to go against the intent of the criteria. |
question is, does section 7 https://www.w3.org/TR/WCAG22/#input-purposes and its (in my view quite incorrect) requirement that the listed values MUST be used overrule the scope of 1.3.5 |
So it looks like there's two options at this juncture:
|
* this is an appendix - it should not contain normative *must* statements * the *must* here is contradicted in the sentence immediately following, where it starts with "Where applicable"? This is related to #4362 (comment)
For options 2, I made #4458 as a starting point...if the group feels that that's the best way forward |
transaction-amount
to 1.3.5 understanding
Follow-up to #3539
Adds a note that tries to square the circle on why "transaction amount" is included.