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

I think we should follow what https://github.com/browserslist/browserslist does with its defaults preset

Um, does anyone know what the numbers on https://caniuse.com/usage-table actually mean? It's a bewildering diagram with no explanation or guidance for how to read it. I'm lost.

The browser usage share among assistive technology users is markedly different to the whole population. I'd like to add these sources to the list:

• 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.
• WebAIM Survey of Users with Motor Disabilities (46 respondents, year 2013). At the time, Chrome hadn't yet achieved the dominance it has today, and IE still had 18% share among the population at large. Neverthless, the responses to this survey both put both IE and Firefox usage at least 10% more than their usage by the general population.

The WebAIM surveys are a much smaller sample size than the large-scale analytics you might get from StatCounter, Google Analytics, et. al.. The flip side of that is that the large-scale analytics don't offer any insight at all about how many users have a disability and/or employ assistive technology, let alone why they use that browser. So the WebAIM surveys are our best source of knowledge about that. (Indeed, there are very strong privacy reasons why that information should not be available to automated analytics, or developers in general.)

I hope we won't base our browser support policy on the whole-population usage figures.

I think to discuss the same topic repeatedly or re-defined the rules every few months or per year is not fun. It's the same as no policy! Maybe you need a new way to deal with the problems.

You could maintain a DrupalCare version with a slower release schedule. DrupalCare able to provide extra tools for screen readers and people with lower performance devices.

If Drupal sets a good policy, you will get a better DrupalCore also. IMO, this is not maintained 2 cores but 0.9 ~ 1.1 core. Uses the right resources on the right channels, improve the development flow.

One bad thing in DrupalCore, I found most contributors write code for DrupalCore only. We never thought about how to build an excellent decoupled component for (heavy) customized sites. Now you have 2 cores to care, it enforcing you to think, or at least provide a good reason for another developer to ban bad coding.
(this is why Drupal sites look like Drupal sites. Drupal has no beautiful sites. Code limited your imagine)

:)

EDITED: `bad coding` here meant sometimes we written optimal code for single DruaplCore only. Usually, code designed for multiple usages is slightly worse in many cases. So, sometimes trying to write/bring a less optimal code into CORE is less possible in my experiences.

Many people using old browsers are disadvantaged in the community. They all need helps. We need not look at single group reports exclusively. During the epidemic, a piece of news in my country reported a girl using her 5 years old low-end android phone for her remote school life and even can't download basic things.

Screen readers are asking for different things. For example, the layout is less important. Using CSS4 for themes is not an issue for screen reader but that's a problem for the above girl.

Some tools like CKEditor, I think it's not suitable for screenreader.

Screenreader on IE 10 has fewer issues than other IE10 users.

Note: JavaScript has builder now. And most Modern JavaScript things have polyfill.

Re. #10:

You could maintain a DrupalCare version with a slower release schedule. DrupalCare able to provide extra tools for screen readers

Are you suggesting 2 versions of Drupal core, or some sort of extended support release? That would be twice the maintenance work.

More to the point, which site owners are going to install it? If we relegate screen reader support to separate (or older) versions of core, I'd expect site owners to say "We don't need to worry about that, because disabled people aren't our target market". (We hear this a lot in the accessibility community. What it really means is they don't know their customers, and it's blatant discrimination.) I can't condone this approach for Drupal core.

Re. #11:

Given that Drupal 10 won't come out until mid-2022, while the absolute percentages are higher, the usage is still going down rapidly and looks like it will be negligible by the time we get to release.

Making choices based on past data is one thing, but making them based on what browser usage might be in the future is a risky supposition. What if the next screen reader survey shows IE usage levelling off, not dropping further? We know that IE usage is much higher among screen reader users; what we don't know is why. Users are only going to switch when another browser will suit their needs. Whatever has been keeping a larger proportion of screen reader users on IE, we can't assume that reason won't still apply in 2022.

Re. #12:

Screen readers are asking for different things. For example, the layout is less important. Using CSS4 for themes is not an issue for screen reader

