Why does a `click` event get triggered on my when I press Enter on it?












13















I'm only adding a click event handler on my <button>.






document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>





(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?










share|improve this question




















  • 6





    Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

    – Thangadurai
    Jan 7 at 11:09











  • Hehe yeah I got that, left it out for brevity :)

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 15:01











  • @phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

    – Christophe Strobbe
    Jan 7 at 16:19











  • @ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

    – phuclv
    Jan 7 at 16:29
















13















I'm only adding a click event handler on my <button>.






document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>





(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?










share|improve this question




















  • 6





    Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

    – Thangadurai
    Jan 7 at 11:09











  • Hehe yeah I got that, left it out for brevity :)

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 15:01











  • @phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

    – Christophe Strobbe
    Jan 7 at 16:19











  • @ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

    – phuclv
    Jan 7 at 16:29














13












13








13


2






I'm only adding a click event handler on my <button>.






document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>





(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?










share|improve this question
















I'm only adding a click event handler on my <button>.






document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>





(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?






document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>





document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();

console.log("Click:", event);
});

<button>Press <kbd>Enter</kbd> on me</button>






javascript html dom accessibility dom-events






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 8 at 5:26









Nisarg Shah

10.7k52040




10.7k52040










asked Jan 7 at 11:03









VincentVincent

1,31211630




1,31211630








  • 6





    Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

    – Thangadurai
    Jan 7 at 11:09











  • Hehe yeah I got that, left it out for brevity :)

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 15:01











  • @phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

    – Christophe Strobbe
    Jan 7 at 16:19











  • @ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

    – phuclv
    Jan 7 at 16:29














  • 6





    Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

    – Thangadurai
    Jan 7 at 11:09











  • Hehe yeah I got that, left it out for brevity :)

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 15:01











  • @phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

    – Christophe Strobbe
    Jan 7 at 16:19











  • @ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

    – phuclv
    Jan 7 at 16:29








6




6





Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

– Thangadurai
Jan 7 at 11:09





Try pressing the space bar when the button is in focus...another surprise..you clicked the button :-)

– Thangadurai
Jan 7 at 11:09













Hehe yeah I got that, left it out for brevity :)

– Vincent
Jan 7 at 11:11





Hehe yeah I got that, left it out for brevity :)

– Vincent
Jan 7 at 11:11













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
Jan 7 at 15:01





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
Jan 7 at 15:01













@phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

– Christophe Strobbe
Jan 7 at 16:19





@phuclv Blind users do everything using the keyboard. Some types of motor impairments also require keyboard access.

– Christophe Strobbe
Jan 7 at 16:19













@ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

– phuclv
Jan 7 at 16:29





@ChristopheStrobbe blind doesn't only mean a complete vision lost. Many people with low eyesight do use a mouse with magnifier. And not only those, keyboard inputs are used a lot by other users. For example tab to move between form fields, and after filling them people will just press enter to submit instead of pressing the submit button with the mouse

– phuclv
Jan 7 at 16:29












3 Answers
3






active

oldest

votes


















17














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.






share|improve this answer


























  • That's great, thanks for the reference - I will be relying on that for accessibility then!

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 11:47






  • 2





    @brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

    – Quentin
    Jan 7 at 11:51






  • 2





    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
    Jan 7 at 11:55






  • 1





    "This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

    – Ben
    Jan 7 at 17:13



















3














Because for keyboard users (where a 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 browser's accessibility support which most, if not all, browsers provide.






share|improve this answer





















  • 1





    "It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

    – Quentin
    Jan 7 at 11:06











  • @Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

    – Adriani6
    Jan 7 at 11:07











  • 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
    Jan 7 at 11:11











  • @Vincent – The standard was defined after most browsers had already implemented it.

    – Quentin
    Jan 7 at 11:12











  • I see. Well, that's great for me - saves me implementing keypress handlers myself :)

    – Vincent
    Jan 7 at 11:13



















3














This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:




While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.




This is also stated in UIEVents /click section:




In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.




The Activation trigggers paragraph states that:




User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.




Which means that any of those triggers will dispatch the click event.






share|improve this answer


























  • Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

    – Vincent
    Jan 8 at 13:38











  • @Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

    – Adam
    Jan 8 at 14:28













  • Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

    – Vincent
    Jan 8 at 14:39











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
});


}
});














