Re: Comments on Use cases 1.0

On 04/30/2015 07:36 AM, Léonie Watson wrote:
> 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.

Hi Léonie, thanks for your comments. This is an official editor's
response to your review comments. When I've made changes based on your
feedback, I've referenced the Github source code commit that implemented
the change.

My apologies in advance, as I have no idea how well the Github commit
viewer works with screen readers. If there is a better way to prove that
the changes have been implemented, let me know and I'll try to go back
and use that mechanism.

> 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.

Fixed. We've tried to stay away from over-use of acronyms. Rather than
introduce an acronym, I've removed the acronym from the use cases.

https://github.com/w3c/webpayments-ig/commit/90d4b2c0ef8b0cac5f680cc6d2d262fb8ac1854d?diff=unified

> 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.

I have added your language almost verbatim to the point of sale kiosk
"accessibility" and "privacy" sections:

https://github.com/w3c/webpayments-ig/commit/9c8dc497966475aa29e1d38a511eff4894399bf9

> 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.

Hmm, "tap to pay" in this case means that the payer taps their mobile
phone on the payee's mobile phone, physically pressing the mobile phones
together for a short period of time.

I've added the following language to an accessibility section in the
mobile "tap to pay" use case:

An auditory cue notifying people that have low vision or are blind
that a payment offer/invoice is awaiting their response as well as
providing guidance on how close their payment device is to the payment
terminal would be helpful.

Please wordsmith as necessary.

https://github.com/w3c/webpayments-ig/commit/08dd22a6d94ded355cfa09230e61a4bfd82cab9f

> 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.

I've added an accessibility note related to establishing formality for
registration-less purchases for people on the autistic spectrum:

People who are on the Autistic spectrum may require trust with the
merchant to be established through a more formal means to prevent
distress and abandonment of the transaction.

https://github.com/w3c/webpayments-ig/commit/8edc9f0e256b3988c8d2c02195ccc2c27d446ce8

> 6.2.2. Selection of payment instruments.
> 
> Digital wallets:
> 
> 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?

Yes, absolutely, and we look forward to working w/ you to put that
document together. :)

> 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.

+1, I've added a note on accessibility to the digital wallets section:

The consistent presentation of digital wallet interfaces also includes
consistent accessibility hints that are exposed in an interoperable
fashion so that devices that are accessability-aware can easily
integrate with the transaction process.

https://github.com/w3c/webpayments-ig/commit/4ece4a783cff91ec46f9166512916c0eb6b34c00

> 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.

Added the following text to make it clear that non-biometric
alternatives should be considered alongside biometrics:

Not everyone can provide fingerprints or detailed iris scans. Therefore,
it is important to offer multiple forms of biometric verification to
improve accessibility in addition to providing alternatives to biometric
verification, such as strong two-factor verification.

https://github.com/w3c/webpayments-ig/commit/9c5ce749da18c8519c57febfbbb359485e20ebf1

> 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.

Noted, and an accessibility comment has been added to the electronic
receipts section to reflect this:

Protecting digital receipts may have the unintended consequence of
degrading or preventing their use with accessibility technology. It is
important that protection measures do not prevent accessibility
technology from reading pertinent information about the transaction.

https://github.com/w3c/webpayments-ig/commit/736bcef3d65dc7eebf9abf336d57ba33516aaa90

> 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?

Agreed. I've added a "memorable payment identifier" use case based on
this scenario:

Memorable IDs

Vern sends money to his friend Ramone by typing in Ramone's mobile phone
number and the amount he wants to send.

Goals

Improved user experience, Innovation, Monetization, and rapid,
widespread adoption.

Motivation

Some countries, like the United Kingdom, maintain registries that map
memorable identifiers like mobile phone numbers to bank accounts. These
memorable payment identifiers can be used to transmit money from person
to person using direct bank to bank transfers.

https://github.com/w3c/webpayments-ig/commit/6df087e176739236ded395b8247529c95f1388d2

The latest Editor's Draft now reflects the changes requested by you and
applied in the changesets above:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

Let us know if these changes have addressed the concerns you had with
the document.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Wednesday, 20 May 2015 06:01:22 UTC