6 ms·

This looks like a great resource. Human checklists are not perfect but they tend to be better than automated checks for this sort of thing. But there is a comm

This looks like a great resource. Human checklists are not perfect but they tend to be better than automated checks for this sort of thing. But there is a common form of accessibility guideline that I have a problem with, and this one illustrates it well: "Avoid using the autofocus attribute." The problem here is it quietly pits users with special accessibility needs against the rest - "Just don't use feature X." OK, but what should I do instead for the rest of my users who benefited from feature X? What if I'm making a search engine landing page and I want to automatically focus the input on page load (and automatically bring up their keyboard if touchscreen)? Is there some other approach that achieves the same UX as the autofocus attribute but without creating accessibility problems? According to MDN, "When autofocus is assigned, screen-readers 'teleport' their user to the form control without warning them beforehand." OK, but really? Why? Why don't they offer the user the option to not do that?

wwweston 4y ago
I have no particular disability at the moment and I’m struggling to think of anything that autofocus adds to my browsing experience and not struggling to think of times it’s annoyed me.
- hallway_monitor 4y ago
  On the other hand, I am endlessly annoyed when e.g. Ebay / Amazon do not auto focus the search box on page load. Anything else I'm going to click and probably 50% of the time I want to search. Just auto-focus please.
extra88 4y ago
Checklists are not a place for nuance. A search engine landing page is a place where using autofocus in the search field is perfectly appropriate; autofocusing a search field that's in the header of every page is not.
- playpause 4y ago
  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.
  - rendall 4y ago
    > 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 4y ago
      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).
      - rendall 4y ago
        Hmm. "All users should experience the page linearly because some do" is not really an argument that works.
        extra88 4y ago
        A sighted user with a cursor or touchscreen can be as non-linear as the size of the viewport and the layout allows. All designers should design the linear experience as well as the non-linear experience because the linear is all some users will have. Responsive design is a move in that direction, a smartphone portrait display is much narrower than a laptop display so the content tends to be in a more linear layout. Experiences through voice assistants are also linear.
Diggsey 4y ago
I agree with the comment, but: > Why? Why don't they offer the user the option to not do that? A screen-reader doesn't replace the browser - it just responds to changes in focus by reading out a description of the currently focused item. It should be the browser that offers an option to disable autofocus. Firefox does seem to have an option in about:config called "browser.autofocus" which I assume does this exact thing.
- mwcampbell 4y ago
  The screen reader could still choose to ignore the automatic focus and read the whole page instead.
  - Diggsey 4y ago
    How? The accessibility APIs in question just tell the screen reader when the focus changes, it doesn't say why it changed. I'm sure theres a hacky way to make it work for specific browsers, but it's the wrong place to solve the issue.
FalconSensei 4y ago
I don't remember which site has autofocus for the username and I absolutely HATE IT, specially because it did that after a small delay - probably loading all js and crap - so it would change the focus from the PASSWORD field to the user field.
Vinnl 4y ago
> it quietly pits users with special accessibility needs against the rest Not just that; it pits users with one accessibility need against users with another. (Or I guess, not "pits" so much, sometimes needs just conflict.) For example, for someone with motor impairments, having to control the mouse (or pressing Tab a lot) to focus an input field rather than being able to use their keyboard right away is not a great experience.

wwweston 4y ago

I have no particular disability at the moment and I’m struggling to think of anything that autofocus adds to my browsing experience and not struggling to think of times it’s annoyed me.

hallway_monitor 4y ago
On the other hand, I am endlessly annoyed when e.g. Ebay / Amazon do not auto focus the search box on page load. Anything else I'm going to click and probably 50% of the time I want to search. Just auto-focus please.

extra88 4y ago

Checklists are not a place for nuance. A search engine landing page is a place where using autofocus in the search field is perfectly appropriate; autofocusing a search field that's in the header of every page is not.

playpause 4y ago
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.
- rendall 4y ago
  > 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 4y ago
    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).
    - rendall 4y ago
      Hmm. "All users should experience the page linearly because some do" is not really an argument that works.
      - extra88 4y ago
        A sighted user with a cursor or touchscreen can be as non-linear as the size of the viewport and the layout allows. All designers should design the linear experience as well as the non-linear experience because the linear is all some users will have. Responsive design is a move in that direction, a smartphone portrait display is much narrower than a laptop display so the content tends to be in a more linear layout. Experiences through voice assistants are also linear.

Diggsey 4y ago

I agree with the comment, but: > Why? Why don't they offer the user the option to not do that? A screen-reader doesn't replace the browser - it just responds to changes in focus by reading out a description of the currently focused item. It should be the browser that offers an option to disable autofocus. Firefox does seem to have an option in about:config called "browser.autofocus" which I assume does this exact thing.

mwcampbell 4y ago
The screen reader could still choose to ignore the automatic focus and read the whole page instead.
- Diggsey 4y ago
  How? The accessibility APIs in question just tell the screen reader when the focus changes, it doesn't say why it changed. I'm sure theres a hacky way to make it work for specific browsers, but it's the wrong place to solve the issue.

FalconSensei 4y ago

I don't remember which site has autofocus for the username and I absolutely HATE IT, specially because it did that after a small delay - probably loading all js and crap - so it would change the focus from the PASSWORD field to the user field.

Vinnl 4y ago

> it quietly pits users with special accessibility needs against the rest Not just that; it pits users with one accessibility need against users with another. (Or I guess, not "pits" so much, sometimes needs just conflict.) For example, for someone with motor impairments, having to control the mouse (or pressing Tab a lot) to focus an input field rather than being able to use their keyboard right away is not a great experience.