[policy, no patch] Drop IE11 support from Drupal 10.0.x

+1 This would make upcoming features around Claro, Gin & Olivero so much easier. Talking about accent colors with CSS3 vars etc.

Please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please 🙏 please!

IE11 usage among assistive tech users in markedly higher than for the general population. However it's not clear why this is the case. More details in the comments at #3080068: [policy, no patch] Define usage heuristics for browser support.

I'm wary of using the low IE11 usage among the general population as a justification for this. We need to be sure we're not throwing assistive tech users under a bus by dropping IE11 support. It would be nice to understand the reasons why IE11 usage is higher among assistive tech users, and take that into account.

The shopping trolley image here is a bit crass IMO. It's reinforcing the Chrome hegemony (it won't last forever...) which isn't really what's intended here I think.

Support for assistive tech should definitely be a factor -- if a significant portion of assistive tech users rely on IE11, then we should see what we can do to continue to support it. Up-to-date stats would be good. Quoting part of @andrewmacpherson's comment from the other issue:

• WebAIM Screen Reader User Survey #8 Results (1224 respondents, year 2019). In response to the question "When using your primary screen reader, which browser do you use most often?", IE11 usage was at 10.9%, and Firefox at 27.4%. IE6-10 account for a further 3.6% of users!
• WebAIM Survey of Users with Low Vision #2 Results (248 respondents, year 2018). MSIE usage is 15.3%, with Firefox at 21%. Notably, these browsers support Windows high-contrast mode, while Chrome doesn't. This is around the time Edge development switched to Chromium, and the introduction of the CSS draft forced-colors media feature.

Those first two are fairly recent surveys, but by 10.0.0 they will also be several years out of date. I think we need ongoing research into assistive tech and IE11 before we can make a decision to drop support. It looks as though usage of IE11 is declining (at least with screen readers specifically) but also still has a significant market share.

The current policy is that we support the most recent version of IE, which is IE 11. Regarding Olivero and Claro in #5, we already added PostCSS -- does that not help the situation?

Regarding Olivero and Claro in #5, we already added PostCSS -- does that not help the situation?

The biggest obstacle (for Olivero) is lack of runtime CSS variables. PostCSS adds static CSS variables, but they're very limited in what they can do (they behave more like Sass variables). We have to define a separate variable for each media query. This is very cumbersome and hard to understand (see the mess at https://git.drupalcode.org/project/olivero/-/blob/8.x-1.x/css/src/base/v...)

Furthermore, PostCSS variables do not cascade. They have to be attached to the html element. Which means that we cannot set CSS variables within Twig and pass it.

A secondary issue is poor CSS grid support. IE11 supports an older version (which we can automatically change the syntax), but it does not support negative grid column numbers, or grid autoplacement (the last is a big one), which leads to horrible hacks such as https://git.drupalcode.org/project/olivero/-/blob/8.x-1.x/css/src/base/u..., and drastically limits what we can do.

In addition, modern browsers support CSS logical properties (https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties), which would drastically reduce CSS size (improving performance) by negating the duplication of rules for RTL.

tl;dr

PostCSS definitely helps, but the pain is still very real.

The biggest obstacle (for Olivero) is lack of runtime CSS variables. PostCSS adds static CSS variables, but they're very limited in what they can do (they behave more like Sass variables). We have to define a separate variable for each media query.

Also it makes it very hard to alter stuff like Gin does with Claro. Needed to override everything (Gin uses CSS Vars also in the output, so subthemes could profit from that). If Claro would have the CSS Vars in the dist files that would make everything a lot easier.

In response to @saschaeggi:

Yes! Changing colors would be relatively trivial if we could support variables. As it stands now, we have to back-burner it because of the complexity of supporting IE11.

IE11 support really holds Olivero back IMHO.

I will chime in here and say that in my experience, demands for IE11 support are often driven by corporate policies that require its use, often related to legacy .NET apps that require it to run. I don't think it's reasonable that the rest of us should have to suffer for the sins of these few, but perhaps related to this policy we should have something we can communicate to such institutions as a viable workaround: Chrome IE Tab, etc.

