Skip to content
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

Update Input Purposes list to remove transaction-amount #3539

Closed
wants to merge 2 commits into from

Conversation

patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Nov 7, 2023

It is hard to argue that transaction-currency and transaction-amount in any meaningful way "relate to the user of the content and pertain only to information related to that individual". (the first one, just at a stretch perhaps, but both are clearly scoped towards a specific transaction the user is carrying out)

UPDATE: after discussion, decided to only remove transaction-amount

Closes #3537


Preview | Diff

It is hard to argue that `transaction-currency` and `transaction-amount` in any meaningful way "relate to the user of the content and pertain only to information related to that individual". (the first one, just at a stretch perhaps, but both are clearly scoped towards a specific transaction the user is carrying out)

Closes #3537
@patrickhlauke
Copy link
Member Author

Either this, or the preamble for this section needs to be tweaked to suggest that the list of values presented here is not just about the user...

@benja11y
Copy link
Member

benja11y commented Nov 8, 2023

Either this, or the preamble for this section needs to be tweaked to suggest that the list of values presented here is not just about the user...

If the preamble was changed, the Intent section would also need to be tweaked. I have not been able to be able to read that section and come to the conclusion that transaction info is included in its scope.

@patrickhlauke
Copy link
Member Author

discussed in the last WCAG 2.x backlog meeting (10 Nov). Decided that there is a faint justification for transaction-currency as information relating to the user (i.e. their preference for currency, related conceptually to their credit card etc details), so re-adding it back.

@patrickhlauke patrickhlauke changed the title Update Input Purposes list to remove the transaction values Update Input Purposes list to remove transaction-amount Nov 13, 2023
@scottaohara
Copy link
Member

scottaohara commented Mar 22, 2024

i'd like to see this correction be made. i realize this would be considered a normative change, and also respect the argument of 'is this a significant enough issue for the LOE of a normative change" ... but imo, because this is an inaccuracy and is normative, is exactly why this should be corrected.

edit: but since we realized since we discussed, that this is not a normative change since the content is in an appendix, then i absolutely see no reason not to move forward with this.

@alastc alastc added the ErratumRaised Potential erratum for a Recommendation label Mar 29, 2024
@dbjorge
Copy link
Contributor

dbjorge commented Mar 29, 2024

I agree that it'd be better if it transaction-amount hadn't been included in the list, but I don't think this is critical enough to fix to warrant being the first normative erratum we've ever issued for 2.x.

Edit: For clarity/transparency, whether it's normative is contested - it depends whether you think it qualifies as an "appendix"

@alastc
Copy link
Contributor

alastc commented Mar 29, 2024

Argument from the TF discussion:


What's the benefit of removing it?

There is a small positive to accessibility from it being in the list.

Also, the normative phrasing starts with "information about the user", so arguably it wouldn't be required anyway, if you don't consider transaction-amount 'about the user'.

Either way, doesn't seem like it needs the change.

Something to discuss at the larger meeting, see if it meets that threshold.

@patrickhlauke
Copy link
Member Author

There is a small positive to accessibility from it being in the list.

as in "people might misread WCAG and think transaction-amount is required normatively, even though it's not, and they might do it because they think WCAG requires it, but it may benefit some users anyway even though WCAG doesn't require it"?

that's...certainly an interesting argument. accessibility by deception...

@mbgower
Copy link
Contributor

mbgower commented Apr 5, 2024

On Friday's call, once it was pointed out that this appendix info is not normative, covered in 5.1 Interpreting Normative Requirements, the people who had voted Thumbs down at that time (@dbjorge and @ljoakley) agreed to support:

Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative).

@mbgower
Copy link
Contributor

mbgower commented Apr 8, 2024

Later on Friday's discussion, it was pointed out that although 7. Input Purposes for User Interface Components appears where an appendix is conventionally located (at the end of the document's main sections, after the glossary), it is not actually labelled as an "Appendix".

However, after the call I confirmed there is a clear record of intent for this to be an appendix, based on the official working group response (and the follow on response and support by issue opener)

RESOLUTION: working group decides to move the list into an Appendix of WCAG 2.1 unless that change contravenes CR status.

@alastc
Copy link
Contributor

alastc commented Apr 15, 2024

Question for those not in favor of the change (@dbjorge?) - Can we argue that it was never normatively required anyway?

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

So I would argue that anything which is in the list but not about the user is not required. In the same way that anything in the list is not required when it is not about the user. (E.g. filling in for your family members.)

