Page MenuHomePhabricator

Labels for payments form fields
Closed, ResolvedPublic4 Estimate Story Points

Description

Definition of done:

  • Text appears above fields
  • This is a testable variant beside what is currently on prod

older body text
Quoting @schoenbaechler

Some form fields lack a proper label, e.g. «First name», «Last name» and Email address. It’s an accessibility no go to use the placeholder attribute as a substitute for labels. Maybe use fixed labels above the input or the float label pattern for form fields.

We will probably also need to test this to see the effect on conversion.

Details

Related Gerrit Patches:
mediawiki/extensions/DonationInterface : masterForm labels via new variant mechanism

Event Timeline

Pcoombe created this task.Jul 5 2017, 7:12 PM

Adding to the task description there are different objections:
Browser will expose placeholder attribute contents to the accessibility API in absence of a connected label element. Nevertheless always use a label for a form input as:

  1. Placeholder text disappears when a text box receives focus:
    • For keyboard users this can be problematic as they must read ahead of current focus when filling in forms.
    • Users, especially those with memory impairments will not have the text label available for reference at the same time as filling in a field.
  2. Users may think a text field is already filled in and skip over it.
  3. If the placeholder hint text is useful information it should be available while the user is filling in the field.

(Widely cited from excellent https://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/)

Ejegg raised the priority of this task from Medium to High.Jul 11 2017, 7:47 PM

@spatton I heard you were interested in this. Is this still relevant? to be clear you want the labels above the fields now?

@DStrine This is probably something we would want to A/B test as well if possible. Trilogy have made a mockup for us, although there are questions over how it should behave on mobile.

Hey @DStrine, could you provide some time estimate re: effort to implement, vs. set up as a variant we can test?

We can make this change on our form but the credit card hosted payment pages may be very complicated or not allowed. So we could make this task about our forms and then separate investigations on each processor.

DStrine set the point value for this task to 2.Jul 17 2019, 4:56 PM
DStrine updated the task description. (Show Details)Aug 20 2019, 8:34 PM
DStrine changed the point value for this task from 2 to 4.
Ejegg added a subscriber: Ejegg.Aug 21 2019, 2:59 AM

If we want to A/B test this via variants, it may be easiest to use dynamic partials, that is, nested child templates which can be chosen according to a variable value. This is a feature we can enable by passing a flag when we compile the templates: https://zordius.github.io/HandlebarsCookbook/LC-FLAG_RUNTIMEPARTIAL.html

Those dynamic partials could also help us with A/B testing other form changes (like T224929) without so many special-purpose JS modules.

Note that this will bring us further away from the Mediawiki core usage of LightNCandy, but they don't seem to be adding things like our helper functions any time soon, so we might want to give up on the idea of eventually standardizing on core's templating code.

Ejegg claimed this task.Aug 21 2019, 11:04 PM
Ejegg moved this task from Backlog to Doing on the Fundraising Sprint Quick and the Deadlocked board.

Change 531766 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] WIP form labels via new variant mechanism

https://gerrit.wikimedia.org/r/531766

Change 531766 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Form labels via new variant mechanism

https://gerrit.wikimedia.org/r/531766

Looks good to me!

Perfect @Ejegg, thank you for working on this!

Wow! Great to see how the payment form evolves @Ejegg @scervantes 👏

Simply just out of curiosity, how do you plan to measure success for this change?

Ejegg added a subscriber: TSkaff.Sep 10 2019, 4:54 PM

Good question @schoenbaechler ! I assume we're going to run an A/B test with and without the variant=labels (this should work for any gateway with personal info fields, btw), and compare the drop-off between form hits and donations. @scervantes, @Pcoombe, @TSkaff, @spatton: Does that sound right? Would we want to look at quality of data somehow?

Good question @schoenbaechler ! I assume we're going to run an A/B test with and without the variant=labels (this should work for any gateway with personal info fields, btw), and compare the drop-off between form hits and donations. @scervantes, @Pcoombe, @TSkaff, @spatton: Does that sound right? Would we want to look at quality of data somehow?

I imagine we will want to run an A/B test, and then adopt if there's no noticeable drop-off in conversion because of the accessibility improvement. Measuring quality of data sounds a bit too complicated

Ejegg closed this task as Resolved.Sep 11 2019, 4:37 PM