I had a recent experience that suggests IE11 support should continue for a while longer. This is obviously anecdotal, but there's little to suggest this isn't an issue that would be faced by many.
In my scarce free time, I'm assisting with a web application that visualizes COVID-19 data for the state of Michigan. It was intended for use by government officials and others in policy-influencing roles. IE11 support was not prioritized due the additional effort required vs. the low usage statistics and many concerns were dismissed as something the end user or organizations should figure out, not the developers.

Within the first week of launch we discovered many users were unable to use the application due to a lack of IE11 support. More than a few of these users are in positions where this data could literally influence life or death decisions. IE11 support mattered.

Government and large organizations often have unwieldy systems and progress at agonizingly slow speeds. The fact that Drupal accommodates these kind of scenarios is one of its strengths, despite the many inconveniences that come with it.

I'm reluctant to drop IE11 support until there's clear evidence that institutional use is close to zero. I'm concerned that many of the institutions unable to move past IE11 also happen to be ones that significantly impact people's lives and Drupal's market share.

I also agree that IE11 is a major pain to support, the accommodations required demand extra time and obstruct innovation. To address those concerns, I'd be more comfortable with a graceful degradation policy is vs. eliminating IE11 support altogether. For example, I'm not opposed to potentially removing IE11 support from Claro since users still have access to Seven (many things would need to be figured out before such a decision could be implemented, of course).

In response to #14, note that IE11 support would be dropped for administrative interfaces and core themes. There's absolutely nothing stopping people from not supporting IE11 in mission critical apps, just as there's nothing that forces them to support IE11.

In addition, keep in mind that this change will be several years down the road.

There's another potential reason for the much higher IE 11 usage in the WebAIM survey besides the difference in audiences, which is that the data has been collected in a different way. It's based on what users report themselves, instead of their actual behaviour. We can see that 86% of the participants use a mobile phone: https://webaim.org/projects/screenreadersurvey8/#devices. Majority of them either use mobile phone as much as they use computer, or more: https://webaim.org/projects/screenreadersurvey8/#mobiledesktopusage. Based on that, 9.5% of the respondents mostly use their phones, but they could have still responded with their preferred browser.

Anecdotally, many of my relatives are owners of very old computers. However, they barely use them since they can do everything on their mobile phones and tablets. In a survey like this, they could report that they are using IE 11, when it actually means that they are doing it not more than once or twice a year when they have to do something more complex such as filing taxes.

I also tried to find a third data source to see if they are reporting as low numbers on IE 11 usage as Statcounter. I discovered data published by Wikimedia Foundation. Interestingly, they also receive higher usage of IE 11 compared to Statcounter.

Even though the Wikimedia foundation data shows that there could be more usage of IE 11 than what Statcounter is pointing out, it still seems pretty encouraging in terms of removing IE 11 support in 2022. The Wikimedia Foundation shows around 13% of desktop traffic coming from using IE 11 in the August of 2019. However, in the August of 2020, their data shows only 3.7% of desktop traffic coming from using IE 11. All sources consistently demonstrate that IE 11 usage is decreasing constantly.

I made graph for easier comparison of desktop browser marketshare based on different data sources:

Looking at different data points, we can see how the numbers vary in different contexts. Because of this, for some websites it completely makes sense to support IE 11, whether it's due to a higher proportion of the users of the site using IE 11, or due to legislation or other policies. Even if Drupal core doesn't provide support for a browser, it doesn't have to mean that it would be impossible to build sites that are IE 11 compatible. If developers find it important to support IE 11, they could build a module that provides IE 11 support to the extent that they need.

As I mentioned earlier, people have multiple devices (both, anecdotally, and based on the data since 86.3% of the respondents report using screen reader on a mobile device). If a user is lucky enough to have a second device and a site fails when they are using IE 11, they could still try again using their mobile phone or tablet.

Based on all of this, the number of people reporting they use IE 11 on the WebAIM survey could be slightly higher due to differences in the way the data has been collected. Regardless of that, it is likely that there are some differences caused by different preferences and differences in demographics between respondents of the survey and general public. However, usage of IE 11 is going down based on all metrics (including WebAIM surveys), most likely to the extent that it would make sense for us to stop supporting latest in 2022.

Microsoft is dropping support for IE11 on a range of it's own products in about a year from now (Office365), Teams Web already Q4 2020: https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-...

Tagging so people find this issue alongside the ones being done in Drupal 9 for Drupal 10.

