As I mentioned in the comment, I think you can do better by not trying to intercept the player's click on the original button, but instead just react to the original button itself being clicked.
We can do this while maintaining the highlight's self-containment, by giving it a script like this:
using UnityEngine.UI;
using UnityEngine.Events;
public class ButtonHighlight : MonoBehaviour {
// Point this at the button that you want to highlight & react to.
public Button targetButton;
// Optionally, you can use an event to fire the next beat in the tutorial sequence.
public UnityEvent onHighlightDismissed;
void OnEnable() {
// Subscribe to the target button's click.
targetButton.onClick.AddListener(OnTargetButtonClicked);
// Trigger any in transition or animation here.
}
void OnTargetButtonClicked() {
targetButton.onClick.RemoveListener(OnTargetButtonClicked);
// Trigger any out transition or animation here.
// This can be done in a coroutine to wait before turning off the highlight.
gameObject.SetActive(false);
// Trigger the next stage of the tutorial, if any.
if(onHighlightDismissed != null)
onHighlightDismissed.Invoke();
}
}
Zero changes need to be made to the code of the buttons you're interacting with. We just eavesdrop on their existing click events, using an object that is not itself a raycast target, and clean up after ourselves once the player has clicked as desired.
We get several advantages from this approach:
It more closely matches the intention of the feature:
This means we have fewer opportunities for the effect of the code to deviate from what we meant it to do.
With the latter style, we have to keep the spoof button carefully matched to the original - any change to one without the other risks breaking the link, so for example the player could click on the intended button and miss the highlight, leading to an invalid state where the player has clicked the button but the tutorial is still telling them to click it.
We get all the normal hover / keyboard interactions of the underlying button (including tab ordering) "for free" - no extra fakery or edge cases to deal with. Your interface still works identically whether the highlight is present or not, reads the same to screen readers, etc., because we haven't interfered with the interaction logic at all.
We're free to style the highlight however we want. It doesn't have to exactly match the shape and size of the source button, or be any specific type of object - it could be an arrow pointing at it from outside its bounds, or a particle system of sparkles showering around it, or a skinned mesh of a character grabbing the button... your visual styling is completely decoupled from the logic of "show this until the player clicks this button"