-
Notifications
You must be signed in to change notification settings - Fork 266
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
Conversation
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
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. |
discussed in the last WCAG 2.x backlog meeting (10 Nov). Decided that there is a faint justification for |
transaction-amount
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. |
I agree that it'd be better if it Edit: For clarity/transparency, whether it's normative is contested - it depends whether you think it qualifies as an "appendix" |
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. |
as in "people might misread WCAG and think that's...certainly an interesting argument. accessibility by deception... |
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:
|
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)
|
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? |
Alternatively, failing agreement on removing
|
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 |
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.
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 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. |
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. |
@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. |
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. |
@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? |
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 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. |
(Chair hat off)
Preferred currency isn't being removed by this PR, just the amount. (I'm sure you know that, maybe I misunderstood.)
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). |
@dbjorge said
To clarify, my point was that you agreed that
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 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.
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 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. |
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.
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 I agree that this is more likely to cause problems with unintended inputs for
@WilcoFiers and I will discuss tomorrow morning and get back to you. |
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. |
@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:
|
I also have a question. Has COGA been consulted on this change? This criterion was championed by COGA after all. |
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" |
@dbjorge wrote:
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, Regardless, per @alastc email to list I am okay with either of the two options he lists:
|
Wilco asked:
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:
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. |
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:
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?
|
@mbgower I'm not sure what part isn't clear. Myself and two colleagues voted -1. Those are objections. |
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? |
It is hard to argue that
transaction-currency
andtransaction-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