Comments on Use cases 1.0

Hello Web payments,

 

Thanks for putting these use cases together – it’s really good to see future
work starting on this basis. It was also an easy document to read and
understand, so props to the editors/authors.

 

I’ve noted down some thoughts on accessibility. Not sure whether it’s what
you were looking for, but hope it helps in any case.

 

1.       Introduction.

 

Where terms like “Point of Sale” are introduced for the first time, it would
be helpful to indicate the corresponding acronym in parenthesis. For example
“Point of Sale (PoS)”. It’ll help everyone, but especially people with
cognition or literacy difficulties.

 

4. A simple example of the payment phases.

 

The example is worth including. It’s good to see the effort being made to
make the information in this document accessible (in both senses of the
word).

 

6. Use cases.

 

6.1.1. Discovery of offer.

 

Point of Sale kiosk:

 

At present kiosks are rarely accessible to blind people, people with low
vision, people who use wheelchairs, or people with restricted mobility that
makes touch interaction difficult/impossible. They don’t tend to offer
speech output, any ability to zoom or customise colours, may be difficult to
reach from a wheelchair/sitting position, and do not accept voice commands.

 

Making kiosks (that are used for financial transactions) accessible
introduces several challenges. Speech output may be overheard by people
nearby, increased text size and/or visibility of content may make it easier
for other people to read, and voice commands may also be overheard.

 

Mobile:

 

Where a “tap to pay” option is provided on someone else’s device, it may be
difficult for a blind person to access it. One option may be to enable the
accessibility features of the device (assuming there are any), another
option might be to offer a second screen on the payer’s own device.

 

6.1.2.1. Non-essential use cases.

 

Registration-less:

 

Completing a transaction without registering an account is a good thing, and
it will likely benefit people with cognitive disabilities because it’s a
more simple process. That said, it will be important to establish trust
early on in the transaction (for everyone), but especially for people who
are on the Autistic spectrum – where the lack of formality may lead to
distress and abandonment of the transaction.

 

6.2.2. Selection of payment instruments.

 

Digital wallets:

 

This is stating the obvious, but it will be absolutely essential for digital
wallet interfaces to be accessible. The need for interface consistency
across digital wallets is mentioned in this document, so an extension of
this should be consistent accessibility/usability. If work will be done to
identify common design patterns within digital wallet interfaces, it may be
worth putting together some guidance on how best to make those things
accessible?

 

It’s worth noting that accessibility is a strong use case for digital
wallets. The ability to initiate a transaction from a personal device goes a
long way to solving many accessibility problems with current transaction
mechanisms. A personal mobile will already have the accessibility features
needed by its owner, the platform/app will be familiar (removing uncertainty
that may stop some people from completing the transaction), and it becomes
easier to ensure personal data is protected from accidental/intentional
access by other people.

 

6.2.3. Authentication to access instruments.

 

Multi-factor:

 

It’s good to see the note about biometric accessibility, but it may not be
enough to require alternative biometric scans to authenticate. It’s touching
on the edge case, but a quadriplegic may not be able to place fingers or
palms on a scanner, and if they’re in a wheelchair they may not be able to
get line of sight with a retinal scanner either. It may be worth thinking
about non-biometric alternatives, where biometrics is the default option.

 

6.4.2. Delivery of receipt.

 

Electronic receipts:

 

The methods taken to protect receipts from being read/accessed between the
payee and the payer can sometimes cause accessibility issues. Enabling
security settings on a PDF can remove the underlying semantics, making the
PDF unreadable with a screen reader for example.

 

 

In the UK we have a system where you can associate your mobile phone number
with your bank account. People can then make a payment to you using your
mobile number instead of your bank account details. The transaction itself
is an online bank transfer, not a mobile to mobile payment. This may be
another use case perhaps?

 

Léonie.

 

-- 

Léonie Watson Senior accessibility engineer, TPG

@LeonieWatson @PacielloGroup PacielloGroup.com