draft saved

draft discarded


















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

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









17














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.






share|improve this answer


























  • That's great, thanks for the reference - I will be relying on that for accessibility then!

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 11:47






  • 2





    @brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

    – Quentin
    Jan 7 at 11:51






  • 2





    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
    Jan 7 at 11:55






  • 1





    "This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

    – Ben
    Jan 7 at 17:13
















17














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.






share|improve this answer


























  • That's great, thanks for the reference - I will be relying on that for accessibility then!

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 11:47






  • 2





    @brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

    – Quentin
    Jan 7 at 11:51






  • 2





    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
    Jan 7 at 11:55






  • 1





    "This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

    – Ben
    Jan 7 at 17:13














17












17








17







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 7 at 11:11

























answered Jan 7 at 11:09









QuentinQuentin

641k718661035




641k718661035













  • That's great, thanks for the reference - I will be relying on that for accessibility then!

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 11:47






  • 2





    @brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

    – Quentin
    Jan 7 at 11:51






  • 2





    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
    Jan 7 at 11:55






  • 1





    "This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

    – Ben
    Jan 7 at 17:13



















  • That's great, thanks for the reference - I will be relying on that for accessibility then!

    – Vincent
    Jan 7 at 11:11











  • 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
    Jan 7 at 11:47






  • 2





    @brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

    – Quentin
    Jan 7 at 11:51






  • 2





    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
    Jan 7 at 11:55






  • 1





    "This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

    – Ben
    Jan 7 at 17:13

















That's great, thanks for the reference - I will be relying on that for accessibility then!

– Vincent
Jan 7 at 11:11





That's great, thanks for the reference - I will be relying on that for accessibility then!

– Vincent
Jan 7 at 11:11













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
Jan 7 at 11:47





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
Jan 7 at 11:47




2




2





@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

– Quentin
Jan 7 at 11:51





@brennanyoung — And make them keyboard accessible with tabindex … best to use elements designed to be interacted with in the first place!

– Quentin
Jan 7 at 11:51




2




2





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
Jan 7 at 11:55





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
Jan 7 at 11:55




1




1





"This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

– Ben
Jan 7 at 17:13





"This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click" No it isn't, it was always like that from the very beginning of Javascript.

– Ben
Jan 7 at 17:13













3