While investigating the removal of jQuery, I ran into a few things that would be needed only if IE11 continues to be supported:

• The :scope selector, used for queries such as immediate children. For example, '> td' in jQuery would be accomplished by ':scope > td' in Vanilla. No polyfills were easily findable. This can probably be worked around by chaining a few functions but doesn't seem ideal. Info: https://developer.mozilla.org/en-US/docs/Web/CSS/:scope
• Nodelist.forEachA pretty simple polyfill can be added in #3143465: Add NodeList.forEach polyfill to support IE11, but wouldn't be needed if IE11 is out. Info: https://developer.mozilla.org/en-US/docs/Web/API/NodeList/forEach
• Element.closestEasy to polyfill, but not needed if IE11 is not supported. https://developer.mozilla.org/en-US/docs/Web/API/Element/closest

I suspect there will be more and will document here as I come across them. They are all surmounntable and shouldn't be seen as reasons we NEED to stop IE11 support, but should probably be factored into the "pros" column.

Microsoft has continued to remove support and repeat that ie is not a web browser anymore. Given MS own stance I see no reason to support ie anymore.

Also this was just posted https://www.theregister.com/2020/11/30/microsoft_teams_ie/ Edge will now have an IE mode to make peoples transition easier.

The main problem with disabilities and assistive tech is:

1. They are really expensive to buy, either hardware or software.
2. The user has set up a system they recognize and know by heart
3. Their hardware does not allow updates of OS anymore and can’t update because of that
4. They have difficulties learning a new system, so the stick to what they put huge amounts of hours into learning
5. They can’t afford license upgrade and are stuck with unsupported media.

In Sweden we do have a lot of benefits and free software and hardware for people with disabilities. But, the effort it takes to learn - usually with assisted learning is just too hard to do over again so a lot of people are stuck with what they have.
Other countries do not have benefits and people can’t afford.

So for Drupal to do this could affect a huge population without options to counter that…

I still hate IE11 and want to to disappear years ago… ;) But I care for people!
So, even though if it would boil down to administrator theme, would mean people being excluded in the workspace is in OUR hands.

I have a couple thoughts

So, even though if it would boil down to administrator theme, would mean people being excluded in the workspace is in OUR hands.

If its in the workspace, they employer should be able to handle the upgrade to a modern browser.

usually with assisted learning is just too hard to do over again so a lot of people are stuck with what they have.

We cannot support IE11 indefinitely. Learning new things is always going to be difficult, but that is part of life regardless if you happen to be disabled or not.

If the argument comes down to "We don't want to force people to have to learn new things", that equates to stopping our innovation as a whole.

But I care for people!

Me too, and that's part of what makes our community great 💙

There are modules to patch in support for older versions of IE (8, 9), so I expect the same could be done for IE 11 if there are things not specific to the default and admin themes included in core.

I do agree with you merchel!

Allthough...

If its in the workspace, they employer should be able to handle the upgrade to a modern browser.

I believe the hinder is not the employers ambition not to upgrade, but the assistive tech in use.

If the argument comes down to "We don't want to force people to have to learn new things", that equates to stopping our innovation as a whole.

Well, I'd say we need to take decisions with this in mind, people might have issues learning new things at all and we find a way to counter that without putting innovation in the bottom drawer. We all remember innovation of Flash and how that affected accessibility. =)

We need to tread lightly and make sure we do not exclude people in the progress of innovation. This is not an easy discussion with a clear solution. WebAIM might be of good help here?

@valross.nu regarding:

We need to tread lightly and make sure we do not exclude people in the progress of innovation. This is not an easy discussion with a clear solution. WebAIM might be of good help here?

Their survey is our primary resource for data on browser use with assistive tech. Unfortunately it only comes out every two years. This is an off-year, and postponing the decision until next year isn't something we can do.

See #9 earlier on this issue for related discussion of that.

Google announced yesterday that they are dropping IE11 support for Workspace (including Gmail) on March 15, 2021 https://workspaceupdates.googleblog.com/2020/12/ending-support-for-ie11-...

I asked a contact at WebAIM which says:

We will be conducting a new screen reader user survey early next year, so will have up-to-date data then.

