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 On Fri, Nov 10, 2023 at 4:12 PM Dominik Röttsches <dr...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBu6CvMWnQWJ_Li_ik0UwvWZtVv%2Bbf1M5G_SHdQYKGZBCw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAARdPYeqGaUJ_5VNV2x0hHL%2B6Qf%3D3qwuSrEMW--m%2BhrW2BaerA%40mail.gmail.com.