Question: On my current project, we are debating the usage of replacing input fields (checkboxes, radio buttons, and select dropdowns) with styled choices via javascript. However, it breaks the support of navigating between form input fields via the tab key. I tried searching to see the usage rate of normal users (i.e. not developers) navigating forms via the keyboard, but couldn't find any studies done on it.

I don't like the idea of breaking basic, expected browser functionality, but I would love to see numbers and/or advice on the usage of keyboard navigation with forms.

Answer: 
The usage of keyboard shortcuts is highly dependent on the type of user, their level of expertise, and how they expect an application or website to work. The broad question of "how do all people do this?" doesn't address your real issue, which is "what is the impact of having mouse-only navigation?" 

In general, keyboard-centric usage is most important to users who are highly skilled, either with software in general, or with an application in particular. I've seen plenty of cases where otherwise-novice users were keyboard-centric with a specific application (or even just a specific workflow within an application) because that is how they were taught to do it, and they meticulously follow what they were originally taught. If it's the case of highly skilled users, you have to decide whether the gains that you get in your proposed user experience are worth breaking those users' expectations. This is especially true if these are highly-skilled users who are very important to your product: they might make up a small subset of your users, but they're also the ones who are most likely to be very vocal, and so upsetting them about a basic expected behavior will have a larger impact on your product than just the impact to their user experience in this particular workflow. As you can glean from some of the comments to your question, breaking expectations about keyboard-centric workflows has a major negative impact on how well users trust your application. 

Keyboard-centric usage is also important for accessibility concerns. How does your design impact a user with limited mobility? Even though users who use accessibility affordances might be a small part of your user base, making it difficult or impossible to use your application can have significant consequences, and could even block the adoption of your product if there is a competitor that provides an accessible experience.

In my opinion, there are times when it's not raw data that you want. You could go out and find out how many people will be impacted by making this workflow mouse-only (but not just in a standard usability study, since often even highly-skilled users will default to using the mouse the first time through; being keyboard-centric is about *usage*, not *usability*), but that doesn't give you the whole story. You need to do a careful analysis of your users and determine if a mouse-only workflow brings sufficient benefit to them. If it's a major improvement, then even the most keyboard-centric user will usually be happy because they're able to accomplish their goals quickly and easily. If it's only a minor improvement for most users, but either a minor improvement or a detriment to your highly-skilled users, then you have to consider carefully whether a small win is really worth breaking expectations. Consistency and expectations matter a lot, and a small win might not be sufficient to overcome those.
For me, this is a current issue as my team is unconvinced when it comes to standards like WCAG when using form fields in an application we use on a daily basis. 

More scientific stuff on the UX and productivity improvements of keyboard usage: [Are there any recent studies of the "Keyboard vs Mouse"-issue?](https://ux.stackexchange.com/questions/30682/are-there-any-recent-studies-of-the-keyboard-vs-mouse-issue) (question from 2012)

I took away from this that using keyboard shortcuts or key combinations to navigate a system/application is significantly faster than a mouse when there is no toolbar.