Ask HN: Why do web sites not place the cursor for input? | Hacker News Reader

Ask HN: Why do web sites not place the cursor for input?

80 pointsbackendanon94 comments

To their credit, Microsoft puts the cursor in the text field ready for me to type in my authenticator code. Most web sites I've found, do not. So I look up with my shiny new code, ready to start typing, realize I need to move my hand to the mouse, place the cursor into the field then there's a 50% change I've forgotten the code and have to look back at my phone.

View on HN

A lot (the majority?) of web developers know their framework and how to script things but don't know that HTML has been able to do things like this out of the box for over a decade. Even IE 10 supported it. So much simpler and more reliable than using JavaScript.

    <input name="foo" type="text" autofocus>

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

This is why I moved away from web frameworks. I could feel them making me incapable of solving really simple problems like this.

Autofocus & tab order are a nightmare-tier mission if you absolutely have to get them right but find yourself trapped inside some dynamic DOM circus.

As far as I am aware, whatever magic is happening inside the browser's HTML engine is infinitely more reliable and predictable than what any JS framework could provide on top. JS certainly won't be making it faster or more responsive.

I have this battle with newer developers quite frequently. They immediately want to reach for a framework for everything and they try to abstract away as much html and css as possible.

A common experience has been with new grads who have a lot of experience with tailwind. They're used to being able to just apply a tailwind class for everything. However, I find they often lack the understanding of what is actually going on at a css-level so are unable to easily do anything that breaks the tailwind mold. I often have them sit down with a more senior developer to watch them use raw css (with some developer ergonomics like styled components or sass) for a bit, and they come away with a new appreciation for how the fundamental languages of the (modern) browser are quite expressive and powerful.

I remember a front-end interview my coworker administered where the candidate was asked what a CSS rule and CSS selector were, and the candidate could not answer. They had no idea what those terms meant. I think they'd only ever used React styled components.

“React-styled components”?

What do you mean by this? You still use CSS rules and selectors to style React components.

Also, maybe your coworker should up their interview game. Instead of asking “define this term” questions, maybe they should ask candidates to actually demonstrate skill.

(Also, it’s a bit weird to tell a “story” like this that happened to your coworker. Were you guys making fun of the candidate afterwards or something? I think we learned more about you and your coworker than about the candidate from your anecdote.)

Styled Components is a library for React that moves CSS styles into the JS code. Depending on how junior the interviewee was, and what tech they were primarily working with, it's possible they never encountered those terms even as they contributed to the code.

Or maybe they just pitched themselves as "full stack" when they were really more back end focused. Doesn't seem that far-fetched to me.

> Styled Components is a library for React that moves CSS styles into the JS code.

Thanks, I see.

> Doesn't seem that far-fetched to me.

The veracity of GP’s comment wasn’t my main concern.

I’m disappointed you’d assume the most toxic interpretation possible there. My coworker came to me and was just curious if the question, which was new, was reasonable - having seen it received so much confusion.

Sure.

The problem here is that the requirement of one tiny little feature on top of a browser's HTML engine might force you to implement a DOM circus from scratch, simply because you can't change the browser's code. Should that feature then be left unimplemented? That's not for you or me to decide. Also: it might not be known beforehand what features will be added later, so it makes sense to use a framework because at least you will be able to extend it.

> Should that feature then be left unimplemented? That's not for you or me to decide

I feel like this shuts down a really important part of the conversation. Why does there exist zero feedback between technology owner and business/user expectations?

Great, now disable it on mobile where opening the on-scree keyboard is jarring.

There is nothing about the dominant web frameworks that prevents one from implementing semantically correct HTML.

Prevent? No. Discourages? All the time.

Can you give an example?

/me gestures emphatically at the entire "HTML & CSS in JS" paradigm.

When you elevate JS above the others, you deprioritize those others in practice. Advanced knowledge of HTML among React developers is a surprisingly rare talent. Whereas Node developers gobbled up (and choked on) left-pad due to incomplete knowledge of JS, far too many (a majority of?) web framework developers reach for packaged components without realizing it was a standard tag with two lines of CSS away.

Accordion: <detail> + <summary>

Button (as a link): <a href> with inline-block, background-color, and other basic CSS

Card: <article> with border-radius and box-shadow

…pretty sure I could do most of the English alphabet in examples.

