You can pass every automated accessibility check and still ship a site that real users cannot use. That sentence is the whole problem with how most teams approach accessibility. They run an audit, the tool shows a green score, and everyone moves on believing the site is accessible. The score measured what a machine can detect, which is a small and not very important slice of what actually matters. The site can be unusable to a person with a screen reader and still score perfectly, because the things that break for that person are mostly things a checker cannot see.
I learned this properly watching real screen reader users navigate sites in a workshop, and almost nothing they struggled with was the kind of thing an automated tool flags. The gap between "passes the checklist" and "a person can actually use this" is where real accessibility lives.
Automated audits give false confidence
Automated tools are useful, and I run them. But they catch a limited set of issues: missing alt attributes, insufficient colour contrast, absent form labels, a handful of structural problems. Those are real, and worth fixing. The trouble is what the green score implies. It implies done, and done is exactly what it does not mean.
What the tools cannot check is whether your site actually works when operated by a keyboard and a screen reader. They cannot tell you that your custom dropdown traps focus, that your modal does not return focus when it closes, that your "button" is a styled div that the keyboard cannot reach, or that your page reads as a meaningless soup because the headings were chosen for size rather than structure. A machine sees valid markup. A person hits a wall. The score is a measure of the easy half of the problem, and treating it as the whole problem is how confident teams ship inaccessible sites.
Semantic HTML does the heavy lifting; ARIA is a last resort
The single highest-leverage thing you can do for accessibility is also the least glamorous: use the right HTML element. A button should be a button. A link should be an a. A list should be a ul. Headings should describe the structure of the page in order, not be picked because h2 happens to be the size you wanted. When the markup is semantic, an enormous amount of accessibility comes for free, because assistive technology understands native elements without any help from you. The browser has already done the work.
The common failure is reaching for ARIA to paper over markup that was never semantic in the first place. A div dressed up with role="button" and a pile of aria-* attributes to mimic what an actual button would have given you for nothing. This is backwards, and it is worse than it looks, because bad ARIA is more harmful than no ARIA. An incorrect role or a stale aria-expanded actively lies to the screen reader, sending the user wrong information they then have to fight. The rule I follow is that ARIA is the last resort, not the first reach. If you find yourself adding roles to recreate a native element, delete the ARIA and use the element. The right HTML is almost always simpler and always more reliable than the ARIA you would use to fake it.
Keyboard and focus management is where real sites fail
If I had to point at the single place where otherwise-decent sites fall apart, it is keyboard and focus management. This is the part automated tools are weakest at and the part real users feel most.
Everything should be operable with a keyboard alone, in a logical order, with a visible focus indicator so the user can see where they are. That last one matters and is constantly removed: somebody dislikes the default focus ring, sets outline: none, and quietly makes the site unusable for anyone navigating by keyboard. Then there is focus management in interactive components. When a modal opens, focus should move into it and be trapped there until it closes, and on close it should return to the element that opened it. When content appears or disappears, focus should not be left pointing at nothing. These are the details that decide whether a real person can use your interface, and not one of them shows up on an automated report.
The honest test is not a score. It is to put your mouse away, navigate your own site with the keyboard, and then try it with a screen reader turned on. You will find things in five minutes that every audit you ran missed.
What "beyond the checklist" actually means
The checklist is not wrong. It is just the floor, and people keep mistaking it for the ceiling. Passing automated checks means you have cleared the issues a machine can detect, which is necessary and nowhere near sufficient. Real accessibility is whether a person using assistive technology can actually accomplish what they came to do, and that is a question about semantic structure, keyboard operability, and focus behaviour, almost none of which a tool can answer for you.
So go beyond the checklist by changing what you measure success against. Not a green score, but a person getting through your site with a keyboard and a screen reader. Build on semantic HTML so the platform does the work, treat ARIA as the rare exception rather than the habit, and take keyboard and focus management as seriously as you take the visual design, because for a large number of users it is the design. The checklist tells you that you did not fail the obvious way. Whether you actually succeeded is something you have to go and check yourself.
