E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Susan Grossman
Date: Fri, Nov 05 2010 12:33PM
Subject: Form Submit or Button versus link (href) with action
No previous message | Next message →

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 ADDRESS REMOVED =

From: Birkir Rúnar Gunnarsson
Date: Fri, Nov 05 2010 4:24PM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
>

From: Cliff Tyllick
Date: Sat, Nov 06 2010 10:18AM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

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 ADDRESS REMOVED =
>>> Birkir Rúnar Gunnarsson < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>

From: Susan Grossman
Date: Sat, Nov 06 2010 11:36AM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

Thanks for the things to consider and discuss with the team! They were all
appreciated.

Cliff is correct that I was thinking more of key board users and AT users
than people with cognitive issues.

I do wonder though if there is a way to tell JAWS that the href is acting
as a button so the "b" will work?


Susan

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.
> Cliff
>
>
>

From: Jared Smith
Date: Sat, Nov 06 2010 2:15PM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

On Sat, Nov 6, 2010 at 11:32 AM, Susan Grossman wrote:

>  I do wonder  though if there is a way to tell JAWS that the href is acting
> as a button so the "b" will work?

<a role="button" ...>

That will do the trick in ARIA supported screen reader and browser combinations.

Jared

From: Susan Grossman
Date: Sat, Nov 06 2010 2:54PM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

Wonderful. Thank you.


> > I do wonder though if there is a way to tell JAWS that the href is
> acting
> > as a button so the "b" will work?
>
> <a role="button" ...>
>
> That will do the trick in ARIA supported screen reader and browser
> combinations.
>
> Jared
>

From: Terrill Bennett
Date: Sat, Nov 06 2010 4:09PM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | Next message →

In numerous articles over many years, the Usability pundit Jackob
Nielsen has stated his first law as being "users spend most of their
time on other websites." In the article below, he says his second law
is "Users have several thousand times more experience with standard
GUI controls than with any individual new design."

Article: Top-10 Application-Design Mistakes
http://www.useit.com/alertbox/application-mistakes.html

What you're telling visitors to your site is that "SOME of the links
on this site are actually buttons, and some of the links are... well,
links. Click the link. If you go to another page, it was indeed a
link. If you don't go to another page, it was in fact a button."

FYI: <button role="link"...>Submit</button> also works in NVDA. It is
possible to make things that look like buttons into links! But I digress.

Just a thought.

-- terrill --

From: Michael.Moore@dars.state.tx.us
Date: Mon, Nov 08 2010 7:54AM
Subject: Re: Form Submit or Button versus link (href) with action
← Previous message | No next message

On Sat, Nov 6, 2010 at 11:32 AM, Susan Grossman wrote:

>  I do wonder  though if there is a way to tell JAWS that the href is acting
> as a button so the "b" will work?

Jared replied

<a role="button" ...>

That will do the trick in ARIA supported screen reader and browser combinations.

Mike Notes,

This is still not a semantically correct option and will cause issues particularly in complex enterprise level web applications. Best practice is to use buttons for things that look like buttons and links for things that look like links. ARIA roles are quite useful but semantic meaning should still be present to allow for graceful degradation.