There are still some more work needed to wire up the semantics action to this element, but I would like to know whether this is the way we want to pursuit.

An alternative is to Make semanticsObject.element to be a directly, that way I can reuse all the RoleManager like Tappable or Focusable.

Can you reuse the Focusable role manager instead of implementing custom focus management?

The focusable role manager will only work on SemanticsObject.element I think? If I want to do that, I will need to add a way to create an <a> as SemanticsObject.element instead of the <flt-semantics-node> that it hardcoded to create. I am fine with that, but it seems to divert from what we were doing with text_field.dart

Ah, in that case you might want AccessibilityFocusManager.

I updated the code to use RoleManager instead, PTAL

Similarly here, can we reuse the Tappable role manager?

Let's keep the generic role last to underscore that it's the fallback role that we only use as a last resort.

The element field is designed to be final, as it participates in the parent's DOM structure. Simply swapping the element field will result in a dangling element not attached to anywhere. Let's chat about what you are trying to do and find a better solution.

Does it need to be late if it is initialized immediately? late has runtime cost (it uses a null check behind-the-scenes) and complexity cost (it is initialized upon first access, which is less predictable than constructor initialization).

non-late final can only accept static function as its initializer. In this case, there isn't a way for sub class to inject their logic

Oh I see, you need to call this.createElement which not static. In that case late make sense. However, I'd still initialize it in the constructor. Otherwise, it gets initialized upon first read of the field, and since it's hard to predict when exactly that field is accessed we can get into race conditions, such as _createAndInitElement reading from semanticsObject that has changed its state after the constructor is finished. Can you move element = _createAndInitElement(); into the constructor body?

Is there a Github issue this can point to?

nit: actually, I'd still keep this static and pass all the information it needs to initialize the element (I think all it needs is the element created by createElement and semanticsObject). This way this method will not need access to this.