5 ms·

- tabindex=0 doesn’t affect ordering, does it? - why do you need to listen for events at the document level? not that i disagree with the article, but some ar

- tabindex=0 doesn’t affect ordering, does it? - why do you need to listen for events at the document level? not that i disagree with the article, but some arguments didn’t seem right.

thyristan 11mo ago
> - tabindex=0 doesn’t affect ordering, does it? Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.
- brandonhorst 11mo ago
  This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - thyristan 11mo ago
    That is correct. From your link: "tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source. "
  - Ma8ee 11mo ago
    Your link actually supports the comment you replied to.
- pverheggen 11mo ago
  That's the same behavior as a <button> without tabindex, like the author is proposing. It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
  - thyristan 11mo ago
    > That's the same behavior as a <button> without tabindex, like the author is proposing. Yes, but often you have elements with taborder > 0. > It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order. Only if document order is sane. Usually with modern websites it isn't, document order is a broken notion if you can position elements at will and e.g. put navigation at the bottom of a document but move it to the top by CSS. Which is actually a recommendation that some people make for acessibility... What you usually want to do is assign a sensible taborder > 0 to the one form element that the user is probably currently using. Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
    - pverheggen 11mo ago
      > Yes, but often you have elements with taborder > 0. You can just as easily apply the same tabindex to a div though. > Only if document order is sane. Usually with modern websites it isn't... Well that's the real problem, all your non-interactive content (like text) is going to be out of order too. You're just adding to the confusion if buttons and other inputs are in a different order from the content they're associated with. > Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first. The proper way of dealing with this is a "Skip to Main Content" element: https://webaim.org/techniques/skipnav/ https://webaim.org/techniques/skipnav/
      - thyristan 11mo ago
        > The proper way of dealing with this is a "Skip to Main Content" element: > > https://webaim.org/techniques/skipnav/ https://webaim.org/techniques/skipnav/ No, it isn't the proper way. That only works if you can see the skip link and know to press enter. Otherwise you will tab straight into the navigation. So possibly useful for screen readers, but completely useless for most keyboard users. Yet another stupid webdev workaround for a selfimposed problem. What you should do is autofocus the first form element (if there is a form), give it tabindex=1 and number the other form elements in a sensible ascending tabindex order. Otherwise, proper semantic markup is sufficient, even for screen readers.
- bugsliker 11mo ago
  I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this. See this fiddle https://jsfiddle.net/483uqjnp/ https://jsfiddle.net/483uqjnp/ (again, I do not condone building your own <button>, just pointing this out)
- minitech 11mo ago
  tabindex=0 does sort naturally into the automatic tabindex order. > So you are jumping through all the other tabindex elements This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0. Try it: data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>
cferdinandi 11mo ago
Hey, it's me, the original author! The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot. And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around. "why do you need to listen for events at the document level?" Not events generally, keydown events specifically, which do not fire on child elements of the document.
- pverheggen 11mo ago
  Not sure about that, MDN's example shows keydown being attached to an element. https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event#addeventlistener_keydown_example https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
- susam 11mo ago
  > Not events generally, keydown events specifically, which do not fire on child elements of the document. Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected. https://susam.net/quickqwerty.html https://susam.net/quickqwerty.html https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.html#L299 https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.... Nice article, by the way!
  - skrebbel 11mo ago
    I think that’s because it’s an input and not a div, so it can get focus. Im not sure whether tabindex is enough to make a div do that too, article suggests no
- kyle-rb 11mo ago
  Hi, good premise overall, but there are just a lot of little things that are off. - It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>. - Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused. - "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option. - Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway. - The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.

- tabindex=0 doesn’t affect ordering, does it? - why do you need to listen for events at the document level? not that i disagree with the article, but some arguments didn’t seem right.

thyristan 11mo ago

> - tabindex=0 doesn’t affect ordering, does it? Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.

brandonhorst 11mo ago
This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- thyristan 11mo ago
  That is correct. From your link: "tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source. "
- Ma8ee 11mo ago
  Your link actually supports the comment you replied to.
pverheggen 11mo ago
That's the same behavior as a <button> without tabindex, like the author is proposing. It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
- thyristan 11mo ago
  > That's the same behavior as a <button> without tabindex, like the author is proposing. Yes, but often you have elements with taborder > 0. > It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order. Only if document order is sane. Usually with modern websites it isn't, document order is a broken notion if you can position elements at will and e.g. put navigation at the bottom of a document but move it to the top by CSS. Which is actually a recommendation that some people make for acessibility... What you usually want to do is assign a sensible taborder > 0 to the one form element that the user is probably currently using. Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
  - pverheggen 11mo ago
    > Yes, but often you have elements with taborder > 0. You can just as easily apply the same tabindex to a div though. > Only if document order is sane. Usually with modern websites it isn't... Well that's the real problem, all your non-interactive content (like text) is going to be out of order too. You're just adding to the confusion if buttons and other inputs are in a different order from the content they're associated with. > Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first. The proper way of dealing with this is a "Skip to Main Content" element: https://webaim.org/techniques/skipnav/ https://webaim.org/techniques/skipnav/
    - thyristan 11mo ago
      > The proper way of dealing with this is a "Skip to Main Content" element: > > https://webaim.org/techniques/skipnav/ https://webaim.org/techniques/skipnav/ No, it isn't the proper way. That only works if you can see the skip link and know to press enter. Otherwise you will tab straight into the navigation. So possibly useful for screen readers, but completely useless for most keyboard users. Yet another stupid webdev workaround for a selfimposed problem. What you should do is autofocus the first form element (if there is a form), give it tabindex=1 and number the other form elements in a sensible ascending tabindex order. Otherwise, proper semantic markup is sufficient, even for screen readers.
bugsliker 11mo ago
I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this. See this fiddle https://jsfiddle.net/483uqjnp/ https://jsfiddle.net/483uqjnp/ (again, I do not condone building your own <button>, just pointing this out)
minitech 11mo ago
tabindex=0 does sort naturally into the automatic tabindex order. > So you are jumping through all the other tabindex elements This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0. Try it: data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>

cferdinandi 11mo ago

Hey, it's me, the original author! The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot. And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around. "why do you need to listen for events at the document level?" Not events generally, keydown events specifically, which do not fire on child elements of the document.

pverheggen 11mo ago
Not sure about that, MDN's example shows keydown being attached to an element. https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event#addeventlistener_keydown_example https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
susam 11mo ago
> Not events generally, keydown events specifically, which do not fire on child elements of the document. Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected. https://susam.net/quickqwerty.html https://susam.net/quickqwerty.html https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.html#L299 https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.... Nice article, by the way!
- skrebbel 11mo ago
  I think that’s because it’s an input and not a div, so it can get focus. Im not sure whether tabindex is enough to make a div do that too, article suggests no
kyle-rb 11mo ago
Hi, good premise overall, but there are just a lot of little things that are off. - It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>. - Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused. - "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option. - Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway. - The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.