So if it has been included but logically never required, wouldn't that make it a non-substantive change?

@patrickhlauke
Copy link
Member Author

Alternatively, failing agreement on removing transaction-amount, can we agree that the sentence that precedes the whole list in https://www.w3.org/TR/WCAG22/#input-purposes is incorrect/misleading if that value remains in, and should be changed instead?

The following input control purposes are intended to relate to the user of the content and pertain only to information related to that individual.

@dbjorge
Copy link
Contributor

dbjorge commented Apr 16, 2024

Question for those not in favor of the change (@dbjorge?) - Can we argue that it was never normatively required anyway?

Yes, I agree with this. If we're satisfied that that means the erratum wouldn't need to be a normative one, I'm fine with removing it from the list; my objection is only that I don't think this meets the bar for a normative erratum, not that removing it would be a bad change in principle.

I'll note that whether an author includes the autofill attribute has limited practical impact; Chromium and Firefox both treat it as an "unsupported" category of autofill attribute.

Copy link
Contributor

@WilcoFiers WilcoFiers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Let's remember this criterion isn't about autocomplete, it's about personalization. Whether browsers autofill this is irrelevant. Section 7 Input purpose says this about it:

This [taxonomy] provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

This criterion came out of wanting content authors to add semantics to their page so browsers and extensions could add known icons, labels, styling to the page to make it easier for them to recognize what things are and what they do. That was the point of it. Semantics so that you can add an icon to a field that you're supposed to enter a transaction amount to is really very useful. This feels like one or the more important ones to me.

@GreggVan
Copy link

@WilcoFiers
Hmmmm That is a very blurry line. The fact that you bought something. The price you paid. The pages you looked at. the search terms you used. those also are about you. Actually every field in every form is now data mined to learn about you. So we need to start thinking about all information as information about us.

We also need to look at the flip side. We all like "free google searches" and "free gmail" and free this and free websites of information. But someone has to pay for all of that. Today we pay for it with our personal information. If we made everything anonymous on the web (no leakage) then a lot of places would have trouble paying for themselves. They could try traditional ads - but we would block them. And then they just have to fold up.

Interesting dilemma,

But not an accessibility issue. Maybe a general population education question....

PS did you know that the algorithms can (with an amazing and scary level of confidence) now tell if you are pregnant before you even know you are - jsut from the natural (unknown to you) changes in your behavior online? They can also tell all sorts of other things about you with scary reliability. We can run - but it is very hard to hide. And if we all did - it would change how the web runs and is financed.

@mraccess77
Copy link

The criterion in my opinion is limited to collecting information about the user. An amount doesn't seem to fall into that category. While I agree that sites collect a lot of other information about users and the SC probably should have used a different term - I think the intent was scoped to things that are user specific. The discussions made a clear distinction between information about other users and about you personally.

@WilcoFiers
Copy link
Contributor

@mraccess77 I agree there's a difference between information about others and about me. When I send an e-mail, the "to" field is not about me. That's where we should draw the line. But that's not the argument by which people seem to have concluded we should make this normative change. The argument is that a how much someone paid for something isn't information "about the user".

Lots of things are "about a user" that aren't directly identifying information such as their name or phone number. Medial records, financial records, browser history, assistive technology use, etc is information about a person. Even if that isn't information I can use to find the person with (although it can be), that's still information about that user.

Why is someone's country of residence information "about" them, but their financial records are not? I get the distinction from an "autofill" perspective, you can autofill a country, doing that for an amount doesn't make sense. But again, this criterion isn't about autofill. The Input Purpose section in WCAG is clear about this.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented Sep 13, 2024

When I send an e-mail, the "to" field is not about me. That's where we should draw the line.

I'm not sure I actually see this line that you're drawing. Using your same rationalisation that "the transaction amount I want to pay is also information about me", we can also say "who I want to send an email to is also information about me"? and with the same thinking of ultimately, this being about personalisation, I could well imagine the argument being made that a user may want to customise (e.g. add a custom visual icon or similar) to a "To" field in an email client...

And yes, the root of the argument is not autofill per se. It centers around what you see what is and isn't encompassed by "about the user", per the normative language. If you wanted to have this apply to all sorts of input types, then the "about the user" should really have been removed altogether from the normative language. What you're arguing for, apparently, is that in the end, everything (to an extent) a user inputs is somehow "about them" ... meaning that the "about the user" wording in the normative language is effectively redundant?

