It depends. Say there is a Label that should show some text and a crazy designer asks me to have the text rotating and jumping and also be super light gray and ahrd to read, the component could still report back to accessibility framework the actual text and you could have a better experience then a regular user.

Custom rendering is not most of the time painting on a canvas. A simple example , you have a Dropdown, each item is rendered with a simple component that is something like

<text>item.text</text>

and you might want to change the render function to be

<icon>item.icon</icon><text>item.text</text>

I think ATM you still can't use the HTML select to have a dropdown with the countries and the flags or a dropdown with the fonts and each font it is painted with it's own font family, or customize the numeric spinner arrows or scroll bars colors.

Again , I prefer using native widgets, but I am forced to implement designs and I have to replace a native component with a pile of netsted divs,js and css.

Oh, I see what you mean. I was thinking about the case where you're painting something completely different than the semantic information but I guess that's rare.

You're right, in HTML you have to fall back to elements without accessibility features pretty quickly if you wanna customize a native component. There are some features that one can use to restore accessibility like ARIA but yeah, it's not great.

Not if you're just making it look different, because the component already hooks into the right APIs to expose itself to screenreaders etc.. Of course if you're doing something completely radical you need to implement accessibility yourself, but there's more flexibility to customise existing components as little or as much as you like.

No, desktop accessibility APIs are basically about exporting a labelled semantic tree to screen readers. As long as your dropdown is still semantically a dropdown with items, etc, and responds to basic commands, it doesn't matter what it looks like.