A few notes from what I've experienced a few months ago while exploring the idea of modernizing typography choices:

• Users have widely differing preferences, therefore I've moved to a user preference based approach detailed in T244748: Add client-side skin preferences drop-down
• "One size fits all" is not possible in this area. It seems previous advancements - most notably Typography refresh in 2014 - however well researched, left negative feelings in some people involved and made typography a topic that's approached with a lot of doubts and unease, or without discussion with the community (T250393).

I think the default font-size for readers should be 16px as typical for long-read format websites, editors on the other hand probably prefer the status quo 14px. This should be a user choice presented in a convenient way (not in the Preferences page). Having that choice, the usage ratios could be measured and - if popular enough - 16px might be made the default.

Change 609797 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [DEMO] Font update: Use default 16px article font-size in Vector

https://gerrit.wikimedia.org/r/609797

@Iniquity How 16px font-size would look:
DEMO with old layout
DEMO with new layout (unfinished)

@Demian thanks for the demo! :) Looking at example, it seems to me that the headings should be brought in accordance with the https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles.

I also think that as one example, we should use T246420 layout :)

From an overall Design, usability and Style Guide perspective a clear yes to increase the font size to 16px equivalent 1em! Details to be evaluated.

In T254055#6324701, @Jdlrobson wrote:

I also wonder if the only blockers are community consultation whether there is anything @Iniquity could do to help us (e.g. see on village pump whether this would be controversial)

Yes, community consensus I think will be the biggest problem for this change. I have already spoken to some of the members and received mixed reviews: old editors work in a very peculiar way with the font, some increase it by browser's scale, some say that it is more convenient to read a small font. We can prepare a survey (with information about [https://pielot.org/pubs/Rello2016-Fontsize.pdf | readers expireince]) and distribute it via Tech-Ambassadors, for example.

Change 609797 abandoned by Jdlrobson:
[mediawiki/skins/Vector@master] [DEMO] Font update: Use default 16px article font-size in Vector

Reason:
Demo no longer being used,253 days old and no activity on phabricator since November.

https://gerrit.wikimedia.org/r/609797

@ovasileva @Volker_E do we plan to do this for new Vector? If not, I fear it's not going to happen. Perhaps the way to look at this is to provide a user preference for default font-size, possibly one that applies to logged-out users as we do in Minerva. That should mitigate the need for community consensus as I assume we have good data to backup why font size change is warranted.

The font-size mismatch in Vector does continue to cause us product debt IMO - for example in icons, the size of which are currently tied to it.

Not only in icons, in all components or things like em-based layout sizing we have to provide specific overrides between desktop and mobile. See Figma WikimediaUI file https://www.figma.com/file/2Jb1lVkhEMDFxO20I5xwyA/WikimediaUI-%E2%80%93-Components-library?node-id=4%3A2425
This is a design and UX debt that trickles down into development and continues to be a high cost.

@Jdlrobson could you expand on the user grouping for the Minerva user preference? Who does what apply to when?

@IKhitron Would you mind sharing your dismissal of this idea here?

Two immediate concerns for this (not ‘issues’, as I have no issue with increasing font size):

1. Vector will be even more mismatched from other skins (notably Monobook) than before, since even now Monobook has old font size one pixel smaller and will have font size three pixels smaller. This mismatch might be problematic in various design decisions made by the end-users. I suppose there’s no way a new font size increase would touch all skins at once, either.
2. If font size gets increased, already small content frame in new Vector (as seen on main pages or even regular articles with infoboxes) will get even smaller. So, obviously, you would need to increase content width as well with this change, otherwise it would be bad to do.

In T254055#7117368, @Volker_E wrote:

@IKhitron Would you mind sharing your dismissal of this idea here?

Sure. From my experience, it makes eyes to hurt.

In T254055#7117475, @stjn wrote:

Two immediate concerns for this (not ‘issues’, as I have no issue with increasing font size):

1. Vector will be even more mismatched from other skins (notably Monobook) than before, since even now Monobook has old font size one pixel smaller and will have font size three pixels smaller. This mismatch might be problematic in various design decisions made by the end-users. I suppose there’s no way a new font size increase would touch all skins at once, either.

On the other hand it would be more consistent with mobile Minerva skin.

2. If font size gets increased, already small content frame in new Vector (as seen on main pages or even regular articles with infoboxes) will get even smaller. So, obviously, you would need to increase content width as well with this change, otherwise it would be bad to do.

Why would these get smaller? Surely a font size bump would lead to all font sizes increasing?

In T254055#7117536, @Jdlrobson wrote:

On the other hand it would be more consistent with mobile Minerva skin.

That is true, but unless you are also prepared to do typeface changes, for most users on Windows the fonts will not look the same size as Segoe UI and Arial have different metrics.

In T254055#7117536, @Jdlrobson wrote:

Why would these get smaller? Surely a font size bump would lead to all font sizes increasing?

Smaller as in ‘even less information will fit in the content width’. If that is not what would happen, then this is not a concern.

While this is a bit offtopic, what should be uncontroversial is increasing the font sizes of the interface of Vector itself. Sidebar, footer, personal links have barely legible font sizes by the modern standards, which were not increased with Typography refresh in 2014, and would benefit from an increase, both from the legibility standpoint and the usability standpoint (it is only my hunch but I think that part of the reason people use non-content site elements a lot less is because they are so small they can be ignored by readers by default).

In T254055#7116601, @Jdlrobson wrote:

@ovasileva @Volker_E do we plan to do this for new Vector? If not, I fear it's not going to happen. Perhaps the way to look at this is to provide a user preference for default font-size, possibly one that applies to logged-out users as we do in Minerva. That should mitigate the need for community consensus as I assume we have good data to backup why font size change is warranted.

The font-size mismatch in Vector does continue to cause us product debt IMO - for example in icons, the size of which are currently tied to it.

We have had some discussions on introducing font size preferences in the last stage of the project. And just to confirm, a font size increase on new vector would mean and increase in the width of the article content. @alexhollender - for the time being, perhaps we can set up the epic for aesthetic refinements and file this as a subtask?

I'm just going to note here that much of the 'discord' about font size and font style comes back to a conflict of readability/accessibility for more casual users vs. information density and efficiency for experienced and highly engaged users/editors/curators.

This is a side effect of how people with different purposes interact differently with these pages. Readers don't know 'where' they are, so are much more likely to go left, right, top to bottom through an article, at most using headings to 'scan'.
Curators/Editors are experienced with navigation and not there to consume the article information in the same way. They take an overview/scan of the entire page and then mentally zoom into a specific area much faster. Being able to see as much of the entire article in one go and having easy access to as many controls as possible is an elementary part of their mental navigation model and efficiency. (It is also why gmail has a much higher information density than most other Google products.)

This is an essential dynamic we have identified multiple times in the past. It should be part of our design principles.

@ovasileva I'm not sure we should leave this to the end of the project. The font-size discrepancy continues to cause us problems as we implement designs - in fact we're often adding hacks to override it, which is increasing the work we have to do later in the project. Please consider doing it earlier. I don't think this is as controversial as it has been pitched - in fact recently there was a village pump discussion requesting this for legacy Vector.

It's also a clear accessibility improvement, so we might want to consider it as part of the upcoming accessibility sprint we have planned.

I applied the following CSS in my browser. They make Wikipedia much more readable.

.vector-body {
    font-size: 1rem;
    line-height: 1.5;
}

.vector-body p {
    margin: 1em 0;
}

Before	After

Please also increase the margin between paragraphs.