Re: [w3ctag/design-reviews] The `interesttarget` attribute (Issue #1058)

matatk left a comment (w3ctag/design-reviews#1058)

The explainer's [pitch](https://open-ui.org/components/interest-invokers.explainer/#the-pitch) is that even though developers _could_ express this UI pattern using existing web features (except for the context menu integration on touchscreens), enough developers fail to consider the needs of non-mouse users, including keyboard, screenreader, touchscreen, and other modalities, that we need a new feature to [make accessibility the default](https://github.com/w3ctag/design-principles/pull/616). Most of the TAG agrees with this claim, and thinks the proposed design looks like a good implementation. The TAG also has consensus on some concerns about the design:

The primary concerns are that
1. the default touchscreen implementation is hard to find;
2. the ["Show details" context menu item](https://open-ui.org/components/interest-invokers.explainer/#touchscreen-and-ar) may break the user expectation that all context menu items do UA-controlled and reliable actions; and
3. the most obvious privacy-preserving gaze-based implementation (to show a UA-provided "show details" button on gaze) is somewhat awkward and ought to include a proposal to style it.

We approve of the `::interest-button` proposal to give users on touchscreen platforms a perceptible way to indicate interest. We think it's important that the proponents find a way to display this button by default on such platforms, so that the feature is accessible default. If **developers have to opt into the button, we risk reproducing the status quo where a lot of developers forget to support touchscreens.**

Showing this button by default on touchscreens has a risk of creating a cluttered and possibly confusing interface, but that seems better than making users discover a context menu option. Note that `::interest-button` _might_ not need to be shown by default on platforms where a gaze can make just the "show details" button appear.

**Alternative avenues that could be explored:**

We think the following might be useful directions to explore. We don't have consensus on whether they're likely to replace the need for `interesttarget`:

* Separate the `InterestEvent` from how it is triggered. Continue to investigate how this could be used more.

  - Being able to use events like `InterestEvent` to indicate user intent within a UI could open up other interaction possibilities - including for humans and machines.

  - The [AOM Input Event Types](https://wicg.github.io/aom/spec/input-events.html) proposal seems to share some of this spirit.

* Consider this as a problem of presenting a responsive preview of another page, and how that other page may be fetched, loaded, and upgraded if the user chooses to visit it.

* The breakout [Pointer Events - Gesture Support](https://github.com/w3c/breakouts-day-2026/issues/3) talked about setting up a possible CG to incubate new gestures on the platform. This may include things like long press (though it wasn't in the initial thoughts of the group).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1058#issuecomment-4602914157
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1058/4602914157@github.com>