E-mail List Archives
Thread: wcag 3.3.4
Number of posts in this thread: 7 (In chronological order)
From: Jennison Mark Asuncion
Date: Thu, Jul 14 2016 3:41PM
Subject: wcag 3.3.4
No previous message | Next message →
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
From: Murray Inman (DZZEX54291)
Date: Thu, Jul 14 2016 3:51PM
Subject: Re: wcag 3.3.4
← Previous message | Next message →
Jennison,
When you say "validated" I presume you mean that it is checked for correct
form (e.g. the CC # doesn't violate any rules). I would think that 3.3.4 is
trying to give the user a chance to easily review what was typed in for
correctness rather than for correct form. The user could type in the
information for credit card A but meant to type in the information for
credit card B.
I personally would say that it would not pass the rule.
[image: Rio Salado College Logo]
[image: Rio Facebook] <https://www.facebook.com/RioSaladoCollege> [image:
Rio Twitter] <https://twitter.com/RioSaladoOnline> [image: Rio YouTube]
<http://www.youtube.com/user/riosaladocollege>; [image: Rio Google+]
<https://plus.google.com/+riosalado/about>
*Murray Inman*
System Applications Analyst / Information Services
Tel: 480-517-8610 | Fax: 480-377-4817 | = EMAIL ADDRESS REMOVED =
2323 W. 14th Street Tempe, AZ 85281 | www.riosalado.edu
------------------------------
A Maricopa Community College
Strengths: Individualization
<http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Ideation
<http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Relator
<http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Connectedness
<http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Input
<http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>;
On Thu, Jul 14, 2016 at 2:41 PM, Jennison Mark Asuncion <
= EMAIL ADDRESS REMOVED = > wrote:
> 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
> > > > >
From: Maxability Accessibility for all
Date: Sat, Jul 16 2016 2:05AM
Subject: Re: wcag 3.3.4
← Previous message | Next message →
Hi Jennison,
I still feel it as violation for 3.3.4. I don't find a mechanism to check
the data entered by the user is checked for input errors in cases where a
manual error can happen. Eg: I can enter credit card 1 number in CC number
field and provide CVV of credit card2. Or I want to enter the details of a
card I have but I want to use another card. If I have a review screen I can
check the details of the card before finalizing the purchase.
On Fri, Jul 15, 2016 at 3:21 AM, Murray Inman (DZZEX54291) <
= EMAIL ADDRESS REMOVED = > wrote:
> Jennison,
> When you say "validated" I presume you mean that it is checked for correct
> form (e.g. the CC # doesn't violate any rules). I would think that 3.3.4 is
> trying to give the user a chance to easily review what was typed in for
> correctness rather than for correct form. The user could type in the
> information for credit card A but meant to type in the information for
> credit card B.
>
> I personally would say that it would not pass the rule.
>
> [image: Rio Salado College Logo]
> [image: Rio Facebook] <https://www.facebook.com/RioSaladoCollege> [image:
> Rio Twitter] <https://twitter.com/RioSaladoOnline> [image: Rio YouTube]
> <http://www.youtube.com/user/riosaladocollege>; [image: Rio Google+]
> <https://plus.google.com/+riosalado/about>
> *Murray Inman*
> System Applications Analyst / Information Services
> Tel: 480-517-8610 | Fax: 480-377-4817 | = EMAIL ADDRESS REMOVED =
> 2323 W. 14th Street Tempe, AZ 85281 | www.riosalado.edu
> ------------------------------
> A Maricopa Community College
> Strengths: Individualization
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Ideation
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Relator
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; |
> Connectedness
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Input
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>;
>
> On Thu, Jul 14, 2016 at 2:41 PM, Jennison Mark Asuncion <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > 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
> > > > > > > > > >
> > > > >
From: Bhaskarjyoti Hazarika
Date: Sat, Jul 16 2016 2:22AM
Subject: Re: wcag 3.3.4
← Previous message | Next message →
Hi All,
I think this is a typical situation where there might be a conflict between
Accessibility and Application Security. Error identification may still be a
challenge if it violates the security. Typically the error message will not
say which field has the error if at all there was an error with the inputs
submitted by the user.
Regards,
Bhaskar
On Jul 16, 2016 13:35, "Maxability Accessibility for all" <
= EMAIL ADDRESS REMOVED = > wrote:
Hi Jennison,
I still feel it as violation for 3.3.4. I don't find a mechanism to check
the data entered by the user is checked for input errors in cases where a
manual error can happen. Eg: I can enter credit card 1 number in CC number
field and provide CVV of credit card2. Or I want to enter the details of a
card I have but I want to use another card. If I have a review screen I can
check the details of the card before finalizing the purchase.
On Fri, Jul 15, 2016 at 3:21 AM, Murray Inman (DZZEX54291) <
= EMAIL ADDRESS REMOVED = > wrote:
> Jennison,
> When you say "validated" I presume you mean that it is checked for correct
> form (e.g. the CC # doesn't violate any rules). I would think that 3.3.4
is
> trying to give the user a chance to easily review what was typed in for
> correctness rather than for correct form. The user could type in the
> information for credit card A but meant to type in the information for
> credit card B.
>
> I personally would say that it would not pass the rule.
>
> [image: Rio Salado College Logo]
> [image: Rio Facebook] <https://www.facebook.com/RioSaladoCollege> [image:
> Rio Twitter] <https://twitter.com/RioSaladoOnline> [image: Rio YouTube]
> <http://www.youtube.com/user/riosaladocollege>; [image: Rio Google+]
> <https://plus.google.com/+riosalado/about>
> *Murray Inman*
> System Applications Analyst / Information Services
> Tel: 480-517-8610 | Fax: 480-377-4817 | = EMAIL ADDRESS REMOVED =
> 2323 W. 14th Street Tempe, AZ 85281 | www.riosalado.edu
> ------------------------------
> A Maricopa Community College
> Strengths: Individualization
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Ideation
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Relator
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; |
> Connectedness
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>; | Input
> <http://classweb.riosalado.edu/murray.inman/StrengthsQuest/>;
>
> On Thu, Jul 14, 2016 at 2:41 PM, Jennison Mark Asuncion <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > 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
> > > > > > > > > >
> > > > >
From: Jonathan Avila
Date: Mon, Jul 18 2016 8:42AM
Subject: Re: wcag 3.3.4
← Previous message | Next message →
> . 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 ADDRESS 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 ADDRESS 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
From: Birkir R. Gunnarsson
Date: Mon, Jul 18 2016 12:25PM
Subject: Re: wcag 3.3.4
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Caitlin Geier
Date: Mon, Jul 18 2016 12:58PM
Subject: Re: wcag 3.3.4
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =