Improving on Tap targets are not sized appropriately

[kaihendry]

Hi there, large tap targets helps to abide by Fitt's law in terms of making the Web app actually usable, especially on mobile. Perhaps I am wrong with the Fitt's law association, though if I am right, it would be good if the law was referenced upon https://web.dev/tap-targets/ so that people are aware that there is some study behind it.

Lately I've been wishing for better tooling to greater automate Fitt's law and maybe other UX gotchas, by for example, quantitatively measuring (scoring) how difficult (or easy?) a form is to fill out. Lets take an example: https://email.thealaskaguys.com/

1. A form with five fields
2. Two are required fields
3. One (required) field requires 6 digits
4. One field should be auto populated ("server side")

Could these computed properties be used as scoring rules?

Tbh I'm most concerned when users (my elderly parents come to mind) require fine motor skills (which they don't have), to just focus on the form to fill in. E.g. making sure Labels work.
Never mind the horrors of hover menus / accordions / modals and other UX anti-patterns.

Maybe Lighthouse is a good platform to create such rules, maybe it isn't. Either way, I hope you can share my interest in highlighting such UX antipatterns via automated tooling and point out any work in the area.

[patrickhulce]

Thanks for taking your thoughts down here @kaihendry! I like this concept a lot for quantifying UX in a methodical way. I think the trickiest part here is coming up with the expected flow of the form and scoring arbitrarily sized forms in a consistent way. There's no real way of knowing if the information the form is prompting is unnecessary and can be derived (example, just asking for postal code to derive city/state is a much nicer UX but three unrelated fields shouldn't be penalized if they're all necessary information).

For the flow part, a simple elements.sort((elA, elB) => (elA.top - elB.top) || (elA.left - elB.left)) might work? Determining where to start I suppose is relying on the <form> boundary itself.