Bootstrap: Changing focus outline for tabindex="-1" has undesired side effects

[artopaavola]

Removing indiscriminate outline suppression for tabindex="-1" elements in version 4.4.0 causes undesired side effects in vanilla js behaviour.

An example: When element.scrollIntoView() is used with focus() there will now be an outline around the element which has been scrolled into view. In case you are wondering, the focus must be programmatically moved to the element so that keyboard focus will also follow the scrollIntoView.

Tested on macOS with Chrome 79, Safari 13.04 and Firefox 71.0

• Focus outline is visible but shouldn't be CodePen: ScrollIntoView with focus in Bootstrap 4.4.1
• Focus outline is not visible which is correct CodePen: ScrollIntoView with focus in Bootstrap 4.3.1

[danielnixon]

scrollIntoView() is unrelated to what's happening here. It's the call to focus() that is moving focus, which is triggering the focus outline styles.

the focus must be programmatically moved to the element so that keyboard focus will also follow the scrollIntoView.

Yep exactly. And focus must be visible:

• https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html
• https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F78
• http://www.outlinenone.com/

If you absolutely _must_ remove focus outlines (but why?), consider using the :focus-visible polyfill so focus outlines are only hidden from mouse users, _not_ keyboard users.

[artopaavola]

You are right, scrollIntoView() is unrelated for the focus styles but I thought the example would make more sense with the scrolling behaviour.

It's clear that focus must be visible for keyboard actionable elements, but I disagree that the focus outline must be visible in my example on the heading where the focus is set programmatically. Are you sure, that WCAG means that focus styles must also be visible on non-keyboard actionable elements? I haven't found anything on that in WCAG. For example, the links to WCAG specs that you provided are only talking about focus styles on keyboard actionable elements.

[danielnixon]

People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

Even if clicking your focused heading has no effect, there must be some reason you're moving the focus to heading (so that focus is moved to the heading at the start of a new dynamically rendered section/page, I assume). In that case, there's value in having the visual indication of where focus currently is because it makes clear what will happen when the user presses tab or shift+tab to move the focus forward or backward.

Removing the focus indicator is needlessly disorienting. Why remove it?

[patrickhlauke]

Because arguably focus indication denotes something that interactive and actionable to some users, who may then be disoriented when they try to activate/trigger something they think it's interactive when it's not.

FWIW there's disagreement on this point even in AGWG https://github.com/w3c/wcag/issues/1001

[artopaavola]

My original case is almost exactly like one of the examples in Patrick's link.

When submitting a form, focus is sent to the container of an error message above the form.

The container has role="alert"and I think it shouldn't have an outline like it now does with Bootstrap 4.4.1.