That's nonsense, I'm afraid. Firstly, layout is important for screen reader users. Sighted people use screen readers, and the screen reader user surveys (in #8) suggest this might be as high as a quarter of screen reader users. Some people use a screen reader in combination with a magnifier, and/or have enough vision to appreciate layout. Other people have no visual impairment, but use a screen reader to assist with dyslexia. If there's a mis-match between visible layout and the order a screen reader announces content, that can be very confusing. Secondly, CSS does have an effect upon screen readers. For example some buggy implementations of display: contents have removed the semantics which are passed to assistive technology. Careless use of flexbox order can result in a very confusing tabbing order.

Some tools like CKEditor, I think it's not suitable for screenreader.

There's some truth here. Many rich text editors have been a poor experience with a screen reader. CKEditor isn't perfect, but it's one of the best for screen readers. The CKEditor project takes accessibility seriously, and have carried out their own testing. When we chose CKEditor, it was the editor with the best screen reader support, and that's still the case AFAIK.

Screenreader on IE 10 has fewer issues than other IE10 users.

I don't know what you're referring to here.

That's nonsense, I'm afraid. Firstly,

You're talking about the common case. I'm talking about the Drupal upgrade (with my prediction). Your example does not fully fit into this issue.

Acutally, your answer extending my word further, most of them asked for different things (in the common case). You skipped mentioning that they can use screenreader on a wired layout while non-screenreader failed to use the same website with a mouse. (for example, overlayed.)

When IE 11 is dropped. The damage for the above girl I mentioned (all 1%) is more than screenreader you mentioned. (This is my main point)

Good points about CKEditor 5 in #14. I haven't looked at v5 much yet, but it sounds like that will likely force our hand. So it goes.

I don't understand #15. I don't think the girl is more important than a screen reader user. I'm not interested in favouring one user above another.

What's the use-case for still supporting IE11 in Drupal 10? Edge is now available for Windows 8. You can configure Edge's IE mode to use IE11 rendering for just the sites that need it, which no Drupal 10 site (or for that matter, even Drupal 9 site) should need.

For people who can't use Edge on Windows 8, why not? And if there are such people, then Windows 8 itself goes EOL in January 2023 and Drupal 9 will be supported until Nov. 2023, so sites wanting to cater to them can delay their D10 upgrade until after Windows 8's EOL.

So after January 2023, that only leaves people on Windows 10, where Edge is the default browser, but people explicitly choose to use IE11 instead, instead of using Edge's IE mode. Are there any legitimate reasons to make such a choice?

I hope we won't base our browser support policy on the whole-population usage figures.

I agree with this. I think we need more heuristics than just whole-population usage. Here's a draft proposal for possible heuristics...

If we're already supporting a browser (e.g., IE11), then we shouldn't remove support so long as any one of these conditions remain:

• Whole population usage is >1%.
• It is the default browser for an operating system or device that is still security supported (e.g., IE11 is the default browser for Windows 8, which is security supported until January 2023).
• There remains a compelling reason to use the browser for a protected group (e.g., https://en.wikipedia.org/wiki/Protected_group or similar list that's defined by other countries). For example, if IE11 enables better accessibility (does it?) than other browsers, we should probably keep supporting it, until other browsers catch up. Or, if IE11 is the best browser for cheap phones (is it?), then we should probably keep supporting it until some other browser is an equally good option for such phones.

However, with Drupal 9 supported until November 2023, if we can reasonably expect whole population usage of IE11 to drop below 1% before then, and we already know that by then it will no longer be the default browser of any supported OS or device, and if it's already the case (or we can reasonably expect it to soon be the case) that it doesn't offer any accessibility advantages (or other advantages for any protected group) over other available browsers, then I think us making the decision to drop it from Drupal 10 makes a lot of sense, and everyone would be best served by us deciding that and communicating that with plenty of lead time.

#17

no problems.

But if you realise the facts, you can figure out the important part and focus your limited resources on that when the dropping is happening. And slowing down the Drupal to drop some parts. Upgrading browsers never meant you have to use all new features.

#18
Many scripts does not designed for IE Mode. The complicated layout has very low performance in IE Mode. And many sites will crash (hanging) in IE mode but work well on the native IE. And more important: General users don't know what is IE Mode. (I'm a IE bugs killer since IE6)

And many sites/libs are supporting IE11 but dropping Edge, LOL

For anyone who doesn't know, running IE on low-end PC is smoother than all other browsers!

End users are not developers. When they visit a broken site, they think: Oh! Your site is broken.
Developer: Oh. I switch to Chrome. Oh, Chrome crash, I will try Firefox.
They will not switch until a new PC upgrade, no more IE11. Or someone warning them: Your bank account will be stolen... (Then, they only not to use IE on bank sites)

And for the screenreader, they don't know and don't care about the layout error as I told in the above comments. In most cases, only scripts error affected them. They have lower momentum than others to make the change.

If script error on "SHOW MORE", non-screenreader is switching their browser but screenreader won't.
https://giphy.com/gifs/dzCLO2QXjToeSoOc0z

Re. #18:

Edge's IE mode may not be the same as actual IE11 as far as assistive tech is concerned. It may be the old Trident rendering engine, but it's wrapped by a different application. On Windows, there are 2 ways that assistive tech gets information from a web browser. In practice, they use a mixture of information from both methods:

• Via OS-level accessibility APIs. This is the more modern method.
• The assistive tech hooks directly into the browser process, and grabs the DOM. This is the older method; it's still widely used for a couple of reasons. Firstly, to make up for deficiencies in browser implementations of the accessibility APIs. Secondly, it also lets assistive tech get some information which isn't provided by accessibility APIs yet.

For the in-process approach, assistive tech needs to have separate code for every browser it wants to integrate with. I don't know a much about how this works in practice, but I wouldn't assume that hooking into actual IE11 will be the same as hooking into Chromium Edge. Even if Edge is in IE mode, it doesn't mean that the assistive tech will be able to extract information the same way they do from actual IE11. I don't know the current status of whether assistive tech is even allowed to hook into Chromium Edge; I recall that Microsoft wanted to clamp down on this with the non-chromium Edge.

Re. #19:

Those 3 conditions sound like a good start.

I'll try to find out more about the reasons why IE11 has a bigger usage share among assistive tech users. I suspect workplace disability assessors will have more insight about this than developers do. Some assistive tech is scriptable, so one possibility is that there are a lot of JAWS scripts out there which would need re-written for other browsers.

For example, if IE11 enables better accessibility (does it?)

Maybe so, given that various assistive tech has a lot of IE-specific stuff from hooking directly into the browser process. It's kind-of like a quirks mode for assistive tech.

https://labs.levelaccess.com/index.php/Assistive_Technology_Browser_Comb...

I think the browser support policy should not be based purely on usage statistics. Another important factor to consider is how much effort required to support a particular browser.

I'll try to find out more about the reasons why IE11 has a bigger usage share among assistive tech users

various assistive tech has a lot of IE-specific stuff from hooking directly into the browser process. It's kind-of like a quirks mode for assistive tech.

@andrewmacpherson were you able to find any examples of assistive tech that had a hard dependency on IE11 ? Or any reasons why IE11 might have a larger usage share?

According to https://webaim.org/projects/screenreadersurvey8/#browsercombos, IE does not have a large usage share with NVDA, only with JAWS. Even on JAWS, even though a lot of users are using IE, more are using Chrome. Also, this survey was prior to Chromium Edge getting rolled out to Windows as the default browser. Meanwhile, https://www.freedomscientific.com/SurfsUp/MicrosoftEdge/Overview.htm now says:

JAWS offers all of the same powerful web navigation features in Edge Chromium that are available in other supported browsers like Chrome, Firefox, or Internet Explorer.

There's a webinar audio with more details, but I haven't listened to it yet.

Maybe, per #21, there are still some advantages to IE over Chrome or Chromium Edge, but I can't find any that are highlighted on https://www.freedomscientific.com/.

Revert vandalism https://www.drupal.org/project/site_moderators/issues/3276540

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.

• caniuse
• statcounter
• 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 Chromium 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.

#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, #3510387: Replace "Opera Mini" with "Opera Mobile" in supported browsers fits with these heuristics.

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.

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...

I checked with @lauriii in committer slack and they confirmed that they agree with this change.

Assigning to myself to come back after the releases are made.

Edit: s/@larowlan/@lauriiii/

I updated credit.

This needs confirmation that the new doc page agrees with the proposed resolution.

I added a sentence about needing a core issue that should cover #61. See https://www.drupal.org/node/3525067/revisions.

Since catch confirmed the new doc is OK I changed the status on it to 'no known problems'.