E-mail List Archives
Re: wcag 3.3.4
From: Birkir R. Gunnarsson
Date: Jul 18, 2016 12:25PM
- Next message: Caitlin Geier: "Re: wcag 3.3.4"
- Previous message: Jonathan Avila: "Re: Wave Tool and Document Outline"
- Next message in Thread: Caitlin Geier: "Re: wcag 3.3.4"
- Previous message in Thread: Jonathan Avila: "Re: wcag 3.3.4"
- View all messages in this Thread
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!
>
>
>
- Next message: Caitlin Geier: "Re: wcag 3.3.4"
- Previous message: Jonathan Avila: "Re: Wave Tool and Document Outline"
- Next message in Thread: Caitlin Geier: "Re: wcag 3.3.4"
- Previous message in Thread: Jonathan Avila: "Re: wcag 3.3.4"
- View all messages in this Thread