How to direct tabindex across multiple Phoenix live components

I am having issues with tabbing through a form that has embedded live_components. It looks like this:



  LIVE_COMPONENT 2 (inside Component 1):
  Text Input Field 1 (tabindex 1)
  Text Input Field 2 (tabindex 2)

Button in LIVE COMPONENT 1 (tabindex 3)

Text Input Field 3 in LIVEVIEW (tabindex 4)
Text Input Field 4 in LIVEVIEW (tabindex 5)

The tabindex numbers show how I want the tab button to flow within the form. I want it to flow from Text Input Field 1 to Text Input Field 2 to the Button in Live Component 1.

Unfortunately, after Text Input Field 2 (tabindex 2) … it jumps to Text Input Field 3 (tabindex 4) inside the Liveview. It bypasses the button in Live Component 1 altogether. Arg!

Is there a way to program a phx-keydown event for the tab key so that it forces it to go to the button and not to the next input field? I’ve been trying to find examples of how to force a tabindex across live components but I haven’t been able to find anything. Anyone else run into this issue?

From MDN, tabindex - HTML: HyperText Markup Language | MDN, the recommendation seems to be to not set tab indexes greater than 0, rather let the browser determine the order from the document source structure. Your specific problem is caused by the browser setting tabindex of 0 on buttons, regardless of the positive number you give it.

  • Warning: You are recommended to only use 0 and -1 as tabindex values. Avoid using tabindex values greater than 0 and CSS properties that can change the order of focusable HTML elements (Ordering flex items). Doing so makes it difficult for people who rely on using keyboard for navigation or assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.

Some focusable HTML elements have a default tabindex value of 0 set under the hood by the user agent. These elements are an <a> or <area> with href attribute, <button>, <frame> Deprecated, <iframe>, <input>, <object>, <select>, <textarea>, and SVG <a> element, or a <summary> element that provides summary for a <details> element. Developers shouldn’t add the tabindex attribute to these elements unless it changes the default behavior (for example, including a negative value will remove the element from the focus navigation order).

The browser doesn’t care if some elements come from another live view, it just looks at the structure of the final markup. Try removing all tab indexes and see how the order behaves, then change your structure accordingly.

1 Like