[playpause]

I agree, autofocusing a search field that's in the header of every page is not generally appropriate, but that's not specifically about accessibility. It would be annoying for anyone on a mobile device (keyboard pops up on every page), and the focus ring and/or blinking cursor would be distracting.

What about cases where it is appropriate to autofocus the search input (as it's the primary action on the page) but where there also might (sometimes) be an important text notice above the search input? Sighted users would see the notice fine, while screenreader users would be 'teleported' (MDN's word) straight past it, missing the notice.

[mwcampbell]

I believe it's up to screen reader developers to come up with innovative ways of making the web as it currently exists more usable, rather than requiring the millions of websites out there to accommodate the technology's current limitations. In this case, perhaps screen readers need to somehow intelligently read nearby text when a control immediately receives focus on page load.

[extra88]

No. Browsers already parse the page to produce an accessibility tree that's provided through the operating system's accessibility API. Screen readers attempting to supplement what's provided through that API by re-parsing the page should be a last resort and is bound to be error-prone.

Designers and developers need to learn that what they make will be, and should be, experienced in ways different than how they do. Content is experienced linearly, not always in two dimensions, and semantics can make programmatically explicit what is only implied visually (like heading text being bigger and bolder).

The prevalence of smartphones and responsive design have helped somewhat to expand people's understanding of how using digital experiences can vary. There's a lot more that can be learned.

Aside from not using autofocus on the input field at all, another existing option is to programmatically associate the preceding block of text by giving the block a unique id and referencing it from the input using an aria-describedby attribute; after a screen reader reads the input's accessible name, it will read the associated description.

[rendall]

> while screenreader users would be 'teleported' (MDN's word) straight past it, missing the notice.

Autofocus in that case seems like reasonable and expected behavior. Isn't it up to the tools (e.g. screen reader, etc) to accommodate the expected behavior, rather than for the reasonable and expected behavior to change?

[extra88]

No. It is reasonable and expected that some users experience page content linearly so designers and developers have to create experiences that takes that into account. That includes not skipping important content. If it's important, don't skip it. If it's not important, maybe it's okay to skip it but there should be means for users to explore and discover what's on the page (like give the preceding block of text a heading that indicates what that section of content is about).