IE focuses elements on click that should not be focusable, and Claro makes this very apparent.

No idea how to address this. How much longer do we need to support IE11?

I haven't heard about this problem with IE11. Is it documented elsewhere? Can you provide more detail about which divs you're concerned about, and steps to reproduce?

These elements are out of tabbing order, but they could be focused using a pointer device.

You're supposed to be able to position focus that way, in any browser. You can use a pointer to click on approximately the correct area of the page (usually in an area of whitespace), then press tab to move forward through operable controls from that point onwards. That's how I normally operate web pages. A lot of users who have difficulty with pointers do this; we are keyboard-mostly, rather than keyboard-only.

Visible focus indicators are only needed when an operable control has focus.

since our current :focus styles are applied globally

Ideally, they should be applied globally. Otherwise you have to maintain :focus rules for a gazillion different components. Seven has a lot of custom focus styles for individual components, and it would be good to avoid that, or at least greatly reduce the number of instances.

Step to reproduce -
On IE11, Umami installation + Claro. /node/1/edit

As you can see in the screenshot below, clicking on an area (outside the items of the form) will mark it with an outline:

I created a patch that removes that outline form-wrapper.

@lauriii
Patch #5 is now using
.page-wrapper *:focus:not(.form-wrapper)

Would you prefer instead of that, adding a specific rule that hides the box-shadow?

.page-wrapper form-wrapper:focus {
  box-shadow: none;
}

In a pinch, this rule will take care of things and (I think) won't result in any unwanted side effects.

<del>/* stylelint-disable-next-line selector-type-no-unknown */
_:-ms-fullscreen,
.page-wrapper div:not([tabindex]):focus {
  box-shadow: none;
}</del>

I'm not quite ready to add this to a patch, though, as I'd like to better understand what leads to this happening as the css rule above may not be the optimal solution.

This is a bad solution - it was an approach considered before the underlying IE11 bug was identified.

I created a plain-html page and loaded it in IE11. If a div is set to display: flex; it receives focus when clicked on... It must be a bad Google day for me as I can't find this mentioned anywhere online, it seems like something that would have been discovered and discussed by now. This is the html I used in IE11:

<!DOCTYPE html>
<head>
  <style>
    .content *:focus {
      outline: 5px solid red;
    }
    .display-as-flex {
      display:flex;
    }
  </style>
</head>
<title>Example form</title>
<div class="content">
  <form method="get" enctype="application/x-www-form-urlencoded" action="/html/codes/html_form_handler.cfm">
    <p>
      <label>Name
        <input type="text" name="customer_name" required>
      </label>
    </p>
    <p>
      <label>Phone
        <input type="tel" name="phone_number">
      </label>
    </p>
    <p>
      <label>Email
        <input type="email" name="email_address">
      </label>
    </p>
    <div class="display-as-flex">
      <h2>I'm in a form, in a div set to display:flex, click me and for some reason I get focus.</h2>
    </div>
    <div>
      <h2>I'm in a form, in a normal div. Clicking me does not result in the div getting focus.</h2>
    </div>
    <p><button>Submit Booking</button></p>
  </form>
  <div class="display-as-flex">
    <h2>I'm in a div set to display:flex outside the form, click me and for some reason I get focus.</h2>
  </div>
  <div>
    <h2>I'm outside the form, in a normal div. Clicking me does not result in the div getting focus.</h2>
  </div>
</div>

It seems not only flexbox is affecting on focus, but also changing display rendering in general. Using HTML example above, I've added inline styles and classes with float, and various display properties, and each time I saw focus issue in IE11.
Me neither found any mention about such bug.
Looks IE11 understands literally this rule *:focus

Can someone clarify which divs are known to be affected? The summary just says "some divs". I think @lauriii is also asking for the same thing in #6

I removed the novice tag at the moment and fixing the event tag.

I've made a demo to illustrate this issue:
https://jsfiddle.net/martijncuppens/z9fnydv1/4/

Whatever we try, we'll need to increase CSS specificity to fix this (unless we can rely on native custom properties).

Why don't we just update the Toolbar and Settings Tray CSS?
Then we can update the CSS to something like:

a:focus,
button:focus,
input:focus,
summary:focus {
  outline: 2px dotted transparent;
  box-shadow: 0 0 0 2px #fff, 0 0 0 5px #26a769;
}

