RE: Comments on Use cases 1.0

From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: 20 May 2015 07:01
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.

Thanks Manu. I'm used to Github, so the commit viewer (although not my
favourite thing) is usable. Responses inline...

> 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/90d4b2c0ef8b0cac5f680cc6d2d262f
b8ac1854d?diff=unified

Good idea.

> 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/9c8dc497966475aa29e1d38a511eff4
894399bf9

Looks good.

> 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/08dd22a6d94ded355cfa09230e61a4b
fd82cab9f

Ah. Ok, I hadn't understood the interaction. The problem remains the same
though - how does someone who is unable to see the screen know how much
they're paying? If the amount also appears on the payer's device, that's a
good solution. If it doesn't/wouldn't, then there needs to be some way for
that to happen.

> 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/8edc9f0e256b3988c8d2c02195ccc2c
27d446ce8

Looks good.

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

No problem, would be happy to help :) How can we best approach doing this?

> 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/4ece4a783cff91ec46f9166512916c0
eb6b34c00

Looks good.

> 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/9c5ce749da18c8519c57febfbbb3594
85e20ebf1

Looks good.

> 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/736bcef3d65dc7eebf9abf336d57ba3
3516aaa90

Looks good.

> 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/6df087e176739236ded395b8247529c
95f1388d2

Glad it was useful. 

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

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

With perhaps a little more thinking about the tap to pay use case, they do.
Thank you.

Léonie.

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

Received on Thursday, 21 May 2015 10:34:48 UTC