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 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 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/CAC2P9W%3DXXM3p9FpeJ3WgFcyj4kctQ8KzohqwPqEfhxoY8oRjUQ%40mail.gmail.com.

Reply via email to