I have to admit, this isn't necessarily a hill I want to die on, there are bigger incongruities in WCAG. however, i'm not the only developer/auditor who has read the normative language of the SC, and then had a bit of a headscratcher moment when seeing that transaction amount is also listed, which many would not consider to be "about the user" in the stricter sense of the meaning.

@mbgower
Copy link
Contributor

mbgower commented Nov 5, 2024

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.

Let's remember this criterion isn't about autocomplete, it's about personalization. Whether browsers autofill this is irrelevant. Section 7 Input purpose says this about it:

This [taxonomy] provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

This criterion came out of wanting content authors to add semantics to their page so browsers and extensions could add known icons, labels, styling to the page to make it easier for them to recognize what things are and what they do. That was the point of it. Semantics so that you can add an icon to a field that you're supposed to enter a transaction amount to is really very useful. This feels like one or the more important ones to me.

@WilcoFiers This was vetted by the TF and then went through a WG review last spring and received support. You thumbed up (thumbs upped?) a comment from @dbjorge around that time which seemed to be supportive.

Can you two please discuss this and decide on Deque's position, and whether your -1 stands?

@dbjorge
Copy link
Contributor

dbjorge commented Nov 5, 2024

You thumbed up (thumbs upped?) a #3539 (comment) from @dbjorge around that time which seemed to be supportive.

This is a 👍 on a comment where I advocated for not implementing the change, I don't think it's reasonable to interpret it as being supportive of the change.


I agree with Wilco's -1.

I continue to think, as I did then in that linked comment, that this change is unnecessary and arbitrary; I don't think a user's preferred currency is any more or less "about the user" than the user's preferred language, which isn't being proposed for removal from the list.

I think our TF discussions about removing it have really focused around the autofill aspect and not the personalization aspect, and I think with the personalization goal in mind, my position has shifted to more strongly feel that there isn't sufficient grounds for a normative change here. We've had a few TF discussions since the pre-CFC, but my recollection (and what I can find in the minutes) is that those were all focused around whether or not the section should be considered normative vs informative; I can't recall having further followup discussion about "in consideration of the SC's intent being to enable personalization rather than to enable autofill, are we sure that removing these transaction-* items is the right call?"

I think it's clear from the discussion that it's ambiguous whether something like "transaction amount" meets the "about the user" bar or not. But I think "the SC is ambiguous about whether it should count" just means that we should interpret the language using the usual priority of constituencies, ie, with user needs first: is the user need that motivates the SC more likely to be addressed by including or excluding the items?

I think that the user need the SC's stated intent mentions - being able to personalize how the field is displayed according to its input purpose - is better served by keeping the list as-is. If we need to clarify better for authors whether it counts, we can do that in a note or in the understanding doc.

@alastc
Copy link
Contributor

alastc commented Nov 5, 2024

(Chair hat off)

I don't think a user's preferred currency is any more or less "about the user" than the user's preferred language

Preferred currency isn't being removed by this PR, just the amount. (I'm sure you know that, maybe I misunderstood.)

I think it's clear from the discussion that it's ambiguous whether something like "transaction amount" meets the "about the user" bar or not.

I've not seen an argument in favour of transaction-amount being considered "about the user" that would then exclude anything a user might type in. We need the "about the user" to exclude things like: name of a relative. A relative is tangentially about the user.

However, the SC can become harmful by misleading people (via personalisation and/or autofil) into putting in the wrong information.

I don't see transaction-amount being harmful in that sense, but I do think we need a clear line between what is about the user, and what is not. Having transaction-amount blurs that line, and leaves it less clear (see Patrick's comments above).

@mbgower
Copy link
Contributor

mbgower commented Nov 5, 2024

@dbjorge said

This is a 👍 on a comment where I advocated for not implementing the change, I don't think it's reasonable to interpret it as being supportive of the change.

To clarify, my point was that you agreed that transaction-amount was not beneficial. You're statement was:

I agree that it'd be better if it transaction-amount hadn't been included in the list, but I don't think this is critical enough to fix to warrant being the first normative erratum we've ever issued for 2.x.

We spent time researching and debating the nature of the list (whether it was an appendix, whether it was normative, etc). As you know, there is no longer a question of whether the change warrants the effort; we've queued up almost 20 items to be incorporated into the republish of the spec. The question becomes, is it better to leave this in place or update?

During the Working Group discussion on this on April 9 your statement was:

I would characterize this as an editorial change to a normative part of the text. Deque would not object, but would vote no.