I just checked it looks like this bug is supposed to be everywhere, where parent html-tag has "display: flex" property, no matter what is inside, this tag gets focus ring.

So!

Honestly i don't know a way how we could manage that, instead of only rewriting:

page-wrapper *:focus,
.ui-dialog *:focus {

to something more obvious, with sensitivity to all possible cases, like:

a:focus,
button:focus,
input:focus,
...some special rules?...
...etc... {

Went with a version of what was suggested in #19. It's targeted to IE, so all other browsers still get the

page-wrapper *:focus,
.ui-dialog *:focus {

styling. The elements targeted is based on the ally.js list of focusable elements https://allyjs.io/data-tables/focusable.html

I started wondering what are the major benefits of having these more specific selectors only for IE 11? I

The decision to go IE11 specific was:

• In past issues I recalled (though this recollection my be incorrect...) seeing a desire to maintain the current *:focus approach to styling the rings. I thought this may have a better chance of making it through the gates if that approach is only altered in circumstances where it's absolutely necessary.
• If there were imperfections with this approach, it would only be on a browser with 1.44% usage (and falling). If there was some kind of problem, it would still be preferable to the current situation of arbitrary focus rings appearing in strange places .

Neither of those are strong opinions, though! Just my thought process for this first patch. I also think the ability to reference the allyjs table makes a specific-selector approach a much safer option in general.

• The media query for targeting everything-but-IE11 did not seem to work anymore, so this has been changed to a @supports, which works with all Drupal supported browsers other than IE11, so it's fine to use this for this specific kind of targeting.
• This patch changes the specificity of focus styling for IE11. The default .classname *:focus is .classname TAG:focus in IE11. I grepped for all :focus in the rest of Claro's CSS and looked for rules that style box-shadow or outline, with selectors that would override .classname *:focus, but not .classname TAG:focus. In these cases, I added an IE11 media query that provided selectors with specificity that would successfully override the default focus styling as expected.

Verified and tested by applying patch #25. Looks good to me.
Can be moved to RTBC.

I did a bit of discovery after the discussion with @rainbreaw that was mentioned in #28. I confirmed that when these shouldn't-be-focusable elements are clicked and get a focus outline, they do become IE11's active element. I had previously thought the bug was purely cosmetic, but since focus is actually changed, the current solution of hiding the outline is not a viable one. @rainbreaw correctly pointed out that if an element receives focus - even due to a bug - that focus state should still be visible. This will need to be addressed in a different way.

None of the previous patches I provided will work because it's not addressing the underlying problem of elements receiving focus when they shouldn't. Those patches would hide the focus ring in those instances, improving things visually but making the experience less accessible.

This approach adds a mousedown listener and prevents focus on elements that should not receive it. I was initially concerned about side effects as this is a somewhat broad solution, but the preventDefault() will not occur on anything that is truly focusable.

Linking open issues from the CivicActions Accessibility - VPAT.

#30 Patch failed

#36 Please review the patch

Re-rolled patch #36, Attached interdiff for same.

Verified and tested patch #37.
Patch applied successfully and looks good to me.

Testing Steps:
# Goto: Appearance -> Apply Claro theme
# Go to any content -> Edit it
# Click on any elements
# User is able to see Green focus

Expected Results:
# IE focuses elements on click that should not be focusable, and Claro makes this very apparent.

Actual Results:
# Currently User is able to see Green focus.

Looks good to me.
Can be a move to RTBC.

we can add the nomodule attribute to the script to make sure it's only executed in "old" browsers.

The patch still has some lint issues (dictionnary).

Added the nomodule attribute and dictionary.

Tagging for Design4Drupal 2021. Contributions are Friday, July 22
https://design4drupal.org/

Correcting tag Design4Drupal2021

Closing as outdated since Internet Explorer is no longer a supported browser

Drupal 10 doesn't support IE11, but Drupal 9 does, and that will not be EOL until November 2023

Fixed CCF for #40.
Please review.

@bnjmnm can we keep the Version at Drupal 9, since we don't need to support this for Drupal 10?

Just trying to prepare an ACR for D10, and wanting to exclude stuff that isn't relevant.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Switching version to Drupal 9 as Internet Explorer is not supported by Drupal 10.

Closing since we don't support IE11 anymore after #3254202: Remove IE11 Support from Claro.