Skip to content

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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

patrickhlauke
Copy link
Member

Follow-up to #3539

Adds a note that tries to square the circle on why "transaction amount" is included.

Copy link

netlify bot commented Apr 25, 2025

Deploy Preview for wcag2 ready!

Name Link
🔨 Latest commit bda88bd
🔍 Latest deploy log https://app.netlify.com/projects/wcag2/deploys/68555ff7dfbd780008272f9b
😎 Deploy Preview https://deploy-preview-4362--wcag2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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>
Copy link
Contributor

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.
@bruce-usab
Copy link
Contributor

Discussed on TF call. Request to @dbjorge or @WilcoFiers tp provide a constructive example? What is a situation where transaction-amount would be helpful for personalization and addresses coga-related need? In previous discussions, there was consensus that auto-fill for transaction-amount is problematic.

@mraccess77
Copy link

mraccess77 commented May 9, 2025

I agree, transaction amount is not about the user and is more dangerous to be required as it could autofill.

@patrickhlauke
Copy link
Member Author

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...

@dbjorge
Copy link
Contributor

dbjorge commented May 12, 2025

Request to... provide a constructive example?

Wilco has offered several already in past discussions. For example, #3539 (review)

@bruce-usab
Copy link
Contributor

For example, #3539 (review)

How much money I donated to a gofundme, how much I bid on an auction, how much I tip, that's information about me. It is not identifying information like my name or an e-mail address is, but it is still about me. Not all currency fields are about me, not every field to enter a transaction amount is about a user, but when it's about a user's money it's about that user IMO.

Okay, for Understanding can we limit transaction-amount for situations where a user is returning to a specific website as opposed to across any/all websites (where something like email-address would be expected to auto populate?

@patrickhlauke
Copy link
Member Author

patrickhlauke commented May 16, 2025

auto-population (if it even happens) is a side effect that's orthogonal to the SC though

can we limit transaction-amount for situations where a user is returning to a specific website as opposed to across any/all websites

how would you specify this? and as an author, how would you do this (in HTML for instance)

@mbgower
Copy link
Contributor

mbgower commented May 22, 2025

@dbjorge

Wilco has offered several already in past discussions. For example, #3539 (review)

For the one you reference, commenters did not find it persuasive:

  • That is a very blurry line

  • An amount doesn't seem to fall into that category... I don't think transaction amount is something that is "about the user" and as such should not be part of what is required for input purpose.

  • I'm not sure I actually see this line that you're drawing.

  • Having transaction-amount blurs that line, and leaves it less clear

  • I do see a likelihood of harm from this: a user unknowingly submitting the wrong value. To me this outweighs what is an abstract discussion on future personalization uses.

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 transaction-amount, except in circumstances such as this, for this reason".

@mbgower
Copy link
Contributor

mbgower commented May 22, 2025

@patrickhlauke

auto-population (if it even happens) is a side effect that's orthogonal to the SC though

That seems a little shaky . The understanding document talks about it quite a bit:

In addition to repurposing this taxonomy, when the autocomplete attribute technique is used to meet this Success Criterion, browsers and other user-agents can suggest and 'autofill' the right content by autocompleting these fields based on past user input stored in the browser. By defining more granular definitions of common input purposes, for example “Birthday” (autocomplete="bday"), browsers can store personalized values for each of these fields (the user's birthday date). The user is relieved of having to type the information and can instead confirm or, if needed, change the value of the field, a significant benefit for users with memory issues, dyslexia, and other disabilities

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 transaction-amount should be used cautiously, and that where it is used, include autocomplete="off"?

It would still be great to think of an example where there is demonstrable benefit.

@patrickhlauke
Copy link
Member Author

Perhaps we could add in guidance that we recommend that transaction-amount should be used cautiously, and that where it is used, include autocomplete="off"?

unless i'm misreading the HTML spec, you can't set off on the autocomplete for the form field itself if you also want to provide its purpose. so

<input type="number" autocomplete="transaction-amount off">

would be invalid (as it's "wearing the autofill expectation mantle").

you could set autocomplete="off" on the entire form, but that would seem a bit heavy-handed and counterproductive.

@patrickhlauke
Copy link
Member Author

That seems a little shaky . The understanding document talks about it quite a bit:

In addition to repurposing this taxonomy, when the autocomplete attribute technique is used to meet this Success Criterion, browsers and other user-agents can suggest and 'autofill' the right content by autocompleting these fields based on past user input stored in the browser.

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 autocomplete is more a side effect/lucky accident

(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)

@bruce-usab
Copy link
Contributor

Discussed (but not resolved) on backlog call 5/23.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented May 30, 2025

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):

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

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 transaction-amount is listed in the input purpose list ... it clearly seems to limit the scope of the SC. So the counter-proposal note could say "note that not all input purposes are about the user, so even though it's listed, transaction-amount likely isn't needed to pass the SC.

but then ... and here's the rub ... in the actual input purpose list section, it says:

This section contains a listing of common user interface component input purposes. The terms below are not keywords that must be used, but instead represent purposes that must be captured in the taxonomy adopted by a webpage. Where applicable, authors mark up controls with the chosen taxonomy to indicate the semantic purpose. This provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

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, transaction-amount seems required due to the "MUST be captured" language. so we likely need to stick with this PR here that tries to somehow explain this ... and it seems based on that wording that we must FAIL a site that doesn't use transaction-amount ?

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?

@patrickhlauke patrickhlauke self-assigned this May 30, 2025
@bruce-usab
Copy link
Contributor

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.

@mraccess77
Copy link

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.

@patrickhlauke
Copy link
Member Author

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

@patrickhlauke
Copy link
Member Author

patrickhlauke commented Jun 2, 2025

So it looks like there's two options at this juncture:

  1. go with some form of what this SC is trying to do ... explain why transaction-amount, even though it may not appear to be "about the user", is required (possibly referencing the fact that in section 7 all the listed values are required)
  2. modify section 7 to soften/mitigate that "purposes that must be captured" (which should probably never have been written that way ... as it seems to create an unnecessarily restrictive normative requirement...not in an SC, but directly in an appendix/section) ... maybe even just softening it to a "should". or be more radical and make section 7 purely a list of purposes defined in the HTML spec, but remove the preamble that says these must/should be used (and leave that aspect to the actual SC, which is then scoped to just "about the user"). and then we add a note in the SC explaining why transaction-amount for instance would NOT be required.

patrickhlauke added a commit that referenced this pull request Jun 20, 2025
* 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)
@patrickhlauke
Copy link
Member Author

For options 2, I made #4458 as a starting point...if the group feels that that's the best way forward

@patrickhlauke patrickhlauke changed the title Add note about transaction-amount to 1.3.5 understanding Add note about transaction-amount to 1.3.5 understanding Jun 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants