<h1>Why you shouldn't force order with <code>tabindex</code>...</h1>
<p>Synopsis: it seems that <code>tabindex</code> only influences tab cycle in desktop browsers (where focus goes using <kbd>TAB</kbd> / <kbd>SHIFT+TAB</kbd>) and (for mobile/touchscreen devices) previous/next on the on-screen keyboard when interacting with form controls. In all other cases/ways in which AT users can navigate content - using standard reading keys, reading gestures (swipe left/right on a touchscreen), specific quick navigation shortcuts (e.g. <kbd>F</kbd> / <kbd>SHIFT+F</kbd> to jump to next/previous form field, swipe up/down when VoiceOver rotor is set to form elements) and dialogs (e.g. <kbd>JAWS KEY + F5</kbd> to see a list of form fields) <code>tabindex</code> is simply ignored...the only order that matters here is DOM/source order.</p>
<p>While the practice of using <code>tabindex</code> (with a value greater than <code>0</code>) to "fix"/determine the focus order of focusable elements (usually form controls) has seen a steady decline (possibly relating to the decline of <code>&lt;table&gt;</code> based layouts), it is still worth mentioning why it's simply a bad idea.</p>
<p>It is true that, for keyboard users who <kbd>TAB</kbd> / <kbd>SHIFT+TAB</kbd> between form controls, <code>tabindex</code> will force a particular order. However, in the more specific case of screen reader users, note that <code>tabindex</code> does <strong>not</strong> influence the order in which these elements are being sequentially encountered when the user is navigating with standard reading keys. Reading keys will simply follow the order in which elements are in the DOM. So, despite possibly well-meaning use of <code>tabindex</code>, there is no guarantee that a user will in fact land on the element with the lowest <code>tabindex</code> value and then <kbd>TAB</kbd> to all subsequent ones in the forced focus order.</p>
<p>In the following (admittedly contrived) example we have three form fields. In the DOM, the order of these fields is "First Name", "Title", "Last Name" - but we're using CSS to reorder the fields vertically, and <code>tabindex</code> to try and ensure that the focus order matches the visual order, "Title", "First Name", "Last Name".</p>
<fieldset>
  <div id="f2"><label for="firstname">First name</label>
  <input type="text" name="firstname" id="firstname" tabindex="2">
  </div>
  <div id="f1"><label for="title">Title</label>
  <input type="text" name="title" id="title" tabindex="1">
  </div>
  <div id="f3"><label for="lastname">Last name</label>
  <input type="text" name="lastname" id="lastname" tabindex="3">        
  </div>
</fieldset>
<p>If we simply navigate using <kbd>TAB</kbd>, the form appears to work correctly. However, if we try navigating this form with a screen reader's reading keys, we find that, as expected, "First Name" will be encountered first. If we now carry on through the form using reading keys, we will come across all other form controls, in DOM order, meaning that the forced order we tried to impose using <code>tabindex</code> is completely ignored.<p>
<p>Note that this also applies when using specific navigation keys to move between specific page elements – for instance, when using <kbd>F</kbd> / <kbd>SHIFT+F</kbd> in JAWS and NVDA to only navigate between form controls, we find that <code>tabindex</code> is ignored, and the fields are sequentially navigated based purely on DOM order. Lastly, the problem also holds true for screen reader specific dialogs that list all elements of a particular type in the current page (such as <kbd>JAWS KEY + F5</kbd> to list all form fields) - once again, the form controls will be listed in DOM order, regardless of <code>tabindex</code>.</p>
<p>Once screen reader users find themselves in a form control, they <strong>may</strong> proceed through the rest of the form using <kbd>TAB</kbd> / <kbd>SHIFT+TAB</kbd>. However, they won't be starting from whatever we tried to define as the first item (with the lowest <code>tabindex</code>), but they'll simply start from the first control they encountered, potentially missing out any of the form controls with a lower <code>tabindex</code>).</p>
<p>Note that this problem is not simply limited to "keyboard" users. The same issue arises for screen reader users on touchscreen devices. By default, the standard way of navigating with a touch/AT is by using left/right swipe gestures, which are the equivalent of desktop AT's reading keys. Once again, the first form field a screen reader user on a touch device will encounter is the "First Name" control.</p>
<p>Similar to traditional keyboard-controlled screen readers, When switching the screen reader to only navigate between specific elements (e.g. in iOS/VoiceOver, using the rotor, setting navigation to form controls), the order in which these elements are then navigated matches the DOM order, regardless of any <code>tabindex</code>.</p>
<p>Of course, once touchscreen users interact with the first form control they encountered, they will - depending on their OS - usually have controls to navigate to the previous and next form control as part of their on-screen keyboard. But once again, they will only be starting from the first form control they encountered in the DOM order, potentially missing any form controls with a lower <code>tabindex</code>.</p>
<p>In short...don't use <code>tabindex</code> to force a particular focus order. It may work for keyboard users, but will still fail for screen reader users navigating with reading keys / gestures.</p>