Intent to implement and ship: Allow elements with CSS display:contents to be focusable

[David Baron]

Contact emails

dba...@chromium.org

Explainer

None

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 component

Blink>HTML>Focus

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 tags

CSS, a11y, accessibility, focus

TAG review

None

TAG review status

Not 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?

Yes

https://github.com/web-platform-tests/wpt/pull/39247

Flag name on chrome://flags

None

Finch feature name

kDisplayContentsFocusable

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 and edited by hand.

[Aaron Leventhal]

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

--
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+...@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.

[Aaron Leventhal]

And (duh to myself), we need to compute a bounding box for our own focus outline. 

Apologies if this is answered elsewhere.

[David Baron]

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

[Aaron Leventhal]

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gOw1Bmzv0mVsA-PeYRyJDRWYEgShedyErcktooY0jovw%40mail.gmail.com.

[David Baron]

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

[Aaron Leventhal]

WDYT about a console error in developer tools when there is no focus rule applied?

[Yoav Weiss]

On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote:

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770

Is this actually defined in the spec? Should the spec be more explicit about it?

 

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

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, a11y, accessibility, 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.

What about compat? Would existing users of `display: contents` have their keyboard flows disrupted by this change?

 

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?Yes

https://github.com/web-platform-tests/wpt/pull/39247

Flag name on chrome://flagsNone

Finch feature namekDisplayContentsFocusable

Requires code in //chrome?False

Tracking bughttps://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 Statushttps://chromestatus.com/feature/6237396851228672

[David Baron]

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

[David Baron]

On Wed, Jan 10, 2024 at 11:14 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote:

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770

Is this actually defined in the spec? Should the spec be more explicit about it?

There was certainly some disagreement about that, but whatwg/html#9425 makes it much more explicit.

 

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.

What about compat? Would existing users of `display: contents` have their keyboard flows disrupted by this change?

 

That is a possible concern, although (a) I think the amount of existing content affected by the change is likely small, although I haven't attempted to measure and (b) I think such a change seems more likely to be an improvement than a regression.

 -David

[Aaron Leventhal]

David, are you sure it's too hard to implement the focus ring in all browsers based on child bounds?

I'm curious if other a11y folks will be ok with just leaving it out, even if we have a console error for the author. Unless there is a really good reason, I think we should repair the missing focus ring.

We even have a setting, "Show a quick highlight on the focused object." -- it's a bit of a misnomer, because what it does is ensure there is always a visible focus as you move. We need to make sure that still works.

Some users really need the focus ring to use software. That's why a11y standards mandate that focus changes be visible.

Aaron

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gZiQxJ3P4rBgadJT-HLR51ru_RhcXAj-oFSBy2UWL5Vg%40mail.gmail.com.

[Philip Jägenstedt]

On Wed, Jan 10, 2024 at 5:50 PM David Baron <dba...@chromium.org> wrote:

On Wed, Jan 10, 2024 at 11:14 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote:

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770

Is this actually defined in the spec? Should the spec be more explicit about it?

There was certainly some disagreement about that, but whatwg/html#9425 makes it much more explicit.

This PR is now ready to land together with the tests via https://chromium-review.googlesource.com/c/chromium/src/+/3910374 when this intent is approved.

 

[Philip Jägenstedt]

The API owners touched on this today. Just a note that we consider it on hold until there's a reply to the questions about accessibility.

[Aaron Leventhal]

Which a11y people are we looking for a reply from? Please CC me on whatever thread that is.

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfiZNKZn_3Lq%2BZVU2ZZVOH_jVtaqtvZmN0XJ9s%3DvrjA8g%40mail.gmail.com.