JS could be used for progressive enhancement—animating the accordion, for example—but almost all accordions I've seen were the typical spaghetti of div tags, chunky event handlers, and accessibility lipstick of aria-roles. But most React devs see some library's Accordion object and think it's normal to see the dark <div> forest in the inspector.

Gotcha; JSX, by colocating related JS and HTML, tempts inexperienced developers to write JS hacks for behaviors already available natively in HTML and CSS.

I think that is a fine tradeoff when the alternative is an arbitrary separation of technologies, a web of querySelectors, imperative DOM manipulation, and walls of incoherent stylesheets.

False dilemma. Try Svelte.

Vue and similar don't have this issue. When used in the most basic way it's just HTML with templating commands. What you see in the inspect window is what you typed, maybe duplicated with a for, or removed with an if.

I agree that Vue is much better than React in this regard. Svelte and HTMx are both steps up from Vue in my opinion.

It's never about a framework, it's always about the programmer. Hacker news is full of complaints about (React) frameworks and how they are the worst and using them makes your web the worst, but in reality almost nobody makes the effort to make the best possible one. It's simply not the frameworks' fault. Current JS framework from adding the 'autofocus' attribute to your inputs.

I don't see how autofocus and tab order are made any worse by a web framework.

What's the connection?

An example from personal experience:

When I was really young, I wanted to figure out web programming. I knew C#, so when I came across a book on making websites in C# with ASP.NET, it was a no-brainer.

I the slogged through 2000+ pages on how to handle connection state, WYSIWYG web forms generation with drag and drop component, etc. The experience was horrible, and turned me off to web programming.

A brief aside, for those unfamiliar: ASP.NET presents the programmer with a (leaky) abstraction over HTTP and HTML, pretending that the protocols involved are stateful, whereas the reality is that HTTP is stateless. This creates all sorts of new ASP.NET specific problems, which are then addressed by jumping through hoops to ensure control state is (de)serialized just right, etc. Thus the 2000+ page count.

Later on I discovered ASP.NET MVC, which did away the the “let’s pretend HTTP is stateful”, and takes an approach much like just about any other web framework out there. You’re expected to know HTML, CSS and HTTP. I was like “oh, is this it? I just learn some HTML, register some request handlers, and generate some HTML?”. Until then, my focus was on getting something working, and I trusted that what they covered would get me up and running. That line of reasoning failed me with ASP.NET, as the book set me up to ignore the underlying (and ironically, much simpler) machinery of the web.

I’m positive ASP.NET isn’t the only framework guilty of distracting developers from learning the fundamentals. And think about it: when’s the last time you’ve seen HTTP or HTML listed as required proficiencies in a job description? I can’t remember. What I do see is an expectation to know all the intricacies of React, Babel, Grunt, Redux, whatever. If you’re trying to land your first job, or working on climbing the ladder, it’s easy to fall into the trap of investing all your time in finding your way around the accidental complexity of the frameworks you intend to make your living from using, and underestimate the value of understanding what’s going on in the layers beneath the abstractions.

ASP.NET 4.x and below Session State and WebForms made sense when, at the time, the goal was to make desktop applications on the web.

Now that no one knows what a desktop application is, we no longer need Session State like functionality.

That is the whole reason that made me stop using them.

Frameworks make you lose capability to write anything outside of them, locking you inside it's own Ecosystem and making you unable to write a single line of code outside of it.

Try Svelte. It's quite easy to use most vanilla JS libraries and techniques with it.

https://hackmd.io/@roguegpu/r1RKQMdt3

The ChartJS section is a good example. You're following the ChartJS tutorials to use it, not just some bespoke framework wrapper around it.

more than two decades. I was setting my websites at work up to do this in 2001.

it's amazing how many web developer don't know what browsers are capable of, and only consider what features the framework they're using has.

Autofocus works only on page load and not when the input is injected later by JS.

So why not have the input be there on page load?

Because when you do reactive web pages, they are not necessarly here on page load.

I made a JS file explorer, to see files on the server from the browser.

I wanted to mimic the windows explorer breadcrumb path bar. If you look at the behavior of the breadcrumb pathbar, you can't do that on page load, you have to replace the breadcrumb by an input text on clic, so not at page load.

Yes theroically, you can fetch a whole new page for that, but it would imply fetching a new page from the server just for this: it doesn't make sense.