Because for keyboard users (where a 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 browser's accessibility support which most, if not all, browsers provide.






share|improve this answer





















  • 1





    "It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

    – Quentin
    Jan 7 at 11:06











  • @Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

    – Adriani6
    Jan 7 at 11:07











  • 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
    Jan 7 at 11:11











  • @Vincent – The standard was defined after most browsers had already implemented it.

    – Quentin
    Jan 7 at 11:12











  • I see. Well, that's great for me - saves me implementing keypress handlers myself :)

    – Vincent
    Jan 7 at 11:13
















3














Because for keyboard users (where a 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 browser's accessibility support which most, if not all, browsers provide.






share|improve this answer





















  • 1





    "It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

    – Quentin
    Jan 7 at 11:06











  • @Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

    – Adriani6
    Jan 7 at 11:07











  • 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
    Jan 7 at 11:11











  • @Vincent – The standard was defined after most browsers had already implemented it.

    – Quentin
    Jan 7 at 11:12











  • I see. Well, that's great for me - saves me implementing keypress handlers myself :)

    – Vincent
    Jan 7 at 11:13














3












3








3







Because for keyboard users (where a 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 browser's accessibility support which most, if not all, browsers provide.






share|improve this answer















Because for keyboard users (where a 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 browser's accessibility support which most, if not all, browsers provide.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 7 at 17:34









Peter Mortensen

13.5k1984111




13.5k1984111










answered Jan 7 at 11:06









Adriani6Adriani6

4,47321327




4,47321327








  • 1





    "It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

    – Quentin
    Jan 7 at 11:06











  • @Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

    – Adriani6
    Jan 7 at 11:07











  • 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
    Jan 7 at 11:11











  • @Vincent – The standard was defined after most browsers had already implemented it.

    – Quentin
    Jan 7 at 11:12











  • I see. Well, that's great for me - saves me implementing keypress handlers myself :)

    – Vincent
    Jan 7 at 11:13














  • 1





    "It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

    – Quentin
    Jan 7 at 11:06











  • @Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

    – Adriani6
    Jan 7 at 11:07











  • 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
    Jan 7 at 11:11











  • @Vincent – The standard was defined after most browsers had already implemented it.

    – Quentin
    Jan 7 at 11:12











  • I see. Well, that's great for me - saves me implementing keypress handlers myself :)

    – Vincent
    Jan 7 at 11:13








1




1





"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

– Quentin
Jan 7 at 11:06





"It's part of the ISO" — It isn't … and nobody uses ISO HTML anyway.

– Quentin
Jan 7 at 11:06













@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

– Adriani6
Jan 7 at 11:07





@Quentin Removed. You're right, our workplace puts a big importance on the ISO hence the reference.

– Adriani6
Jan 7 at 11:07













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
Jan 7 at 11:11





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
Jan 7 at 11:11













@Vincent – The standard was defined after most browsers had already implemented it.

– Quentin
Jan 7 at 11:12





@Vincent – The standard was defined after most browsers had already implemented it.

– Quentin
Jan 7 at 11:12













I see. Well, that's great for me - saves me implementing keypress handlers myself :)

– Vincent
Jan 7 at 11:13





I see. Well, that's great for me - saves me implementing keypress handlers myself :)

– Vincent
Jan 7 at 11:13











3














This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:




While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.




This is also stated in UIEVents /click section:




In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.




The Activation trigggers paragraph states that:




User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.




Which means that any of those triggers will dispatch the click event.






share|improve this answer


























  • Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

    – Vincent
    Jan 8 at 13:38











  • @Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

    – Adam
    Jan 8 at 14:28













  • Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

    – Vincent
    Jan 8 at 14:39
















3














This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:




While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.




This is also stated in UIEVents /click section:




In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.




The Activation trigggers paragraph states that:




User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.




Which means that any of those triggers will dispatch the click event.






share|improve this answer


























  • Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

    – Vincent
    Jan 8 at 13:38











  • @Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

    – Adam
    Jan 8 at 14:28













  • Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

    – Vincent
    Jan 8 at 14:39














3












3








3







This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:




While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.




This is also stated in UIEVents /click section:




In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.




The Activation trigggers paragraph states that:




User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.




Which means that any of those triggers will dispatch the click event.






share|improve this answer















This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:




While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.




This is also stated in UIEVents /click section:




In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.




The Activation trigggers paragraph states that:




User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.




Which means that any of those triggers will dispatch the click event.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 7 at 17:36









Peter Mortensen

13.5k1984111




13.5k1984111










answered Jan 7 at 15:34









AdamAdam

11.9k1635




11.9k1635













  • Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

    – Vincent
    Jan 8 at 13:38











  • @Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

    – Adam
    Jan 8 at 14:28













  • Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

    – Vincent
    Jan 8 at 14:39



















  • Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

    – Vincent
    Jan 8 at 13:38











  • @Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

    – Adam
    Jan 8 at 14:28













  • Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

    – Vincent
    Jan 8 at 14:39

















Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

– Vincent
Jan 8 at 13:38





Huh, that first excerpt is interesting - in an earlier test, the click event did not get triggered when I bound the listener to an anchor on which I pressed <kbd>Enter</kbd>. See e.g. here: codesandbox.io/s/4r3rl2nrz7?expanddevtools=1

– Vincent
Jan 8 at 13:38













@Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

– Adam
Jan 8 at 14:28







@Vincent In your example, your a anchor lacks an href attribute to make it a link. So the a tag will have no default action.

– Adam
Jan 8 at 14:28















Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

– Vincent
Jan 8 at 14:39





Ah, right. But then that first excerpt is, I think, about something else: clicking a button (or anchor) activates its default behaviour. Whereas the question was not about what happens when you click the button, but about why the click event is triggered when you don't click the button. (Which I think the other two excerpts show.) Anyway, thanks :)

– Vincent
Jan 8 at 14:39


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Can I use Tabulator js library in my java Spring + Thymeleaf project?