This is very true. Like any optimization, there is a point at which improving things for one community makes things worse for others. An example most of us are familiar with are the trade offs between mobile UI and desktop UI: You can make your UI adequately work on both, but in order to give both an optimal experience things start to get quite complex. I’ve seen developers tie themselves into knots trying to be all things to all people here. Accessibility is harder in a sense because able-bodied devs often don’t have any instinct for when they’re crossing the line from “good enough” to “overkill”.

The 80% rule for accessibility is really just “Make your site keyboard accessible”. While there will still be some issues for some users, it’s a clear enough goal that it can break a dev out of “analysis paralysis” and just get moving on something, and the benefit is huge for the vast majority.

Broad stuff like providing controls for changing content (e.g. carousels) are what automated a11y tests fail on; other hard-to-test criteria includes WCAG 2.1§2.3.1 "Three Flashes or Below Threshold" and 1.4.9 forbidding "Images of Text"

Common thought, but not really true. The basics of accessibility might be considered just "usability" or even UX, but going beyond that, it steps in being useful for people with certain disabilities while not impacting people without.

One example from the article, `aria-hidden="true"` (https://www.w3.org/TR/wai-aria/#aria-hidden) might be used to hide elements containing text that are not useful for people with screen-readers, while not changing the experience at all for the ones not using one.