Even if the focus indicator is displayed with the element itself, it may be unclear to which element it refers, see #936 (comment)

Proposed working group answer:
Thank you for your comment.
The glossary definition of focus explains that it is the "point where the user’s input interacts with the web page". This implies that the focus is near or around the element in focus. The case of the displaced focus indicator that you mention would be valid where the element with the visible focus (say, the play button) matches the function of the element that actually activates the function.

The group met today and agreed the following response:

I agree with the proposed response that programmatic focus and visible focus need to be close to support users of screen magnification and those that overwrite focus indicators with custom ones in style sheets. So while a displayed indicator is ok for some people indicators that are close to the control are needed for users with low vision.

@mraccess77 I'd note that it gets tricky in situations where, by design, the programmatically focused element (i.e. the element that is the document.activeElement, if we're talking HTML specifically) is different from what "logically" has focus (as is the case with some ARIA-fied widgets that use aria-activedescendant or similar). there are legit cases where programmatic and logical focus will not be on the exact same element - so it will be tricky to mandate anything that says otherwise. would something that completely messes up, say, screen magnification fall under the general "accessibility supported" aspect somehow, perhaps? and where / which SC would one fail gross mismatches/problems of that nature?

I'd consider active-descendant to be the point of programmatic focus - so no issue there. I agree there could be edge cases - but in general I would not want something that allowed the focused element and visual indicator to be too far from one another as a general rule because how would magnification software know where that is.