Why do major sites give tabindex priority to auxiliary functionality rather than the primary action button?

Question

In Twitter's web app, after the tweet body in Compose Tweet, the next tabindex is the Add emoji button. However the primary action is the Tweet button.

In GitHub's web app, after the comment body in Leave a Comment on a Pull Request, the next tabindex is the Select a File to Upload link. However the primary action is the Comment button (which had tabindex priority for years, and was only changed recently).

A GitHub support agent told me that it is to do with accessibility.

What is the accessibility best practice on tabindex here? (I am surprised that GitHub and Twitter don't have a solution that is both good for accessibility but still allows the next tabindex to be the primary action)

Answer 1

Tab index is not necessarily meant to point to the next "priority" element that a typical user would think it should. That is because tab index is not really meant for the typical user, it is meant for visually impaired users using screen readers and keyboard navigation.

Tab index is meant to lead you through elements in the same order you would see them laid out visually on page (i.e. top-to-bottom left-to-right atleast in LTR cultures) regardless of priority. It has to be able to reach every element, whether it is priority or not.

I am not familiar with the forms for either mentioned site, but imagine if you could not see the screen and were relying on tabbing to guide you through. If it jumped you from the "Compose Tweet" to the "Tweet" button skipping over the emoji section you would have no idea that feature existed. Or worse, you know it exists but have no way to access it. This leads to unhappy users as well as a non-ADA compliant website.

Answer 2

@dasbeasto is heading in the right direction. Tabindex isn't necessarily about the tab order but rather about access to all the interactive elements on the page. If you are going to use tabindex, please only use the values 0 and -1. Anything other than that could actually break accessibility.

WCAG 2.1.1 talks about keyboard access.

If you are designing your own button or checkbox or some other interactive object and you are implementing it with <div> or <span> tags along with CSS and are not using <button> or <input type=checkbox>, then you must use tabindex so that the keyboard user (whether that's an assistive technology user or a mobility-impaired user or just power user) can navigate to your object using the keyboard.

I can explain the difference between the values 0 and -1 offline or you can find discussion of it on stackoverflow.com but it's not pertinent to this forum.

In the specific case of twitter, I just looked at it in firefox with the NVDA screen reader and it's actually quite terrible. It fails accessibility. The emoji button is a real <button> but they've added aria-hidden=true which means they are intentionally hiding that button from visually impaired users. aria-hidden does not prevent you from tabbing to the object but it causes the text to be read as 'blank' as if there's nothing there.