Hacker News Reader

Comment by mtmail | Hacker News Reader

(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...

View on HN

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%

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.

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.

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

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

Sounds opinionated. Why not offer a choice?

Reply on news.ycombinator.com