PSA: Web contents will honor the Android OS bold text setting

[Mark Schillaci]

Title:

Intent to Ship: Honoring Android OS-Level Bold Text Settings

Body:

Contact emails

mschi...@google.com, dr...@google.com

Explainer

Help users who need more contrast in their fonts for increased readability, by adding support for a new Android a11y API that opts into text being always bold.

Spec

No formal design doc

Relevant CL: crrev.com/c/4809211

The FontBuilder::CreateFont method (link) will include a call to a new method, FontBuilder::UpdateWeightAdjustment (see CL). This adjustment will be added to the current font weight and clamped to the min/max weight values for that font. The font weight adjustment can be any number; but with the current Android OS it will be 0 by default (no bolding), or 300 when a user has enabled bold text. For example, a font with weight 400 would become weight 700 when the user has enabled the OS-level setting. This will apply to all elements on the web.

Summary

The Android OS has an accessibility option to enable “Bold text”. When enabled, all content rendered by Android will be in bold. We intend to make this user setting affect web contents in addition to the native OS widgets.

Supporting Links

No formal explainer doc

Configuration.java: https://developer.android.com/reference/android/content/res/Configuration#fontWeightAdjustment

Android 12 announcement: https://www.android.com/android-12/

Google support page: https://support.google.com/accessibility/android/answer/11183305?hl=en

Demo link

Video link (Alphabet internal)

Screenshots of the feature enabled without and with bold text user setting:

 

Motivation

This is an accessibility feature, and we want parity between the web and Android OS.

Risks

Interoperability and Compatibility

No interoperability or compatibility risks as this is an Android only feature. This will not run on any other platforms.

Solving the intended problem

See demo.

Ergonomics

This feature is likely to be used in parallel to text size scaling or page zooming, since both are intended to assist low-vision users.

Activation

No

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, this is an Android only feature. It is controlled by a setting that is only available in the Android OS-level settings.

Is this feature fully tested by web-platform-tests?

Progressed upstreamed.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5145839765028864

Requesting approval to ship?

Yes

 Honoring Android OS-Level Bold Text Settings

[Dominik Röttsches]

Hi Mark,

Thanks for sending this and for the summary you made for plans of upcoming a11y integrations to web content. In my view, there's more to discussion needed.

I understand the desire to transfer an Android a11y feature to the web and make it available seamlessly in the browser, as well. Thanks for providing the background and examples. The subject should probably be prefixed with "Intent To Ship" to highlight it for review by API owners.

You're describing the implementation as interfering after style resolution and building and modifying all FontDescriptions with font weight increased uniformly by 300.

Let me surface a couple of concerns here that we touched upon in the CL you uploaded and in discussion with pdr@. 

1. Availability of font weights: There are differences in availability of bolder weights in web content compared to user interfaces in Android, when bold or black weights are not provided by the page. In Android, the system UI fonts are provided by the OS. I am not sure what the default UI font on Android is atm, but the OS has control to provide them as a variable font with a wide weight range, or provide even a black (weight 900) weight.
   While this feature may look reasonable on system UIs, as bold and black fonts may be available, on web content this may lead to two less desirable situations:
• Synthesis or lack of bold font: A bold weight is not available for a web font, as the page has not included one: font-synthesis is applied, or if font-synthesis: none; is specified in CSS: no synthesis occured and bolding does not show. 
• Loss of bold semantics: Text is already bold, then the bolding adds 300 weight, requesting a black font weight, which is not available. For that, we don't do synthesis, so the distinction between regular text and bold text is lost. 
2. Observability in web content: Contrary to other a11y features like zoom, this change would actively modify the DOM and potentially break assumptions authors made about their content. Reading the computed style of the element would not match the style as specified by the author anymore - it would be a somewhat magic DOM change.
   
3. Detectability and opt-out: With a couple of other accessibility related features, for example a user's preference for reduced motion, dark or light mode, high contrast etc.  there are media queries to detect these. Authors can then design for that request. Such a detection affordance I find missing from this proposal.
4. Interoperability: It's not ensured that other browsers, for example FF on Android, would apply and implement the system setting in an identical way, leading potentially to a different resulting page. It would then become hard for page authors to still achieve a consistent user experience of their site, as the page appears different in each browser.
5. Utility in different languages: Granted, as this is a system setting, this is ultimately up to the user: but for multilingual users reading content in different scripts, for example an alphabetic and an ideographic script, this may not be ideal, as ideographic scripts may not necessarily become easier to read when bolded. Bolding could be applied selectively per :lang attribute if there was a media query.

Since you're explaining that there is no design doc for the Android side change, I am still curious about the original motivation: 

1. Do you have any research findings regarding user trials of this feature showing the legibility benefit? 
2. Do we have any use data: Of the user population that has access to this feature, how many are activating it?
3. Is there any feedback from app developers on this?

I am by no means an a11y expert but I would propose to synchronize this with the CSS working group and the accessibility working group. 

As an alternative, perhaps we can introduce prefers-bold-text media query, and maybe have a default in the user agent stylesheet that sets the body element's font-weight to bolder if the hypothetical prefers-bold-text media query is matched.

Dominik

[Philip Jägenstedt]

Hi Mark,

There is certainly precedent for supporting OS-level settings like this, and doing it is important for the users who use the settings and expect consistent experience. As Dominik notes, most such modes are detectable, and for some the page can react to the preference using prefers-* media queries. (I think it depends on whether we want pages to have the power to override the preference, or merely detect it.) To ship something that is observable in style or layout but that doesn't have usual detection/control would make this less predictable for web developers. We would be forced to address the problem sooner or later, so I'd recommend doing it up front.

An Intent to Ship is the right path to take eventually, and you would start that from chromestatus.com. However, I think the first order of affairs is coming up with a proposal for the detection and/or opt-out should look like, presumably a media query. I'll reach out in private and suggest next steps.

Best regards,

Philip

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBu6CvMWnQWJ_Li_ik0UwvWZtVv%2Bbf1M5G_SHdQYKGZBCw%40mail.gmail.com.

[Rupert Wiser]

Hey Mark,

I wanted to check if this includes WebView and if that will operate the same as Chrome?

Relevant WebView doc: https://chromium.googlesource.com/chromium/src/+/main/android_webview/docs/web-page-layout.md

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.