I completely agree that this is a pain point. In general, high quality documentation is lacking. I am not however convinced that this is a problem that can be automated and abstracted away. Neither am I convinced that it's one we should necessarily try to hide. It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap. Shifts in culture via higher educational curricula and stated quality attribute priorities within companies will do more good here than anything else.
Accessibility is a quality that needs to be built in from the start. The good news is that provided your HTML is sane and not a mess of class tagged DIVs, or you're building a pretty straightforward document-like navigation/content/etc site, you really only need to declare attributes to handle the places you do something unusual. The defaults are generally correct.
Much of this "unusual" behavior that needs special treatment is within custom components (e.g. a custom date selector widget with plenty of invisible divs used for layout of the calendar days can be inscrutable to a screen reader without hinting) and is the responsibility of component library or framework producers. Some issues here run deeper, like properly correlating ARIA attributes in shadow and light DOM. But that being the case, such component libraries aren't even necessarily suitable for many sites (either too complex, or make too many mismatching assumptions).
The bulk of the remaining accessibility attribute slinging that needs to happen has to do with the overall site layout (especially reactive layouts). I don't know of any framework that will handle this for you in a satisfying way for anything sufficiently sui generis. I think the tough but true answer here is "the people building the site should have at least skimmed the WAI-ARIA standard, and be using an auditing tool, and know what to be thinking about as they design the site from the start".