[policy, no patch] Define usage heuristics for browser support

This only really becomes critical when we want to add or drop support for a browser, in between, we forget about it hence lack of activity here. Next time adding or dropping a browser comes up I think we should postpone that on this issue, but for now moving to major.

there have been two webaim surveys since this was last updated, so linking the new one. https://webaim.org/projects/screenreadersurvey10/

We didn't make any changes to the supported browsers for Drupal 11 because there were no pressing trends (and we already dropped IE), but it would be nice to get this closed out so if something does get notably more or less popular in the next couple of years, we've got some guidelines on how to approach it.

I gather this will be a new policy page in the ' Core change policies' → guide.

My first pass at that text is

Introduction

Browser support determines which bug reports are accepted. It also determines which third party libraries are adopted and influences when those libraries are removed. Trend data is used because the decision about third party libraries is made months or years in advance of a major release.

Dropping a browser

Support for a browser is dropped when the following conditions are met.

1. The browser is on course to drop below 1% global usage by the time of a major release.
2. The browser has insignificant screen reader usage or a solid downward usage trend as shown by the latest webaim screen reader survey.
3. If the browser is disproportionally included in the lastest webaim screen reader survey, then it should not be providing a specific technical reason that makes it better for accessibility.

Support is removed in advance of the next major release. This allows dependencies and core code to operate on the browsers that will be supported for the duration of that release.

Adding a browser

A browser is added when either of the  following conditions are met.

• It is on course to increase above 1% global usage, has significant (>30%?) market share in particular geographic areas.
• It is disproportionately and steadily or increasingly used by screenreaders, 
• If the browser is disproportionally included in the lastest webaim screen reader survey, then it should be providing a specific technical reason that makes it better for accessibility.

References

The following are used to evaluation browser adoption.

• statcounter
• caniuse
• lastest webaim screenreader survey
• Hopefully, add a good source for geographical browser usage, in case a specific browser is very highly used in particular countries.

There are two points that need to be taken into considerations.
1. We live in epoch of "always green" browsers. Vendors continuously push new browser releases. It would be hard to manually evaluate available browsers each major release of Drupal.
2. There is a variety of chrome based browsers. We probably need to establish the support policy based on on the version of Chromium engine.

That was already mentioned in #7. I think the evaluation of browser adoption can be done through through browser list.

Would be good to make more progress here, I think #41 is good, we could go with that and tweak it later if necessary?

Just opened 🌱 Re-evaluate opera mini support Active .

#41 looks good to me, but two of the links (caniuse and statcounter) have had their href's swapped.

I updated the links in #41. There are no objections here so RTBC.

Do we have a list somewhere on what browser would be supported under the proposed heuristics?

@lauriii, not that I know of. Although, 🌱 Re-evaluate opera mini support Active fits with these heuristics.

Yes 🌱 Re-evaluate opera mini support Active is the only known change to the current browserl ist.

Opera mini is below 1% (0.04%) on https://caniuse.com/usage-table and it's still in the supported browsers list.

Opera Mobile is above 1%, but it's not in it. More on 🌱 Re-evaluate opera mini support Active .

@effulgentsia asked stats questions on #3510387-9: Replace "Opera Mini" with "Opera Mobile" in supported browsers → which I have tried to answer in the two comments after that one.

The short version is that with Opera Mini, it shows as 0.05% usage globally, but in Kenya, which has the highest sample size of countries that also have highest Opera Mini usage, it's hovering around 5%. Or in Nigeria down from 5% to 2.5% in the past couple of years.

I think we could add something like this:

"If a browser has disproportionately high usage in a specific region, then it can be removed if the usage on course to be below 5-10% in countries in that region by the time of the next major core release. One source of this data is regional statcounter reports."

This would then match the regional 30% language in 'adding a new browser'. I think it's probably good to have a gap between the threshold for adding a browser and the threshold for removing one, they shouldn't be too close otherwise it could lead to unnecessary churn.

Back to needs review for that bit. Should we move the suggested text into the issue summary too?

Sure, I'll put it in the issue summary.

I replaced the proposed resolution with the suggested text from #41 and the new paragraph from #51. The latter was modified for plain English and to fit the style of an item list.

Add 'countries' into the proposed text, which I missed.

All good for me, critera makes sense.

With what's going on with chrome/google in the US and the AI turn everything is taking we might not need this for a while but it's good to have it laid out.

I think this looks great. Few comments that would be great to address to make sure that it's clear how this guidance should be applied:

1. Can we add a reference for geographical browser usage? If we don't have one, I don't think we should include it in the heuristics.
2. Can we define specific thresholds for when we would we consider a browser is disproportionally used by screenreaders per webaim screen reader survey?
3. Should we add guidance on how browser versions are handled? If they follow the existing policy, we could drop support for previous major of Safari for example.

#1. I've updated the statcounter link to go directly to https://gs.statcounter.com/browser-market-share, which includes regional filters by continent and country along with a short mention. I think it's good to link to the resources we know about, but don't think we want to be comprehensive/prescriptive here in case something better shows up.

#2. I had a look at the most recent webaim survey to see if there was an example.

https://webaim.org/projects/screenreadersurvey10/#browsers

This shows Firefox at 16% and Edge at 19%, whereas if we look at the last month's global data on statcounter:

https://gs.statcounter.com/browser-market-share/desktop-mobile/worldwide...

Firefox is at 2.5% and Edge is at 5%

So I've added "(e.g. more than 10-15% stable usage when global usage is under 1%)".

The 'stable' in there is so that the 'downward trend' above can take precedence, this was part of the considerations for dropping IE11 support iirc because it was clearly on its way out in successive webaim surveys, if still disproportionately used.

Stable 10-15% usage isn't a hard number (and we could change it to a different number), it just means we would need to put some effort into understanding why a browser is disproportionately and consistently used over the years before dropping support for it.

#3. I started writing a comment saying I think versions is already covered in https://www.drupal.org/docs/getting-started/system-requirements/browser-... → , but then I realised that doesn't cover how we decide which browsers get two major vs. only latest major version covered. So yes, we probably do need something.

I've added:

In general, desktop browsers are supported for their two most recent major releases, and mobile browsers are supported only for their most recent release. See https://www.drupal.org/docs/getting-started/system-requirements/browser-... → for details of current support.

I think we'd need a good reason to deviate from that for a specific browser, firefox ESR and safari mobile are the only two deviations we have, not sure we can get around discussing special cases like that.

I think that hopefully addresses the feedback, going to be bold and self-RTBC the changes since they are pretty minimal in the scheme of things.

Thanks for the udpates catch.

Although @lauriii hasn't responded this seems close enough to agreement that I went ahead and created the policy page with the current text from the issue summary. It is not yet in the menu of the guide it is in. https://www.drupal.org/about/core/policies/core-change-policies/supporte... →