I honestly don't know. But I believe one big reason why my SEO game seems always a bit better than others is because I learned and still practice to build websites user friendly.

This starts by using the right tags for things (articles, section, header, ...) over autofocus, alt and title tags and even rel attributes. No magical js page builds. All my websites are screen reader friendly by default.

Yep, 100%. Using HTML as it was intended helps with SEO, accessibility, readability, semantic understanding, etc. It's got it all out of the box.

Folks just seem to go out of their way to make things harder by focusing on the JS layers and frameworks above it all. Converting everything to a sea of divs that you have to go back it to style, add ARIA roles and labels, and make keyboard-accessible.

It's all like enriched white bread: stripping out everything healthy, adding a bucket of preservatives, supplement with a few of the vitamins and minerals they leached out earlier, and market its insubstantial tastelessness like it's normal.

(From https://github.com/sveltejs/svelte/issues/6629#issuecomment-...) "The reason why autofocus should be generally avoided, is that it's messing up the focus order for screenreaders and similar assistive technologies. Additionally, logical "focus order" is also a success criterion on the official WCAG 2.0 accessibility guidelines by the W3C." https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechan...

I've always wondered, couldn't screenreaders and similar just disable autofocus? I can't imagine a scenario where a site would break by disabling it, all I can think of is they don't have that much control over the browser, which seems even more insane...

Right? Why all these accessibility tags and features if we have to outright disable meaningful features for the other 95% of users?

We can have both!

Along similar lines, the only scenario I've found where auto-focus on input can be obnoxious is with mobile devices. Causing the virtual keyboard to appear by default can make the display scroll and shift unexpectedly, reducing accessibility (if unexpected, of course).

I hadn't thought about assistive technologies in general, so this is useful to consider.

I am still annoyed by iOS apps like IMDB where you tap the “search” icon, it goes to the search screen but the search field does not have focus. You still have to tap the input. Perhaps that’s because you would not see more promos that they put on the search screen? It’s a user hostile UI but I guess that should not surprise me with IMDB.

I believe this is one of those don't attribute to malice what you can attribute to incompetence type deals.

Many websites and apps (don’t) do this.

In the case of an "input your authentication code" page, I'm pretty skeptical that accessibility is a good reason to not focus the only part of the page that a user probably wants to interact with. The screen reader is going to clearly announce something like "input, authentication code" assuming the dev has labeled the input correctly. I'm just having trouble imagining why autofocusing the only input on a page that matters would somehow make the experience worse for specifically users of screen readers.

This is ass-backwards. Screenreaders should handle autofocus properly or ignore it, not force the other 90% into (even deeper) insanity.

Just ignore the standard and do what’s best for the users.

This might get you into a lawsuit if wcag is't followed. Or at least that's what the legal and accessibility team will think.

Agree - wis there no additional layer of abstraction between autofocus and screen readers? Why is there such a dependency on this unrelated functionality? I’m inclined to see this is a failure of screen readers, and perhaps more broadly the standards on which they are based if they can’t handle what is a reasonable and common use case for normal web browsing.

Yeah I'm all for helping 5% of the population, but not at the expense of the other 95%

Sounds opinionated. Why not offer a choice?

I get that, but dedicated 2fa pages should default into the text input. A few big sites don't do this.

You can absolutely implement autofocus which conforms to WCAG. In OP's example, you can imagine the authenticator code input being shown in a modal, and from your link, example 3 of correctly implementing focus order:

> A Web page implements modal dialogs via scripting. When the trigger button is activated, a dialog opens and focus is set to the first interactive element in the dialog.

That perhaps was an issue 20 years ago but not for modern tools. A lot of accessibility guidelines are just cargo culting since so few disabled users have any say in how they are drafted.

So that's why the only input field when you start a web browser ( the address bar) has no input focus. For accessibility. /s

Cynically, I feel like these details are often lost in the two-week sprint cycle or other realities of modern software development process. The Figma file didn't specify autofocus, the PM doesn't care about it, and the engineer just wants to close their ticket so they can move on to the next one. It's a login page, who cares? What revenue or business metric does it drive? Same reason the input field for the code doesn't have its input mode set to numeric (to show a numeric keyboard on mobile devices), and the same reason the email field doesn't have the email input mode set (to show the email input keyboard with @ and . prominently featured).

> these details are often lost in the two-week sprint cycle or other realities of modern software development process

Indeed. This is why we should abandon the "modern" software development process. Bureaucracy & consulting appears to be producing shit software. By whatever means necessary, the developer needs to be made to care more about the quality of the final product.

Making "UI/UX" a label, project category or other management abstraction is a gigantic red flag to me. This tells me it is everyone's job, therefore it is effectively no one's job. Someone needs to take deep ownership in things that end in "experience" or it won't work.

You'd be amazed at what others around you will start stepping up to if you set even the tiniest example. Certainly, there are those who will do bad work on purpose, but you won't change those. All you can do is your best and let HR take care of the rest.

The root of all of these is: nobody really cares. The PM is just trying to cram features X, Y, and Z in before the sprint ends so that metrics A, B, and C can go up. The engineer (as you said) just wants to close tickets and implements whatever is in the ticket, regardless of whether it's the right way. QA probably caught this, but the ticket was prioritized as a P3 and buried with the other 459 P3 bugs that nobody is ever going to look at. The senior exec doesn't even know what autofocus is and just wants the $ chart to go up rather than down. He's really the only one on the totem pole with any power to say "Wait, stop, this isn't right--it isn't beautiful, it isn't complete, and the little details matter." But he won't because he is a businessman, not a craftsman.

Another post in two weeks that reminds me of that S.Jobs quote I lean on a lot: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

Nobody seems to care about the aesthetic or quality anymore. Software development has become a beige, boring assembly line where brains go in as input and "Metrics Go Up" comes out the other end of the factory.

I care, and where I work (as a coder) what I care about does matter. Or I make it matter.

You sound depressed. Maybe try find a smaller shop where you have more influence?

It's the same reason why links are not a tags. The dashboard of my company is a React app, but it has proper routing so opening a new tab at mycompany.com/account goes to your account.

At the end of last year the menu was redesigned, and the links which were a tags were replaced with some other element. So now you can't ctrl click to open pages in new tabs, which was a big part of my workflow.

Oh and the labels on the design of the new menu were removed, but of course there is no title tag to explain what the items are.

I filed a bug report shortly after it was released, and it is - and probably for the rest of eternity will be - in the backlog.

What bugs me most in these stories is that they are actively destroying what worked before. Barbarians with big frameworks. Their company pays them while they make the product worse and nobody notices. Even with user feedback, because instead of going to a solver, it goes to the problem itself.

> So now you can't ctrl click to open pages in new tabs, which was a big part of my workflow.

I came across the exact opposite recently. With Ghostery enabled, one of the company owned websites won’t work with regular clicks. The only way to go to the link is to open in a new tab/window. Infuriating.

I can get over that, but I've used a couple of websites where hitting enter in the code box doesn't submit the code and log you in - that is unforgivable.

Similarly, disabling pasting a copied code.

Also the sites that autosubmit once you’ve typed 6 characters, and worse still the sites that require you to login again from scratch if you typo the last character and it autosubmits

Blowing away the form on submission is the worst sin if form design. Only blow it away if it was accepted!

I wonder if this is a deliberate (legal) submission reduction technique.

Probably closer to the PM didn't specify, the PO had a deadline, the Scrum Master wanted a lower estimate, the devs don't want to argue, and QA followed the acceptance criteria and didn't want to be seen as an impediment, especially since the devs had already surrendered.

I love the auto submit on auth codes

There's this one page that disables the login submit button until the password field is filled. The browser auto-fills, login still disabled. Need to manually add and then remove a character before the form can be submitted.

Principle of Least Astonishment

"In user interface design and software design,[1] the principle of least astonishment (POLA), also known as principle of least surprise,[a] proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users."

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Such a feature would negatively affect accessibility, without some sort of accessible clue about where the cursor was moved.

It's perfectly possible to have sufficient a11y tags indicating where the cursor is: if anything, this would help accessibility, and a page which is solely there to accept OTP code being focused on the input field would not be at all surprising.

Even without any a11y hint other than a field label, a11y tools and users would probably appreciate it just like regular user would: imagine a screen reader having to go through 20 menu items to get to the OTP code entry field.

    <input name="foo" type="text" autofocus>

HTML takes care of the accessibility for you in this case. Going further, plain HTML is by and large 99.9% accessible. As developers—as uncomfortable as it may be to hear—we take a 99.9% accessible markup foundation and BREAK that accessibility with our CSS and JS choices, then run through hoops patching accessibility back in again with a hodgepodge of aria-role attributes and scripting hacks.

Folks really don't get how much work went into plain old disrespected HTML. We just keep putting that fake brick wallpaper over real brick walls.

How does that take care of the accessibility issue?

Screen readers et al know standard HTML, especially when the features in question are more than a decade old. Dynamic event handling in JS that eventually sets focus are a demonstrably less reliable option.

Just because there's a named principle with its own wikipedia page doesn't mean many web devs aren't just lazy slackers and either didn't notice the usability problem, didn't care enough to change it, or just didn't know how and didn't care enough to figure it out.

Similar vein, there’s a special place In hell for web / iOS developers who don’t flag input fields correctly to allow autofill / password managers to work. I see it in a lot of crappy legacy iOS apps.

This is also an issue in Android and desktop browsers. I've also seen some websites actually go to extra effort to prevent autofill from working.

Even worse is when the input is initially has the cursor, but then the site's absolute genius SSR rehydration kicks in, not only erasing what you just typed, but also removing focus from the input.

I needed 22 tab presses to achieve the comment field here w/o mouse and tab enter to send.

a couple of reason not to focus:

1. on mobile devices, a focused <input> also triggers Keyboard to open, that in turn may cause the page/content to scroll suddenly etc. that could annoy the user, 2. if there's content to read (a message, Terms etc), the user may end up not fill the form at all

Isn't that what the @media stuff is for?

use @media to do what in this case? to not display the virtual keyboard on input.onfocus?

Disable autofocus when using a device (mobile?) on which it is problematic? I'm no expert though. Maybe that isn't possible or is more undesirable for some other reason.

Yes [however] you could using props like <input inputmode='none'> or <input readonly='readonly'> and that prevents the device's virtual keyboard from opening 'onfocus'. however, that's not practical, if you want to type/enter data into it during that session.

Maybe I'm not understanding the objective or the constraints. I thought the goal is to disable autofocus on mobile devices in order to prevent the appearance of the virtual keyboard from unexpectedly disturbing the layout.

In order to achieve this why not use @media to identify a device which uses touch input (I'm sure there are some edge cases, but this seems like a good proxy for a mobile device) and javascript or jquery to disable autofocus?

Sendgrid's lack of autofocus in the 2FA page is particularly annoying

One reason I don't see mentioned: you can't use keyboard shortcuts that use the backspace key.

I never knew of any backspace shortcuts. Are you referring to one in specific?

Backspace has traditionally been a back button shortcut. In a similar complaint, the current key combo to navigate back across all platforms doesn't perform that action when a textbox is focused.

Using the backspace key to go back is a massive PITA in browsers that have that keybinding set. Have accidently lost form input by pressing backspace, so frustrating. Backspace should only delete a character in a form and not go to a different page.

While I normally feel like the designers don't care about accessibility, I feel like in this case, it may be a bit of a security issue. The site wants to do all they can to foil automation, for example, and if the caret isn't helpfully placed exactly where they need to start input, a human can figure that out better than a bot.

If your security is dependent on the ability of a bot to know which fields are available, why not go all the way? Make a canvas tag, draw the input fields, handle the text input, and completely thwart those bots! /s

In case you haven't heard, a very popular and effective way to foil spambots has been the inclusion of a hidden FORM field, which the user won't see and won't fill out. The bot dutifully fills out the field, sends an HTTP POST, and is busted for looking at the HTML source. Have a nice day.

And it’s called a honeypot.

Useful against the lone hacker. Far less useful against a botnet where the source IPs are both constantly changing and not necessarily a bad actor, just compromised.

But sure. Security measures from 1998 have their place too, I guess.

https://javascript.plainenglish.io/goodbye-html-hello-canvas...

Print the password prompt and request the user to send the answer via fax!

its because they're using autofocus

Vimium.

The web is not designed to be useful for any purpose. It is designed to demonstrate plausible "technologies" developed by companies whose investors want to sell them to other companies.

Anything beyond basic WEB 1.0 is intended to be "plausible" instead of "useful."

Reply on news.ycombinator.com