• Organism
  • CORE COMPONENT
  • Taxonomic name: O-WALLET
  • Extension: PAYMENTS
  • Added on: v3.4.0 (08/06/18)
  • Updated on: v5.11.0 (07/09/21)

Wallet, add card

Wallet allows users to add and use payment methods within their account to make payments on Abeille Assurances websites. This addition allows users to add new credit cards to their wallet.


Design and usage

Desktop / tablet

Structure

  • The adding card form is shown in a full screen modal.
  • When the modal loads, the card image on the right is displayed in its default state. Its default state is where the card details are left empty, with 'X's denoting the card number and expiry date.
  • As the user enters their card details, the card image on the right updates with a replay of the information that is being entered:
    • Once the card type is recognised, the card image transitions its background colour to match the colours of the card brand (refer to the designs for the different card colour patterns) and the card logo also fades in.
    • As the form data is entered, the card image updates with a replay of these details (ie. the card image on the right shows the card information that has been entered into the form fields).
    • RATIONALE / INSIGHT: The purpose of the replay image is to show the card details in a format that closely resembles the physical card allowing a closer association of information.
  • The add new card form can also show a toggle option to make this new card their default card; this is an optional feature that will appear depending on whether the project has chosen to implement the default functionality.
  • The dates in the form fields and on the card image are displayed in a MM/YY format, but can be shown as MM/YYYY when needed.
  • The add card primary button remains disabled until the form fields have been completed (excluding the action of clicking the default button – as a user can choose not to select this.) The disabled version of the “Add card” button does not follow the usual Framework pattern for disabling a primary button. See the designs for how the “Add card” button looks.
  • After adding a card, the user returns to the top of the wallet section where a success/fail notification is placed. If the card has been successfully added, the user will see a success notification, otherwise they will see our error notification card with a failure message.
  • The newly added card will appear as the first card in the sequence, unless there is another card that is the default card. If another card is the default card, the newly added card will appear as the second card in the sequence.
  • If the user closes the modal without adding a card, they return to the page position they were at previously.

Labels

  • All modals must have a 'Cancel' form button and the 'Close' modal button.
  • In the modal, the card image displays the full card number, but when the card appears in the wallet sequence (after being added) only the last 4 digits are shown.

Non-JS requirements and considertions

  • The screens that would normally appear in a modal instead appear on separate pages.
  • Content is left aligned to the page.
  • The grey background and card image on the right is hidden from view, as the card recognition relies on JS.
  • Unsupported card type messages only show when the form is submitted to the server.

Accessibility and screen readers

  • Aria-invalid must be used to indicate when an error has occurred with this element.
  • Aria-describedby must be used to link any help, instructional and/or error text with the element/form fields.

Placement

  • Full screen modal forms show as built and the layout cannot be modified.

Mobile

The mobile experience is adaptive and creates a difference experience compared to that of the desktop and tablet variants.

  • The adding card form is still shown in a full screen modal, however the default view has an 'Add a new card' heading inside the card background colour. When the user taps the first form field, the content scrolls up to hide the heading.
  • The user is asked to fill each form element separately in a stepped approach.
  • The form fields used in the mobile design are specific to this organism and can't be used elsewhere.
  • The card recognition functionality remains the same as the desktop and tablet experience. Background colour changes, card logo appears and card details update to reflect content in the form fields.
  • Cancel and Next buttons always appear above the keyboard.
  • Form error states show their error message by replacing the card image.

Examples

Interactive example

Code example

Add card - modal trigger button

Add card

Add card - content


Add a new card

Please use the format MM/YY

Please enter the name as it appears on the card

Add card - content with errors


Add a new card

There are problems with your card details; please correct them before continuing.

Error: ...

Please use the format MM/YY

Error: ...

Please enter the name as it appears on the card

Error: ...

Development and test

Notes for developers

Basic setup

For basic information about setting up wallet, including standard classes, information regarding locale settings, card types and so on, please visit the Wallet documentation page.

Input types

Care should be taken when choosing input field types for various uses, particularly with regard to number entry, as making the wrong selection could prevent users from inputting the required details into a form. For further information, see the form introduction page.

Aria usage for errors and help text

To aid screen reader users in completing forms without error and also with understanding and fixing any errors that have occured, some additional aria attributes are now recommended to be applied across all form fields/rows.

All form row help, explanatory text, form row instructions and form row errors must have a unique id assigned to them and be appropriately linked to either the individual form input or the form row using aria-describedby. This ensures that the help text is read out immediately on focus of the form input/fieldset. When there is more that one item that requires referencing within the aria-describedby attribute the id values must be supplied in the form of a space separated list. For example if there is an error with id of 'err1' and help text with id of 'help1' the value for the aria-describedby attribute would be 'err1 help1'.

