WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Form Submit or Button versus link (href) with action

for

From: Cliff Tyllick
Date: Nov 6, 2010 10:18AM

Often we forget that accessibility is also about removing barriers to people with cognitive disabilities. I would be curious to see how this design works for people with attention deficit and other cognitive disabilities. Would they figure out what they could do? Would they know what to do next? Or would the combination of saying "That's been saved" plus restoring the link to "Rename" confuse them?

I guess I would have to see it to have a stronger sense one way or the other, but that's something I would consider.

Cliff


Cliff Tyllick
Web development coordinator
Agency Communications Division
Texas Commission on Environmental Quality
512/239-4516
<EMAIL REMOVED>
>>> Birkir Rúnar Gunnarsson < <EMAIL REMOVED> > 11/05/10 5:24 PM >>>
As a rule, AT users strongly prefer buttons over links for forms and
other "activities" online, at lesat in my experience.
Most screen readers offer the shortcut "b" to get to the next button
on a page, from anywhere, and I always use this to quickly save and
submit the form.
I understand there may be developmental reasons for implementing a
submit as a link, but make sure that its text is crystal clear,
because when such actions are denoted by links I alwyas find myself
looking at the entire form to figure out what to do and where the link
is (I always subconsciously expect a button).
So make the link text something like "To ave this form, click this
link" instead of just "save", that should be an easy change.
Also, if possible, associate the enter key with the default
action/save action on the form is possible. If users do not find the
button to submit on a form the next trick they try is just to fill in
all the info and hit enter from within an edit fild, hoping it will
trigger the default action of the form.
Thanks
-B

On 11/5/10, Susan Grossman < <EMAIL REMOVED> > wrote:
> This may be a bit of a "no-brainer", but I wanted to make sure. When using
> Ajax I do cartwheels trying to break the code before calling it accessible,
> and send it back to development a lot!
>
> FYI - JavaScript is required to use this application, for other product
> related reasons (this is a service backing up a product).
>
> Were working on an application that we're trying to meet WCAG 2.0. One
> little issue is the need for a submit button on a form. We're using a table
> with accessible Ajax that on a link (tab/enter or click), changes a text
> field to an input.
>
> On this change the focus is moved to the input, which is labeled and
> announces itself correctly, both the label and the current content are read
> out.
>
> After changing this text (it's a rename) the next item tabbed to is a "save"
> link that (tab/enter or click) saves the changed text without refreshing the
> page. There is a message that it has been saved and focus is moved to the
> link that now says "rename" instead of "Save" (the readers speak this) and
> you can continue tabbing to the next table row from there. Focus is not
> locked, and everything is tab-able.
>
> I've tested in JAWS and NVDA (I know the basic keys/shortcuts, though I'm
> not a "real user") and tested with just keyboard. I believe this meets the
> needs, but of course the validators tell me I still need a submit. I'm
> aware that a validator isn't the "end all" but a guide, but wanted to make
> sure I didn't miss something before calling this accessible.
>
> Any comments would be helpful or pointers to how others handle the balance
> between Ajax and accessibility
>
> Thanks -
>
> --
> *Susan R. Grossman*
> <EMAIL REMOVED>
>