Hardly. These examples are really clear cut and easy to avoid in isolation, however some of them can also be employed by accident or ignorance in larger code bases.
An audit, and using the site as a person who requires accessibility would while developing. The automated tools are just a quick check to find anything blatantly wrong. I also suggest using WAVE and AXE for that purpose.
As you get deeper into accessibility you'll also find there isn't one single right answer to improve accessibility.
> … there isn't one single right answer to improve accessibility.
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.
My last job had audits done on a semi-yearly basis and they always caught things our automated tests hadn't.
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.
If they are no good for screen reader users, what's their puprpose for non-screen reader users? I can only think of bad use-cases. Duplicating content the site wants to promote or a duplicated navigation. Things would probably be more clean without in most cases.
Screen readers often read things in particular ways that non-screen readers would interpret differently. One example that I've run into is using all caps to label something, like "ACCOUNT NAME". Screen readers will typically read out each letter individually instead of as a word. There could be other things, like describing field colors or something that are not as useful when audio only.