Accessibility: default auto bold font effect too weak (for custom CSS-linked fonts without bold variant shipped)
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: el, Unassigned)
Details
Attachments
(2 files)
Firefox auto bold effect vs Blink auto bold effect
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Steps to reproduce:
-
Download any font from Google fonts as a TTF, put it on a server reachable via HTTPS. Make sure to pick the "regular" variant as a single .ttf file and make sure to NOT pick any variable thickness or bundled variant
-
Add the font via CSS as a new font family by referencing the .ttf download and make sure to give it a custom made up font family name (so that it's not picked up from the local system and neither are any premade bold variants)
-
Use the font for text in a website and add strong or b tags for more font weight
Actual results:
The auto bold effect computed by whatever firefox uses for font rendering is way too weak, barely indistinguishable from the regular text. This is the case for almost all fonts no matter which. Even worse, all the blink browsers don't have this problem, so this means any custom effect like -webkit-text-stroke applied to counteract this will then suddenly make the text way too bold in all other browsers but not firefox. So this is both an accessibility and cross browser compatibility problem.
Expected results:
Regular and auto computed bold effect are sufficiently distinguishable like in blink browsers
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
Example shown in font-synthesis seems to corroborate this, especially switching between none and weight. Chrome seems to ship with the font used for the example, but WebKit seems more aggressive with its synthesized bold font.
I gave the font a strange font family name in the CSS and specified it via filename, so unless Chrome does some more extreme magic stuff it shouldn't have used the version that ships with it but rather used the synthesized bold. I did this to hopefully give a fair comparison.
|
||
Comment 4•2 years ago
|
||
The results vary quite a bit depending on platform, browser, screen resolution, and maybe other factors. There's no one "right" way to do synthetic bold -- there are various implementations, each with their strengths and weaknesses. We could "dial up" the boldness of ours a bit, but that would also tend to make it look more "smeared", which can be ugly.
This screenshot shows that in some cases, Chrome's version appears even "weaker" than ours; the boldness of the word "bold" is barely perceptible, to my eye.
Should I close this issue then? For what it's worth, for accessibility I feel like it might be preferable to err on the side of uglier but perceptible. Then again I guess if it's too thick then the gaps might become intelligible again. I understand this is a hard problem.
(Or maybe it might make sense to limit this issue to Linux? Is it possibly a Linux-only issue? I'm not sure which exact platforms would share the same or similar font rendering and which ones wouldn't.)
|
|
||
Comment 7•2 years ago
|
||
This wouldn't be Linux-only, I think, though the specifics of how things look may vary among platforms. But yes, it's a hard problem and I don't think there's a single ideal solution, just a bunch of trade-offs.
(For better accessibility, the "correct" thing for authors to do is to provide a real boldface font resource. That's also the right thing to do from a typographic-quality point of view, regardless of accessibility concerns.)
I suppose the question here, though, is whether we should (or can) do something in Firefox to improve the visual contrast for cases where the author has not done the "right" thing, and the user may therefore be struggling to see the distinction. Perhaps we can make the degree of emboldening a configurable setting, so that users can choose what level of distortion to accept in the interests of greater contrast.
Description
•