All inline form error messages should start with the hidden text 'Error: ' so that when read by out by a screen reader it is immediately clear that the text being read is an error message.

All erroring form fields (or fieldset if a group or radios/checkboxes) must have aria-invalid="true" set on them, ensuring that when a user focus' on an errored form field, the field will be announced as invalid, so the user is then aware that there in an issue that requires fixing.

When linking help or errors, or even adding aria-invalid to the markup careful consideration must be taken as to where it is most appropriate to apply the value. The following rules should be used to decide where the attribute(s) should be applied.

  • Single form field - All attributes should be applied directly to that form field
  • Group of form fields but only one in error or help text applies to only one - Apply the attribute(s) to the only field in error or where the help text applies
  • Group of form field where all in error or the help text applies to all - Apply the attribute(s) to the groups surrounding fieldset (form row)

There may situations where more than one of these rules applies to the overall form row for example a date range where the instruction text applies to both fields so should be linked to the fieldset for the date range but one of the two fields is in error so the error should be linked to just that field not to the fieldset.

Important messages

To help those using assistive technologies, make sure that success/error messages which need to be announced to users have their aria attributes updated to role="alert" and/or aria-live="assertive".

Extension component

This component forms part of the 'payments' extension and so requires an additional stylesheet to be loaded in order to be used; include the following code in the header of your page to attach the relevant additional stylesheet:

Changing locale settings

Default text for the navigation controls at mobile can be changed for a particular locale.

en: {
	oWallet : {
		nextButton : 'Next',
		previousButton : 'Back',
	},
},

For more information on this, see our page on how to change locale settings within JavaScript.


Notes for testers

  • Ensure that all form fields have a correctly associated label. This not only provides context to each field for assistive technology users but also a larger clickable area to select the field. Clicking/pressing on a label for a single input field should cause the input to gain focus.
  • Ensure that autofill is not available for sensitive fields such as password, card/account number etc.
  • Users should be able to copy and paste if necessary.
  • If the field has been restricted in length the maximum number of characters allowed must also be restricted. Note: many browsers will not do this for number field and older browsers will not do this at all.

Classes overview

The following table gives you a quick overview of the CSS classes that can be applied.

Class Outcome Required Applied to Comments
.o-wallet-card-display Base style for card display area Yes div  
.o-wallet-card-display__heading.o-wallet-card-display__heading--mobile Style for card display heading at mobile Yes .o-wallet-display > l-content-container > p  
.o-wallet-card-display__heading.o-wallet-card-display__heading--desktop Style for card display heading at tablet and desktop Yes .o-wallet-display > l-content-container > p  
.o-wallet-card-display-inner Style for card display inner content wrapper Yes .o-wallet-display > l-content-container > div  
.o-wallet-card-display-inner__number Style for card number within card display Yes .o-wallet-display-inner > p  
.o-wallet-card-display-inner__expiry Style for expiry date within card display Yes .o-wallet-display > p  
.o-wallet-card-display-inner__name Style for card holder's name within card display Yes .o-wallet-display > p  
.o-wallet-wrapper Base style for main wallet area Yes div  
.o-wallet Base style wrapping container of wallet organism Yes .o-wallet-wrapper > div Defines styling for standard form elements when used within wallet
.o-wallet-add-edit-remove-heading Style for main heading Yes .o-wallet > h1  
.o-wallet-add-edit-remove Style for main form rows wrapper Yes .o-wallet > div  
.o-wallet-add-edit-remove-buttons Style for form row containing primary and secondary CTAs Yes .o-wallet > .m-form-row  

Keyboard operations

TAB

Tabbing to an input field should make the input clearly visually different so that the focus point on the page is obvious to the user.

Component releases

  • Added on: v3.4.0 (08/06/18)
  • Updated on: v5.11.0 (07/09/21)

Latest update:

  • fixed: Card replay now correctly shows the expiry date with the '/' when the value auto formatted.
  • fixed: Very long names on very narrow tablet displays now wrap rather than overflowing the content area.
  • fixed: 'Add card' button has now been disabled until all inputs have values.
  • fixed: Tabbing at mobile is now contained within the visible carousel area, rather bypassing the 'Next' button and jumping between them.
  • fixed: Various minor issues with the print stylesheet have been corrected.

Full version history

A full history of changes and enhancements detailing all minor and major updates to the component.

View full version history

Want something new in Framework, or to chat about an issue you're having with it?

Contact the team