At today’s BoF at DrupalCon Europe it’s been discussed the option to create a contrib module to give the option to still have support for IE11. It could be a really good middle solution for all the situations where it could be required for admin interfaces. I think most of the projects that would require IE11 support would probably require other contrib modules anyway.
By the time Drupal 10 is launched IE11 used will have decreased even more, as it’s been pointed in #9, and we could finally get rid of all the extra work that comes from giving support to IE11. So a huge +1 to this.

Discussed this in DrupalCon Europe with @Klara Binon, @rivimey, @saschaeggi, @ckrina, @justafish and @bnjmnm. We discussed the impact of dropping support for Internet Explorer 11 to users of assistive technology, and people in less privileged situations, in particular because our values and principles document that we build software that everyone can use. The group unanimously agreed that going in the front-line of dropping support for Internet Explorer 11 would be against our values and principles. However, since some large organizations like Google and Microsoft are dropping support before 2022, they are already likely forcing most people to upgrade to a different browser. The proposed timeline seemed reasonable to everyone.

We also discussed about our decision potentially having an impact on users that are obliged to support Internet Explorer 11. We don't know whether these types of requirements will still exist in 2023 when Drupal 9 is EOL, given that many organizations have likely already dropped support by then. Since many of the users having these types of organizations are usually larger organizations, it seemed acceptable to move at least some of the maintenance burden from the core maintainers to the organizations themselves. This could be done by encouraging contribution to a contrib module that provides support for Internet Explorer 11 in Drupal 10.

I also had a separate discussion with @mgifford, @JohnAlbin and @adamjuran on the accessibility BoF. We had a short discussion about the impact of the decision to users of assistive technology. On this discussion too, people seemed supportive of dropping support for Internet Explorer 11 in the proposed timeline. As a next step we agreed to ask for input from various organizations that are committed to accessibility. So far @mgifford has opened issues in the gov.uk design system issue queue and uswds issue queue. He also reached out to WebAIM on Twitter, and their response was:

Our official recommendation is that IE die a fast and ignominious death. Nobody should be using it. Period. A new survey early next year will provide more data, but continued support for no longer seems reasonable.

@Lauriii As promised I contacted some people and got a good answer from a contact working for "Anysurfer" the Belgian accessibility organisation.
He agrees that support for IE11 should drop. He says that alternative assistive technologies are working good now, a mayor step forward was when Edge became chromium-based.
Right now most sites don't work wel in IE11 anymore and they dissuade people needing assistive technologies from using IE11.

Excellent investigations and go throughs! I feel safe with you doing this fantastic work =)

I shared this thread with a colleague who focuses on accessibility, she spoke with the founder of the Blind Institute of Technology in Denver, as well as their research team, many of whom are native screen reader users. He is a JAWS user and is "in favor of ending support for IE11".

paraphrasing here:

WCAG standards specify support for current and future technologies under the Robust principle. There are no written standards for supporting legacy tech like IE11. Doing so could even put end users at a security risk as they would be using an unsecured browser.

Large companies like Microsoft are even dropping support for IE11 now, so it's definitely trending in that direction. To the point that assistive tech users are stuck with dated technology that relies on IE11 and can't afford tech that works with a modern browser: NVDA is completely free and available in 54 languages.

Even Windows Narrator handles standard HTML elements on Google Chrome, so from a screen reading software perspective, there is no major software that requires IE11 in order to function.

Tried to add some of the more recent information to the issue summary.

USWDS replied here: https://github.com/uswds/uswds/issues/3877 have also added that into the issue summary.

More help with the issue summary welcome, but also next step feels like drafting a change record, so tagging for that.

@catch and I agreed that the above feedback is sufficient that the release managers can sign off on this from a policy perspective, assuming the accessibility maintainers also sign off. So removing the RM review tag, but leaving it tagged for accessibility review.

Bumping priority -- this has a significant impact on what we do for D10 with frontend libraries.

Yes please

IE11 tats from gov.uk indicate

• 5.99% usage in Dec 2019
• 1.89% usage in Dec 2020

From https://twitter.com/TheRealNooshu/status/1348955568459968515

Information from the Swiss government: Requirement to support IE11 was dropped in 2020.
Link to the document: https://www.bk.admin.ch/dam/bk/de/dokumente/dti/ikt-vorgaben/standards/a... (German only)

Adding to the JS queue.

