accessibility and asp:button

JV

This is for anyone who has tackled the accessibility issue on their web site
(and if you haven't, I bet you will in future).

Apparently the asp:button control always renders as '<input type="submit"
....' (a.k.a. submit button) and this can have a big impact on your web
site's keyboard handling. Default IE behavior when you have the keyboard
focus on an edit field is to find the first submit button and trigger a
click event on it (NOTE: Submit buttons behave similarly to a default
button in a Windows GUI application -- often the "Ok" button -- so their
border is drawn darker to indicate that they are the default for that form.
Of course, blind people cannot detect that, but hey...).

Anyway, if you use multiple asp:button controls on your web form, the ENTER
key's behavior may surprise your users. Did you put a LOGIN/LOGOUT button
on all of your pages? Maybe ENTER logs them out instead of clicking the
SUBMIT button you expected it to click.

So, it's probably not a good idea to use the asp:button control more than
once on your form, and then only for the most obvious, sensible default
button.

Has anyone else run into this?

--JV

P.S. Before you freak out, keep in mind this only applies when keyboard
focus is on an edit field. If it is on a button or hyperlink, default
behavior is to click that button or hyperlink.

Nov 19 '05 #1

societopia.net

I ran in similar situation when I was designing the City of North Vancouver
website www.cnv.org

Many of the online forms have different sections, typically: the site search
section and the application section. I used the following JavaScript in
every textbox to associate it with a specific button:

function fnTrapKD(btn){
if (document.all){
if (event.keyCode == 13)
{
event.returnValue=false;
event.cancel = true;
btn.click();
}
}
}

For the site search textbox, I add the attribute:
onkeydown="fnTrapKD(document.all.btnSearch)"

For other textboxes within any form I pass the button ID that would submit
the section, which in turn would cause the postback event to be triggered.

---

www.webswapp.com

www.societopia.net

"JV" <jo**********@goisc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

This is for anyone who has tackled the accessibility issue on their web site (and if you haven't, I bet you will in future).

Apparently the asp:button control always renders as '<input type="submit"
...' (a.k.a. submit button) and this can have a big impact on your web
site's keyboard handling. Default IE behavior when you have the keyboard
focus on an edit field is to find the first submit button and trigger a
click event on it (NOTE: Submit buttons behave similarly to a default
button in a Windows GUI application -- often the "Ok" button -- so their
border is drawn darker to indicate that they are the default for that form. Of course, blind people cannot detect that, but hey...).

Anyway, if you use multiple asp:button controls on your web form, the ENTER key's behavior may surprise your users. Did you put a LOGIN/LOGOUT button
on all of your pages? Maybe ENTER logs them out instead of clicking the
SUBMIT button you expected it to click.

So, it's probably not a good idea to use the asp:button control more than
once on your form, and then only for the most obvious, sensible default
button.

Has anyone else run into this?

--JV

P.S. Before you freak out, keep in mind this only applies when keyboard
focus is on an edit field. If it is on a button or hyperlink, default
behavior is to click that button or hyperlink.

Nov 19 '05 #2

JV

That would certainly work, and I could see doing that on sites with not too
many forms, but on some sites it seems like that could turn into a lot of
extra coding to tie that to every focusable control that is neither button
nor hyperlink.

"societopia.net" <so********@societopia.net> wrote

I ran in similar situation when I was designing the City of North Vancouver
website www.cnv.org

Many of the online forms have different sections, typically: the site
search
section and the application section. I used the following JavaScript in
every textbox to associate it with a specific button:

function fnTrapKD(btn){
if (document.all){
if (event.keyCode == 13)
{
event.returnValue=false;
event.cancel = true;
btn.click();
}
}
}

For the site search textbox, I add the attribute:
onkeydown="fnTrapKD(document.all.btnSearch)"

For other textboxes within any form I pass the button ID that would submit
the section, which in turn would cause the postback event to be triggered.

Nov 19 '05 #3

societopia.net

The function fnTrapKD cost is only 8 lines of code that are shared by the
entire page. Then in each textbox the only additional code is the function
all: onkeydown="fnTrapKD(document.all.btnSearch)"

You can also make a variation of that function for other boxes where you
want the return key to cause the focus to be set to a subsequent textbox
instead of to submit the form.

---

"JV" wrote:

That would certainly work, and I could see doing that on sites with not too
many forms, but on some sites it seems like that could turn into a lot of
extra coding to tie that to every focusable control that is neither button
nor hyperlink.

"societopia.net" <so********@societopia.net> wrote

I ran in similar situation when I was designing the City of North Vancouver
website www.cnv.org

Many of the online forms have different sections, typically: the site
search
section and the application section. I used the following JavaScript in
every textbox to associate it with a specific button:

function fnTrapKD(btn){
if (document.all){
if (event.keyCode == 13)
{
event.returnValue=false;
event.cancel = true;
btn.click();
}
}
}

For the site search textbox, I add the attribute:
onkeydown="fnTrapKD(document.all.btnSearch)"

For other textboxes within any form I pass the button ID that would submit
the section, which in turn would cause the postback event to be triggered.

Nov 19 '05 #4