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


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

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/aaabc541-832c-4c47-89f6-0d6bab35bf98n%40chromium.org.

Reply via email to