A fun thing I noticed today, I tested a patch on IE11 and windows automatically opened Edge with the same page and a splashscreen telling me the website works best in Edge. So for people who're not locked in on IE11 with group policy or something, usage should go down faster.

That's good to remove all non chromium-based Edge at the same time

Of note for Olivero:

We want to get Olivero to stable in either 9.2 or 9.3 so it can be the default theme for Drupal 10. That means making it stable in Drupal 9, which still supports IE11. That might mean that Olivero still needs to support IE11 even if we drop support in Drupal 10.

The only alternative I can think of is some sort of warning when you enable the theme, but that's not great UX either and sort of contrary to current policy. We're also going to have to handle this somehow for the CKEditor 5 experimental module.

Thats pretty interesting. I'd love to find a way around that.

From Olivero's point of view, we would love to remove IE11 support. Doing so would dramatically simplify our codebase as well as provide new requested features (eg changing colors).

Edit: We expect to support IE11 in Drupal 9 for forever. As long as we can drop support in Drupal 10, we can introduce the new features that we hope to.

Thank you for all of the feedback that was given during the feedback period. We decided to extend the feedback until the end of January based on a request from the accessibility topic maintainers to have more time for doing research on the impacts of this change to users.

During this period we have learned that:

• U.S. Web Design System (USWDS) has a policy of supporting browsers that have usage of over 2% based on their statistics. The number is in February 2021 2.3% which is down from 2.9% in December.
• Web Experience Toolkit (WET) open source project led by the Government of Canada no longer supports Internet Explorer 11. They have some issues with governmental agencies forcing Edge into a Internet Explorer 11 compatibility mode on certain websites.
• Based on data from gov.uk, Internet Explorer 11 usage has dropped from 5.99% usage in Dec 2019 to 1.89% usage in Dec 2020. They are still supporting Internet Explorer 11 based on their commitment to support 95% of their traffic.
• The government of Switzerland has dropped support for Internet Explorer 11 in May 2020.
• Hassel Inclusion recommends accessibility conscious organizations to continue supporting Internet Explorer 11 on a blog post written in January 2021.
• In Slack, @andrewmacpherson brought up several additional points and use cases we hadn't considered. He brought up how changing browsers is disproportionately inconvenient for screen reader users for various reasons such as that a lot of screen reader users rely on scripting/macros. There is also an informal pairing of what works well together in practice: JAWS+IE vs. FF+NVDA, which means that changing browser could in a worst case mean changing browser and screen reader at the same time.

Our values and principles document that we build software that everyone can use. Therefore, dropping support for a browser shouldn’t be taken lightly. It’s easy to forget how versatile the impacts of these decisions can be. Browser users depend on bookmark management, print dialogs, toolbars, password manager integrations, and so on. Ending support for Internet Explorer 11 means you have to learn all that again, and hope it works with your screen reader. At worst scenario Internet Explorer 11 users might face a learning curve for a new browser and a new screen reader at the same time.

While it would be nice to be able to support all browsers, there’s a cost associated with it. Here are some of the reasons why we are thinking of dropping support for Internet Explorer 11:

• Microsoft stopped developing Internet Explorer 11 in 2015. For that reason it is significantly behind modern browsers that have continued development. Because more and more libraries are adopting the use of those features, there is a significant cost associated with maintaining Internet Explorer 11. For example, the latest major release of CKEditor has dropped support for Internet Explorer 11, which means that Drupal 10 cannot support both CKEditor 5 and Internet Explorer 11.
• Microsoft and Google are dropping support for Internet Explorer 11 in many of their services before the release of Drupal 10.
• Usage of Internet Explorer 11 has decreased significantly. Drupal doesn’t collect analytics on browser usage from its end users, so we rely on data provided by other projects such as Wikimedia, WebAIM, and Statcounter. For example, in October 2019, Wikimedia had 4.4% of its traffic using Internet Explorer 11. October 2020 that number had dropped to 1.4%. Based on the data, the number of Internet Explorer 11 users will continue decreasing before the release of Drupal 10.
• Supporting Internet Explorer 11 degrades the experience for everyone. We currently supply all users extra code to make Internet Explorer 11 work. This increases the request size and makes page load time slower for everyone.
• The additional requirements of Internet Explorer 11 demand additional development time that far exceeds the browser's market share. These efforts come at the expense of new features and bug fixes, including accessibility improvements.

