WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: wcag 3.3.4

for

From: Caitlin Geier
Date: Jul 18, 2016 12:58PM

Generally, credit card information isn't the entirety of the information
needed for a transaction - there's also often stuff like billing info,
shipping info (if there are physical items involved), etc. There also
should be a list of the things being paid for, with quantities and costs.
Is this the case with the form you're talking about? If all of that
information that is part of the transaction can be viewed or filled out on
the page with the Place Order button, then I think the process of
validating the form would pass 3.3.4 because the user is able to see
everything at once before submitting.

If, however, they entered their billing information on a different page and
can't see that info when they're submitting the credit card form, then I
think it fails 3.3.4 if you don't explicitly prompt / allow a user to
review ALL of the information they entered before the final submission. A
user may not remember what information they gave in previous steps of the
process.

As another example, perhaps the user forgot that an item they decided they
didn't want was still in their shopping cart, which was on a previous page
in the order workflow. If the last screen in the order workflow only has
credit card information on it, submitting the payment at that point would
then charge them for that item anyway, which could have been prevented if
they were able to review the contents of their cart easily before
submitting. Amazon's review screen has saved me from a couple of
unexpectedly expensive transactions by allowing me to view and modify the
items I'm ordering before finalizing the submission.

On Mon, Jul 18, 2016 at 2:25 PM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> This is an interesting problem.
> Using the html disabled attribute takes the focusable element out of
> focus order. That is functionality provided by browsers, perhaps
> dictated by spec.
> Using aria-disabled="true" keeps the control in the browser but
> announces it as "unavailable" (or, in the case of Voiceover on iOS
> "dimmed").
> Screen reader users, at least users with experience, rarely explore
> the webpage using only the tab key, though while in forms mode it is
> convenient.
> So I am not sure to what extent we need to provide them with
> additional info about disabled controls. Would be interesting to do a
> user study on taht sometime and base recommendations off of that
> (e.g., to recommend that browser keep disabled focusable attribute in
> the focus order).
> RE the original question.
> Obviously a payment is not going to be processed unless the user
> provided number, expiration date and CCV number from the same credit
> card, so in a sense that is not a scenario we have to worry about.
> I, personally, had a related incident on a website recently, where I
> meant to provide a coupon code, but did not realize wehre to put it in
> and committed the transaction before I could provide it. I was not
> able to reverse the transaction without emailinc stuomer service, and
> it made me a little grumpy.
> I think the intent of the SC is to allow user a chnce to review the
> complete info before committing to it, and fixing errors on individual
> form fields does not provide the same functionality.
> But trying to read the 3.3.4 text from a "minimal compliance" point of
> view, I think it can be interpreted to say the error correction is
> sufficient.
>
>
>
> On 7/18/16, Jonathan Avila < <EMAIL REMOVED> > wrote:
> >> . The Place Order button is disabled until all fields are completed and
> >> validated (e.g., if the CC # is incorrect, a message is dynamically
> >> displayed).
> >
> > My concern is that some users may not understand why the place order
> button
> > is not available and additionally some screen reader users may tend to
> use
> > the tab key for form input and may become confused when the place order
> > button that is disabled is not in the focus order. I'm not advocating
> > disabled buttons to generally be in the focus order -- but I would
> recommend
> > a message perhaps that was in the focus order when the button was
> disabled
> > to alert users to the situation.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > SSB BART Group
> > <EMAIL REMOVED>
> > 703.637.8957 (Office)
> > Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> > Check out our Digital Accessibility Webinars!
> >
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf
> > Of Jennison Mark Asuncion
> > Sent: Thursday, July 14, 2016 5:42 PM
> > To: webaim-forum
> > Subject: [WebAIM] wcag 3.3.4
> >
> > Looking for a sanity check - imagine a screen with fields: credit card #,
> > month and year of expiration, and postal code. The Place Order button is
> > disabled until all fields are completed and validated (e.g., if the CC #
> is
> > incorrect, a message is dynamically displayed). Once the Place Order
> button
> > is pressed, the order is in fact being placed, and there is text letting
> the
> > user know this is the case.
> >
> > Based on WCAG 3.3.4, one of the following must be true:
> > 1) Reversible: Submissions are reversible.
> > 2) Checked: Data entered by the user is checked for input errors and the
> > user is provided an opportunity to correct them.
> > 3) Confirmed: A mechanism is available for reviewing, confirming, and
> > correcting information before finalizing the submission.
> >
> > Based on this, I am saying this meets 3.3.4, specifically #2. Am I on
> > track?
> >
> > Jennison
> > > > > archives at
> > http://webaim.org/discussion/archives
> > > > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >



--
Caitlin Geier
User Experience Designer
<EMAIL REMOVED>