I feel like the discussion has now been turned to the nature of the perceived benefit to users versus concerns about undesirable outcomes as a result of authors following the requirement.

I think our TF discussions about removing it have really focused around the autofill aspect and not the personalization aspect, and I think with the personalization goal in mind, my position has shifted to more strongly feel that there isn't sufficient grounds for a normative change here.

There is one sufficient and one failure technique published in regard to the use of this list, and they are both specifically about the use of autocomplete attributes. A concern in the original issue was that forcing authors to programmatically designate the transaction-amount auto-fill attribute increases the risk of a prior value being autopopulated on a site, contrary to a user's intent or desire.

Unlike Alastair, 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. However, like Patrick I don't feel like this is the largest challenge we face.

So what I'm trying to understand is: is the -1 a "no" but not an objection? If you're now feeling this is worthy of an objection, IMO we can kill/defer and let the other errata go through. If not, there seems to be good support for it.

@dbjorge
Copy link
Contributor

dbjorge commented Nov 6, 2024

As you know, there is no longer a question of whether the change warrants the effort; we've queued up almost 20 items to be incorporated into the republish of the spec.

When I talk about something "not warranting a normative change", it's not coming from a concern that it's time-consuming for the working group to queue up a new edition of the spec; the much, much bigger cost is that it creates a burden for everyone subject to legislation that incorporates WCAG as it existed at a specific date in time. Because the normative errata don't apply to those cases, authors subject to such legislation now need to worry about adhering to the normative requirements as they existed before the errata, but it's very easy for an author to miss this or misunderstand that. They usually end up needing to meet the requirement both with and without the errata if they're publishing in multiple legal jurisdictions.

This is why I make such a big deal about normative vs informative changes in TF discussions.

However, the SC can become harmful by misleading people (via personalisation and/or autofil) into putting in the wrong information.

A concern in the #3537 was that forcing authors to programmatically designate the transaction-amount auto-fill attribute increases the risk of a prior value being autopopulated on a site, contrary to a user's intent or desire.

Thanks for bringing this up again. I had become convinced that this was not concerning based on a reading of the relevant chromium/firefox source that appeared to treat autocomplete="transaction-amount" as ignored for autofill purposes. But based on you bringing this up I went back and tested the behavior and found that my previous understanding was wrong, and that UAs do in fact do autocompletion with transaction-amount fields, including for same-named inputs across different origins.

I agree that this is more likely to cause problems with unintended inputs for transaction-amount than many of the other fields, but I also don't think this problem is unique to transaction-amount - I think it would also be problematic for a user to have their credit card number or contact information autofilled if they didn't want it to be.

So what I'm trying to understand is: is the -1 a "no" but not an objection? If you're now feeling this is worthy of an objection, IMO we can kill/defer and let the other errata go through. If not, there seems to be good support for it.

@WilcoFiers and I will discuss tomorrow morning and get back to you.

@mraccess77
Copy link

My two cents. 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 don't think that was the intent when we discussed using autocomplete for this purpose.

@WilcoFiers
Copy link
Contributor

@dbjorge and I talked this over. We are both going to stay on a -1 vote. My objection here is stronger then Dan's. Regarding a formal objection, the W3C process is that objections come after a decision is made, not during the vote. So if the chairs decide consensus is reached despite these -1's, without a vote on publishing without this change, Deque will at least consider raising an FO.

To repeat and summarize, the two reasons for voting -1 are:

  • There are good reasons why in cerain situation people may want the ability to give custom styles to input fields for a currency amount. The point of this criterion was always personalization, not autocomplete. When AGWG first approved this, we knew not everything on this list would immediately benefit people, and we knew there was a chance it never would. We're still in that situation. Yes, there isn't wide spread adoption of tools that use autocomplete to give custom styles to form fields. Removing the requirement means it never will.
  • The "there is grey area" and "this feels less about the user then the other values" is not a strong enough of a reason to introduce a normative difference between WCAG 2.1 2024 edition, and all copies, including into standards and legislation, all its translations, etc. A clarification in the understanding documents is a better way to handle this.

@WilcoFiers
Copy link
Contributor

I also have a question. Has COGA been consulted on this change? This criterion was championed by COGA after all.

@patrickhlauke
Copy link
Member Author

