Why does a `click` event get triggered on my when I press Enter on it
I'm only adding a click
event handler on my <button>
.
HTML:
<button>Press <kbd>Enter</kbd> on me</button>
Javascript:
document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();
console.log("Click:", event);
});
(Demo link)
Nevertheless, when I tab to the button in Firefox, then press Enter, I see the click
event being fired. However, I cannot see this behaviour documented anywhere. Is this standard behaviour, and can I count on it working in all browsers?
javascript html dom accessibility dom-events
add a comment |
I'm only adding a click
event handler on my <button>
.
HTML:
<button>Press <kbd>Enter</kbd> on me</button>
Javascript:
document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();
console.log("Click:", event);
});
(Demo link)
Nevertheless, when I tab to the button in Firefox, then press Enter, I see the click
event being fired. However, I cannot see this behaviour documented anywhere. Is this standard behaviour, and can I count on it working in all browsers?
javascript html dom accessibility dom-events
1
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago
add a comment |
I'm only adding a click
event handler on my <button>
.
HTML:
<button>Press <kbd>Enter</kbd> on me</button>
Javascript:
document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();
console.log("Click:", event);
});
(Demo link)
Nevertheless, when I tab to the button in Firefox, then press Enter, I see the click
event being fired. However, I cannot see this behaviour documented anywhere. Is this standard behaviour, and can I count on it working in all browsers?
javascript html dom accessibility dom-events
I'm only adding a click
event handler on my <button>
.
HTML:
<button>Press <kbd>Enter</kbd> on me</button>
Javascript:
document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();
console.log("Click:", event);
});
(Demo link)
Nevertheless, when I tab to the button in Firefox, then press Enter, I see the click
event being fired. However, I cannot see this behaviour documented anywhere. Is this standard behaviour, and can I count on it working in all browsers?
javascript html dom accessibility dom-events
javascript html dom accessibility dom-events
asked 4 hours ago
Vincent
1,26211628
1,26211628
1
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago
add a comment |
1
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago
1
1
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago
add a comment |
2 Answers
2
active
oldest
votes
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
Quite right. You get a lot of accessibility 'for free' with<a>
,<input>
and<button>
, but otherwisetabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.
– brennanyoung
3 hours ago
I switched from an<a>
to a<button>
for exactly this reason - to make sure I get the browser's a11y features for free. Withtabindex
,role
andclick
andkeydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)
– Vincent
3 hours ago
add a comment |
Because for keyboard users (where mouse is not available), when a button is in focus and you press enter (possibly space as well) it simulates a click event.
This is the browsers accessibility support which most if not all browsers provide.
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54073140%2fwhy-does-a-click-event-get-triggered-on-my-button-when-i-press-enter-on-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
Quite right. You get a lot of accessibility 'for free' with<a>
,<input>
and<button>
, but otherwisetabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.
– brennanyoung
3 hours ago
I switched from an<a>
to a<button>
for exactly this reason - to make sure I get the browser's a11y features for free. Withtabindex
,role
andclick
andkeydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)
– Vincent
3 hours ago
add a comment |
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
Quite right. You get a lot of accessibility 'for free' with<a>
,<input>
and<button>
, but otherwisetabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.
– brennanyoung
3 hours ago
I switched from an<a>
to a<button>
for exactly this reason - to make sure I get the browser's a11y features for free. Withtabindex
,role
andclick
andkeydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)
– Vincent
3 hours ago
add a comment |
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
edited 4 hours ago
answered 4 hours ago
Quentin
640k718611032
640k718611032
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
Quite right. You get a lot of accessibility 'for free' with<a>
,<input>
and<button>
, but otherwisetabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.
– brennanyoung
3 hours ago
I switched from an<a>
to a<button>
for exactly this reason - to make sure I get the browser's a11y features for free. Withtabindex
,role
andclick
andkeydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)
– Vincent
3 hours ago
add a comment |
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
Quite right. You get a lot of accessibility 'for free' with<a>
,<input>
and<button>
, but otherwisetabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.
– brennanyoung
3 hours ago
I switched from an<a>
to a<button>
for exactly this reason - to make sure I get the browser's a11y features for free. Withtabindex
,role
andclick
andkeydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)
– Vincent
3 hours ago
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
That's great, thanks for the reference - I will be relying on that for accessibility then!
– Vincent
4 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
It's a very useful mechanism. If you plan to rely on it for accessibility, the caveat is that most elements do not have this default behaviour, so if you're using (say) a div or a span as a control, you'll have to add the key event handling yourself. (Be sure to add a role attribute too!)
– brennanyoung
3 hours ago
1
1
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!
– Quentin
3 hours ago
1
1
Quite right. You get a lot of accessibility 'for free' with
<a>
, <input>
and <button>
, but otherwise tabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.– brennanyoung
3 hours ago
Quite right. You get a lot of accessibility 'for free' with
<a>
, <input>
and <button>
, but otherwise tabindex
is just as important. Unfortunately, a11y implementation is far too rarely considered 'in the first place'.– brennanyoung
3 hours ago
I switched from an
<a>
to a <button>
for exactly this reason - to make sure I get the browser's a11y features for free. With tabindex
, role
and click
and keydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)– Vincent
3 hours ago
I switched from an
<a>
to a <button>
for exactly this reason - to make sure I get the browser's a11y features for free. With tabindex
, role
and click
and keydown
event handlers, I'm sure I'd probably still have forgotten something, or would implement something incorrectly :)– Vincent
3 hours ago
add a comment |
Because for keyboard users (where mouse is not available), when a button is in focus and you press enter (possibly space as well) it simulates a click event.
This is the browsers accessibility support which most if not all browsers provide.
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
add a comment |
Because for keyboard users (where mouse is not available), when a button is in focus and you press enter (possibly space as well) it simulates a click event.
This is the browsers accessibility support which most if not all browsers provide.
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
add a comment |
Because for keyboard users (where mouse is not available), when a button is in focus and you press enter (possibly space as well) it simulates a click event.
This is the browsers accessibility support which most if not all browsers provide.
Because for keyboard users (where mouse is not available), when a button is in focus and you press enter (possibly space as well) it simulates a click event.
This is the browsers accessibility support which most if not all browsers provide.
edited 4 hours ago
answered 4 hours ago
Adriani6
4,34421327
4,34421327
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
add a comment |
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
1
1
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.
– Quentin
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.
– Adriani6
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
Ah sorry, I did not mean "why did they make it this way", but "why did browsers implement this - was it because it was standardised, or because they thought it was a good idea themselves". Apparently the former!
– Vincent
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
@Vincent – The standard was defined after most browsers had already implemented it.
– Quentin
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
I see. Well, that's great for me - saves me implementing keypress handlers myself :)
– Vincent
4 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54073140%2fwhy-does-a-click-event-get-triggered-on-my-button-when-i-press-enter-on-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)
– Thangadurai
4 hours ago
Hehe yeah I got that, left it out for brevity :)
– Vincent
4 hours ago
keyboard geeks don't often use the mouse. Many even use vi-like addons to their browsers so that they can surf the web without ever touching their mouse. It's very frustrated when an app don't respond to keyboard events
– phuclv
26 mins ago