You should not have to think about accessibility.
Not because you can afford to ignore it, but because it should just be there in every UI tool you use. Frameworks — for the web, for desktop, and elsewhere — should have accessibility so thoroughly integrated into them that it would take work to make it not work, so that a typical developer can build their project and be able to count on it being accessible by default. We have the technology and industry knowledge to do this, and have had it for decades — there is no longer any good reason for it not to be considered a basic requirement.
Note that, for the sake of this argument, accessibility refers not just to usability with a screen reader, larger text, or other options typically thought of as "accessible", but also to many things not typically classified under that label, such as localization. While the merits (and drawbacks) of the social modal of disability are beyond the scope of this blog post, the core idea behind that modal — that disability is ultimately the failure of a system to provide for a person's needs, rather than a feature of the person themselves — forms a good first principle for UI design: design your interface for existing users, rather than expecting users to adapt to your interface. Seen through that lens, the process of designing for users who will need to use your software through different sensory mediums and that of designing for users who will need to use it in different languages strongly resemble one another.
Given all of that, and the level of accrued knowledge in the software development community after multiple decades of the internet being a regular part of people's lives, it is reasonable to say that accessibility is the job of the UI framework. That does not mean that developers not actively working on UI projects can ignore it entirely — at very least, they still need to choose a UI framework that provides decent accessibility — but expecting every developer to reiterate the same (long) checklist of possible accessibility issues on every single project increasingly feels like a scenario precisely engineered to create buggy UIs that are only usable for fully abled users who approach them in exactly the way the developer anticipated. Nobody, abled or otherwise, wants that.
This is also another strong argument for why developers should avoid reinventing the wheel whenever possible, and instead use existing, well-documented and standardized tools for user interfaces. Web development standards like HTML are near-universally supported, have large numbers of highly competent people working on them, and when used as intended get you a high level of accessibility by default. While I will not attempt to enumerate UI or web development frameworks here, I would encourage developers choosing a framework to consider the accessibility features that the framework gets them for free — and I would encourage framework and standards developers to consider accessibility as not just a requirement, but one of the core features they are providing. After all, if not to make content available and accessible to the greatest number of people possible, what are user interfaces even for?
The world would be a much better and more usable place if developers spent more time pondering that question.