I think accumulating the rectangles of children seems like a good option if we need to report a bounding box. It sounds like that's something else where I need to test, and possibly change, our current behavior for elements with display:contents.
Regarding focus outlines: these elements won't draw focus outlines. This is definitely a tradeoff. As I wrote in https://github.com/WebKit/standards-positions/issues/164#issuecomment-1708822339 : So I think my preference for outline is that we say that if a developer is going to depend on focusability of something with display: contents, they need to add appropriate styles to draw the focus outline (for example, by drawing it on an appropriate descendant or descendants). I admit that developers aren't going to get that right all the time. But the same is true of the current situation. That is, I think developers will sometimes not do what we want if we say either of: - developers shouldn't use display: contents if they need an element to be focusable, or - developers should add appropriate focus styles if they use display: contents on something that is focusable. (Note that needing an element to be focusable is often a need for users using keyboard navigation or similar, that may not apply to users using a mouse. So developers may well miss it.) Then the question is which problem is worse: is it worse to have an element that the user needs to get to but that can't be focused at all, or worse to have it be focusable but without a good indication that it's focused. The latter at least gives a keyboard user a chance to figure out what's going on, whereas with the former they're out of luck. So my inclination is that having the element be focusable but without an indication of focus is less bad than having it not be focusable at all when it should be. I admit that this is just my instinct and I haven't attempted to confirm this. And there's also the confounding factor that the two problems might occur at different rates. -David On Tue, Jan 9, 2024 at 11:46 AM Aaron Leventhal <alevent...@chromium.org> wrote: > And (duh to myself), we need to compute a bounding box for our own focus > outline. > > Apologies if this is answered elsewhere. > > On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal <alevent...@chromium.org> > wrote: > >> Interesting. How will the bounding box be reported via a11y APIs? >> >> Examples of where this is used: >> 1. ATs for low vision users that draw a box around the focus and/or move >> the focus onscreen (especially for a magnifier that is only showing part of >> the actual screen's contents in a virtual viewport). >> 2. Voice Input: used to show numbers next to the item when several things >> have the same name, e.g. a bunch of links labelled "click here". >> 3. Single switch ATs: for highlighting an item that the user can select >> >> One answer might be to accumulate the rectangles of all children and to >> use that. Not sure what the algorithm would do for out-of-flow children. >> >> Aaron >> >> On Tue, Jan 9, 2024 at 11:39 AM David Baron <dba...@chromium.org> wrote: >> >>> Contact emailsdba...@chromium.org >>> >>> ExplainerNone >>> >>> Specification >>> https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770 >>> >>> Summary >>> >>> This change means that elements that have CSS display:contents can be >>> focusable. In other words, if they would have been focusable without >>> display:contents, display:contents will no longer change that. Before this >>> change, elements with display:contents could never be focused. Developers >>> making elements with display:contents that can be focused need to ensure >>> that such elements have appropriate styles to make the focus visually >>> apparent, since they will not have a default focus outline. >>> >>> >>> Blink componentBlink>HTML>Focus >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EFocus> >>> >>> Motivation >>> >>> Elements with display:contents are exposed to assistive technology as >>> having their normal roles (as though they had their default display). The >>> contract for the meaning of accessibility roles includes support for >>> certain role-specific keyboard interactions which often include >>> focusability. So it's important that the exposure to AT match the >>> focusability. The CSS Working Group has concluded that both AT exposure and >>> focusability should be as-normal. Prior to this change, AT exposure was >>> interoperably as specified, but such elements were interoperably not >>> focusable. >>> >>> >>> Search tagsCSS <https://chromestatus.com/features#tags:CSS>, a11y >>> <https://chromestatus.com/features#tags:a11y>, accessibility >>> <https://chromestatus.com/features#tags:accessibility>, focus >>> <https://chromestatus.com/features#tags:focus> >>> >>> TAG reviewNone >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> This is proposing to change a currently interoperable behavior. This has >>> some risk that other engines won't match the change and we'll end up with >>> less interoperability. However, I think there is probably enough support >>> from other engines at this point that we should take the lead and hope that >>> other engines will soon follow. >>> >>> >>> *Gecko*: Positive ( >>> https://github.com/mozilla/standards-positions/issues/772) >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/164) No official >>> position but https://github.com/web-platform-tests/interop/issues/568 does >>> show Safari interest in the topic. >>> >>> *Web developers*: No signals >>> >>> *Other signals*: Positive advocacy from users / user advocates such as >>> in https://bugs.chromium.org/p/chromium/issues/detail?id=1366037 and >>> https://github.com/web-platform-tests/interop/issues/568 >>> >>> Activation >>> >>> This fixes what appears to be one of the obstacles for developers to use >>> display:contents in a way that is accessible. While in the short term it >>> reduces interoperability (since engines agree on the current "bad" >>> behavior), the long term goal is that engines will converge on the new >>> behavior, and this will lead to increased developer confidence in and >>> increased usability of CSS display:contents. >>> >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Debuggability >>> >>> None >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)?Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> https://github.com/web-platform-tests/wpt/pull/39247 >>> >>> >>> Flag name on chrome://flagsNone >>> >>> Finch feature namekDisplayContentsFocusable >>> >>> Requires code in //chrome?False >>> >>> Tracking bug >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1366037 >>> >>> Estimated milestones >>> >>> No milestones specified >>> >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> None >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/6237396851228672 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/> and edited by hand. >>> >>> -- >>> 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/CAG0MU3irORkF9G%3Dkr-KJF0hvoYbTpdpmYordQ1qi6w3s2jd5Fw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3irORkF9G%3Dkr-KJF0hvoYbTpdpmYordQ1qi6w3s2jd5Fw%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/CAG0MU3gOw1Bmzv0mVsA-PeYRyJDRWYEgShedyErcktooY0jovw%40mail.gmail.com.