Given that, I believe that as other services are dropping support for Internet Explorer 11, it would be acceptable for us to do so too. With other services dropping support far sooner than Drupal, it seems like that other services will have forced most users off Internet Explorer 11 well before Drupal drops support. Ideally we could support all of the browsers our users are using but the cost associated with that would be too high. Many of the costs associated with supporting Internet Explorer 11 will keep increasing as more and more of the work needed for supporting it will be on our shoulders.

I have discussed with the accessibility maintainers and we have all agreed that with the current timeline we will be relatively late to drop Internet Explorer 11 support, since Drupal 10 is not released until mid 2022. Also, we will support Internet Explorer 11 in Drupal 9 until end-of-life in late 2023.

Given all that, I feel I have sufficient information to remove the Needs Frontend Framework Manager tag.

I opened #3198941: [policy, no patch] Allow CKEditor5 to be committed to Drupal 9.x and marked stable, despite not supporting IE11 to discuss #48. I also opened #3198919: Create plan for communicating new browser requirements to users for discussing how we communicate this change to our users.

We reviewed this during the Drupal Accessibility Maintainers Office Hours (Mike Gifford and Rain Breaw were both present along with Mike Herchel, Mikey Williamson, Anson Parker, and Ofer Shaal).

As a team, we determined that the line has to be drawn somewhere, and so it is time to allow us to move forward with better accessibility support for all technology and drop support for IE 11.

Removing 'needs accessibility review' tag, thanks for looking at this!

We still need a change record here, but otherwise I think we're close to being able to close this. We should also update the d.o requirements docs (probably with a Drupal 10 section for now) at https://www.drupal.org/docs/system-requirements/browser-requirements as part of marking this fixed.

I added note to https://www.drupal.org/docs/system-requirements/browser-requirements that IE is only supported by Drupal core versions below 10. I've also created a draft CR so I'm moving this to needs review.

can we tweak the wording on the browser support page? "Drupal <10" is not very human friendly, something like "Drupal 9 and below" maybe?

Looks like #56 has already been fixed. I also made some small edits to the CR.

Should we mention that we considered the accessibility impacts in the CR?

Sorry for the noise.

Can we specify which Edge (chromium or not)?

We may remove the non-chromium-based Edge supports accidentally. broswerlist counted them the same browser

I think we intended to support it, at least for 9.x.x.
https://www.drupal.org/project/drupal/issues/3084843#comment-13351708

It's good timing to remove IE & non-chromium Edge together in this thread.

A follow-up issue for borswerlist config update is required
https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/package.json...

@droplet we only support the latest two major versions of each browser, so non-chromium Edge should get dropped automatically by the current policy, and this would allow for dropping support during Drupal 9 (we may already have done so?). If we need to discuss non-chromium Edge, we should do so in a new issue.

Opened the follow-up for browserlist, good point! #3200913: Remove IE11 from browserlist configuration

Added this bullet to the CR per #57: https://www.drupal.org/node/3199540/revisions/view/12223147/12223978

The documentation page has been updated and there is a change record draft. Moving to RTBC.

I can't think of anything else to do here. Marking fixed and adding some issue credit.

I think Mikey Williamson and Anson Parker need credit on this issue via the accessibility office hours meeting, but I don't have their Drupal.org user names - if someone could post those we can add credit later.

Further support for this decision: Microsoft announced they are retiring IE11 on Windows 10 in June 2022. While IE on Windows 8.1 is out of scope of that announcement, Windows 8.1 itself is EOL in January 2023 as well.

Technically, the tech note reads "for certain versions of Windows 10"

I don't object to dropping support; just want to be rigorous here.

Fair point. But they clarify in the article that the only Windows 10 versions that are excluded are Windows Server (which is intended for server use, not for browsing websites) and Windows LTSC (for relatively specialized use-cases).

Noting that as of April 2018, 20% of our non-headquarters site visitors at SFMTA.com, a public transportation website in San Francisco, are on Windows. Of that 20%, 86% are on Windows 10 (~17% of total visitors). Most of the remaining 14% (~3% of total visitors) are on Windows 7 (10% or ~2% of total visitors). Make of that what you will.