Counter-proposal: either make a change to the normative wording of the SC to remove the confusing/contradicting "about the user" part altogether (as it's really tough to explain how a payment amount is "about the user"), OR updating the understanding to effectively backtrack and say "we know we said 'about the user' ... but actually, just ignore that bit"

@bruce-usab
Copy link
Contributor

@dbjorge wrote:

...I went back and tested the behavior and found that my previous understanding was wrong, and that UAs do in fact do autocompletion with transaction-amount fields, including for same-named inputs across different origins.

I agree that this is more likely to cause problems with unintended inputs for transaction-amount than many of the other fields, but I also don't think this problem is unique to transaction-amount - I think it would also be problematic for a user to have their credit card number or contact information autofilled if they didn't want it to be.

In the context of this SC, I don't agree it is problematic for CC or contact information to be autofilled -- since those are reused often across different transactions. (Autofill of CC and other sensitive information is a bigger and different issue.) In contrast, transaction-amount is hardly reused. Any benefit from custom styling is lost to the harm of usually having to make a correction to a wrong value. Also, an empty value (which the page would catch), is much easier to spot and fix than an incorrect value.

Regardless, per @alastc email to list I am okay with either of the two options he lists:

If others express objections (-1s) based on the input-purpose aspect alone, we can remove that part and consider it consensus.
If there are no other objections we can “pass with an objection”.

@alastc
Copy link
Contributor

alastc commented Nov 7, 2024

Wilco asked:

Has COGA been consulted on this change? This criterion was championed by COGA after all.

Not specifically, but several members are active in AG and attended the meeting where this was discussed. My understanding is that, at the time of the SC development, COGA were happy with the "about the user approach" so their perspective would be to make that work effectively.

Pat wrote:

OR updating the understanding to effectively backtrack and say "we know we said 'about the user' ... but actually, just ignore that bit"

I don't think we can do that, even apart from that is in the SC text itself, we need that aspect so people aren't dinged for not-including autocomplete on fields about other people.

@mbgower
Copy link
Contributor

mbgower commented Nov 8, 2024

Regarding a formal objection, the W3C process is that objections come after a decision is made, not during the vote. So if the chairs decide consensus is reached despite these -1's, without a vote on publishing without this change, Deque will at least consider raising an FO.

My interest here, @WilcoFiers, is to understand whether what is on record -- that Deque is going to vote "no" but "would not object" -- is accurate.

I don't believe anyone thinks this is a change which is going to have massive ramifications either way. We do not have evidence of any author using this attribute as a means of realising advantages in personalization nor do we have evidence that the implementation of this auto-complete attribute is causing harm. It's motivated by the TF trying to correct something that appears to be an unintentional error of inclusion.

So I am obviously highly unmotivated to have what I consider a minor correction lead to all the work and turmoil of an objection. On the other hand, if -- as has occurred before -- this is simply a desire on your part to have your disagreement on record and not a desire to actually object to the CFC, then given this has had otherwise good support in the TF and WG, my inclination is to proceed with it.

Hence the reason I asked for clarity from Deque. To ensure I am being crystal-clear here, I'll restate my last comment:

If you're now feeling this is worthy of an objection, IMO we can kill/defer and let the other errata go through.

Please let me know your decision.


On the TF call which just wrapped up, it was agreed to work on some content in the Understanding document to try to clarify intent. So if Deque does indicate this is serious enough for them to object, we have some avenue to address the concern.

However, as Bruce and Alastair have pointed out, in order to pass the SC in its current form, a team must use this attribute on any transaction amount, even if they discover harm to a user (as a result of a prior use of a page causing an unintended and incorrect population of the transaction amount). That concern is the reason I'm pushing back, to a degree.


@JohnRochfordUMMS, do you or anyone else on COGA want to specifically weigh in on this?

Wilco asked:

Has COGA been consulted on this change? This criterion was championed by COGA after all.

Not specifically, but several members are active in AG and attended the meeting where this was discussed.

@WilcoFiers
Copy link
Contributor

@mbgower I'm not sure what part isn't clear. Myself and two colleagues voted -1. Those are objections.

@mbgower
Copy link
Contributor

mbgower commented Nov 19, 2024

Based on -1 responses to CFC, not implementing. On the TF call, it was agreed to work on some content in the Understanding document to try to clarify intent. @patrickhlauke I believe you are opening a separate PR for that?

@mbgower mbgower closed this Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.3.5 Identify Input Purpose ErratumRaised Potential erratum for a Recommendation WCAG 2.2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Does the autocomplete attribute apply to the currency dropdown and Amount input fields on the transfer page?
10 participants