Definition of done:
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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Form labels via new variant mechanism | mediawiki/extensions/DonationInterface | master | +120 -2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T87667 Triage accessibility for donor-facing Fundraising components | |||
| Resolved | Ejegg | T169795 Labels for payments form fields |
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:
(Widely cited from excellent https://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/)
@spatton I heard you were interested in this. Is this still relevant? to be clear you want the labels above the fields now?
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.
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.
Change 531766 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] WIP form labels via new variant mechanism
Change 531766 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Form labels via new variant mechanism
OK, this is up on production as a variant for Ingenico. Try it with
https://payments.wikimedia.org/index.php?title=Special:IngenicoGateway&appeal=JimmyQuote&ffname=cc-vmad&payment_method=cc&recurring=&uselang=en&language=en¤cy=USD&amount=1&country=US&variant=labels
Note: you may need to ctrl-F5 to clear old CSS or JS from your cache.
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?
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
Ooh, I notice this label variant fixes T169797: Inconsistent order of payment field errors too!