You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This change JunHo mentioned on the review this change conforms to the spec)
However, this can lead to issues when clickable items are contained inside other clickable items. For example, it's a common pattern to do something like this:
<a>
<button>Menu Item</button>
</a>
Both the and the are considered for Spat Nav but they're the same size. The practical effect is that it requires multiple navigations to move between menu items. e.g. See https://m.youtube.com/watch?v=eKhv9CnA6A0 using mobile emulation.
Another pattern I'm told is common is to wrap a common action in an ancestor click handler:
This leads navigation to select an invisible wrapper around both buttons which looks awkward.
Not sure how much we can do about the latter in particular but we may want to investigate some heuristics to prevent, e.g. selecting multiple candidates that overlap almost exactly.
The text was updated successfully, but these errors were encountered:
Defining the focusable element which contains another focusable element as a spatial navigation container by default could be the solution for this.
Then the focus can move inside the element and the focusable elements inside it can be reachable.
FYI, in the current spec, spatial-navigation-contain: contain has to be specified if the element needs to work as a container.
We can skip this step exceptional for this case.
Does spatial-navigation-contain: contain prevent navigation to the container itself? Based on my reading of the navigation algorithm, it seems like we'd still navigate first to the container, than to its inner element.
Yeah, it doesn't prevent navigation. But if we want to solve the issue of unreachability first, this could be a solution.
On top of that, there is a proposal for "focus delegation".
If we combining these two approaches, it may solve this issue.
Sorry, I can't find where in the spec is responsible but this pertains to changes landed in Chrome in https://chromium-review.googlesource.com/c/chromium/src/+/1587559
(This change JunHo mentioned on the review this change conforms to the spec)
However, this can lead to issues when clickable items are contained inside other clickable items. For example, it's a common pattern to do something like this:
<a>
<button>Menu Item</button>
</a>
Both the and the are considered for Spat Nav but they're the same size. The practical effect is that it requires multiple navigations to move between menu items. e.g. See https://m.youtube.com/watch?v=eKhv9CnA6A0 using mobile emulation.
Another pattern I'm told is common is to wrap a common action in an ancestor click handler:
<a onclick="dismissPopup();">
<button>Confirm</button>
<button>Cancel</button>
</a>
This leads navigation to select an invisible wrapper around both buttons which looks awkward.
Not sure how much we can do about the latter in particular but we may want to investigate some heuristics to prevent, e.g. selecting multiple candidates that overlap almost exactly.
The text was updated successfully, but these errors were encountered: