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
On Friday, November 10, 2023 at 5:05:22 PM UTC Philip Jägenstedt wrote: > 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/c4a801dc-da17-45d3-8875-48de886474e1n%40chromium.org.
