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 <https://chromium-review.googlesource.com/c/chromium/src/+/4809211> 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 <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/font_builder.cc;l=623?q=%22FontBuilder::CreateFont%22&ss=chromium> 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 <https://drafts.csswg.org/mediaqueries-5/#mf-user-preferences> 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 On Thu, Nov 9, 2023 at 5:46 PM Mark Schillaci <mschill...@google.com> wrote: > Title: > > Intent to Ship: Honoring Android OS-Level Bold Text Settings > > Body: > > Contact emails > > mschill...@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 > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/font_builder.cc;l=623?q=%22FontBuilder::CreateFont%22&ss=chromium>) > 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) > <https://drive.google.com/file/d/1Pn5MXkIcMluw716CUB0i8Ztk6iHnfNgm/view?usp=sharing&resourcekey=0-6mV47b3k5O01J_OgDy9h6g> > > 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > Progressed upstreamed. > > Link to entry on the feature dashboard <https://www.chromestatus.com/> > > https://chromestatus.com/feature/5145839765028864 > > Requesting approval to ship? > > Yes > > > > Honoring Android OS-Level Bold Text Settings > <https://docs.google.com/document/d/1lAvXGK8fV8LOsbcRB_KNaY3UXKG7JGSGKOKccSN5mws/edit?usp=drive_web&resourcekey=0-7pN6ICsESCR0hIbX-Dw74A> > > > > -- 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+unsubscr...@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.
