Accessibility: Autofocused elements

[cjcenizal]

Problem

On most pages, keyboard focus is automatically set to a particular page element (e.g., the search field on the "Discover" page). Automatically setting focus may cause confusion for keyboard users. It also means keyboard users must navigate backward (Shift + Tab) to navigate to the start of the page.

However, autofocused elements aren't always bad for accessibility! Per @aphelionz's comment below, we can use autofocus to create intuitive user experiences for people using screen readers.

If sighted users find auto-focused elements useful, then maybe we can create a settings option for opting in (or out) of this behavior.

Audit

Search for autofocus, input-focus, and select() for trouble spots.

[eprothro]

FWIW, I would prefer this change in functionality (removing autofocus) be opt-in.

• There is a noteworthy speed benefit to majority of users by having fields autoselected
• Adding accessibility is already a change in behavior to keyboard users, so with opt-in, we don't also change behavior for other users (one man's feature is another man's bug here).

[aphelionz]

In my opinion/experience this is entirely contextual. It can be confusing if done clumsily, but if you make sure the screen reader reads the right text to the user, i.e. "Create an Index Pattern" -> enter key -> "Enter the index pattern name", then it will make sense and save a lot of time.

That is to say, each case needs to be considered. We can't blanket remove all autofocus, but the practice should be done with care and consideration

[cjcenizal]

I think Discover is an app where autofocusing the query bar makes a ton of sense, since the whole point of that app is to let you explore your data. What do you all think of this solution:

1. Apply aria-describedby to the query bar input, and point it to the title of the app ("Discover") and a hidden label to describe what this search does ("Search your documents using the Lucene query syntax").

2. Add a "reverse skip link" so that screen readers can tab off this input and go back to the top of the document. I'm not sure if this is useful, but if part of the confusion of autofocus is that it drops you into the middle of the information hierarchy, then it seems like having the ability to quickly "start over" might help.

[timroes]

I've just checked all our autofocus instances and I would consider them all to be fine. Also with providing proper landmark navigation to all of Kibana, there is not the problem, that you would need to "shift-tab" to the beginning of the document, because you can make use of the landmark navigation to jump to any part of the application you like.

Thus closing this, and if there are more specific cases where the autofocus might break things and we want to discuss whether to remove it in that place, let's open a new issue for that case.