[HN Gopher] Ask HN: Why do web sites not place the cursor for in...
___________________________________________________________________
Ask HN: Why do web sites not place the cursor for input?
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.
Author : backendanon
Score : 52 points
Date : 2023-07-23 15:23 UTC (7 hours ago)
| NoZebra120vClip wrote:
| 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.
| ttfkam wrote:
| 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
| eddd-ddde wrote:
| Print the password prompt and request the user to send the
| answer via fax!
| NoZebra120vClip wrote:
| 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.
| pwdisswordfishc wrote:
| https://javascript.plainenglish.io/goodbye-html-hello-
| canvas...
| eimrine wrote:
| I needed 22 tab presses to achieve the comment field here w/o
| mouse and tab enter to send.
| codingclaws wrote:
| One reason I don't see mentioned: you can't use keyboard
| shortcuts that use the backspace key.
| eddd-ddde wrote:
| I never knew of any backspace shortcuts. Are you referring to
| one in specific?
| alexchamberlain wrote:
| 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.
| someweirdperson wrote:
| 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.
| capableweb wrote:
| Similarly, disabling pasting a copied code.
| kiririn wrote:
| 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
| EamonnMR wrote:
| 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.
| MattGaiser wrote:
| 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.
| willsmith72 wrote:
| I love the auto submit on auth codes
| bdavbdav wrote:
| 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.
| mtmail wrote:
| (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...
| uses wrote:
| 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.
| amelius wrote:
| Sounds opinionated. Why not offer a choice?
| notsylver wrote:
| 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...
| Waterluvian wrote:
| 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!
| SanderNL wrote:
| This is ass-backwards. Screenreaders should handle autofocus
| properly or ignore it, not force the other 90% into (even
| deeper) insanity.
| appplication wrote:
| 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.
| throwaway1777 wrote:
| Just ignore the standard and do what's best for the users.
| cosmotic wrote:
| 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.
| [deleted]
| paulddraper wrote:
| Yeah I'm all for helping 5% of the population, but not at the
| expense of the other 95%
| nodesocket wrote:
| I get that, but dedicated 2fa pages should default into the
| text input. A few big sites don't do this.
| nosefurhairdo wrote:
| 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.
| mr-wendel wrote:
| 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.
| Tagbert wrote:
| 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.
| bjourne wrote:
| 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.
| brrtbrrt wrote:
| [dead]
| ravenstine wrote:
| 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.
| retrocryptid wrote:
| 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."
| pictur wrote:
| [flagged]
| bdcravens wrote:
| 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.
| ttfkam wrote:
| <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.
| Kiro wrote:
| How does that take care of the accessibility issue?
| ttfkam wrote:
| 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.
| [deleted]
| pengaru wrote:
| 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.
| necovek wrote:
| 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.
| htfu wrote:
| Vimium.
|
| gi
| dimaor wrote:
| Sendgrid's lack of autofocus in the 2FA page is particularly
| annoying
| al_be_back wrote:
| 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
| mhb wrote:
| Isn't that what the @media stuff is for?
| ttfkam wrote:
| 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...
| bob1029 wrote:
| 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.
| paulddraper wrote:
| I don't see how autofocus and tab order are made any worse by
| a web framework.
|
| What's the connection?
| cstrahan wrote:
| 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.
| frob wrote:
| 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.
| teaearlgraycold wrote:
| 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.
| bluepod4 wrote:
| "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.)
| Tronno wrote:
| 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.
| bluepod4 wrote:
| > 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.
| teaearlgraycold wrote:
| 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.
| nosefurhairdo wrote:
| There is nothing about the dominant web frameworks that
| prevents one from implementing semantically correct HTML.
| ttfkam wrote:
| Prevent? No. Discourages? All the time.
| nosefurhairdo wrote:
| Can you give an example?
| jahewson wrote:
| Great, now disable it on mobile where opening the on-scree
| keyboard is jarring.
| amelius wrote:
| 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.
| bob1029 wrote:
| > 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?
| naikrovek wrote:
| 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.
| illamint wrote:
| 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).
| ryandrake wrote:
| 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.
| htfu wrote:
| 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?
| bob1029 wrote:
| > 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.
___________________________________________________________________
(page generated 2023-07-23 23:03 UTC)