I think such a console error sounds like a reasonable idea, but I'd need to dig in to see how hard it would be to do.
-David On Tue, Jan 9, 2024 at 2:59 PM Aaron Leventhal <alevent...@chromium.org> wrote: > WDYT about a console error in developer tools when there is no focus rule > applied? > > On Tue, Jan 9, 2024 at 2:56 PM David Baron <dba...@chromium.org> wrote: > >> I think in theory it might make sense for focus outlines to use something >> like an aggregation of child bounds. (The specifications even allow focus >> outlines on regular elements to expand to contain the bounds of children.) >> >> However, in the case of display:contents, it would be hard to implement >> in all browser engines (need to figure out responsibility for painting and >> invalidating it), hard to specify (need to describe how it interacts with >> visual effects... and also implement that interaction), hard to explain to >> developers (doesn't fit with the normal model around how outlines are drawn >> and how display:contents works), and probably hard to get standards >> consensus around (for those same reasons). >> >> So my current preference is to allow display:contents elements to be >> focusable and to make visual indication of the outline the developer's >> problem (but perhaps still somewhat discourage having to go down that path). >> >> -David >> >> On Tue, Jan 9, 2024 at 12:49 PM Aaron Leventhal <alevent...@chromium.org> >> wrote: >> >>> Would an option for focus outlines to be to use the same idea we're >>> discussing for AT bounding boxes? Namely, to use an aggregation of child >>> outlines? >>> >>> On Tue, Jan 9, 2024 at 12:33 PM David Baron <dba...@chromium.org> wrote: >>> >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gOw1Bmzv0mVsA-PeYRyJDRWYEgShedyErcktooY0jovw%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/CAG0MU3iCxUjKipVmEttqAMF1ZHvc%2BfK734cK5jg9zHeoqW8EMg%40mail.gmail.com.
