Section 508 does not describe a set of features. It points at the Web Content Accessibility Guidelines 2.0 at Level AA, and since the 2018 refresh that pointer is the whole of the technical requirement — which is why “we are 508 compliant”, on its own, tells a contracting officer almost nothing.
The four that fail first
In our experience the same four items account for most first-review failures. Colour contrast below 4.5:1 on body text. Form fields whose only label is a placeholder, which disappears the moment someone types. Focus order that does not follow the visual order, usually because a component was moved with CSS rather than in the markup. And images whose alternative text describes the file rather than the meaning.
None of these are expensive to get right at the start. All of them are expensive to retrofit, because fixing focus order after the fact usually means rebuilding the component that broke it — and that component is usually the navigation, which every page depends on.
What an audit actually looks at
An auditor works through the success criteria with assistive technology, not a scanner. Automated tooling catches perhaps a third of what matters: it is a floor, not a verdict. We run it on every commit and still expect a human pass before launch, because the failures that hurt real users are the ones a machine cannot see — a heading structure that is technically valid but meaningless, or a live region that announces the wrong thing at the wrong moment.
What to ask a vendor
Ask which version of WCAG, at which level. Ask whether the claim covers every page or the templates. Ask what the automated coverage actually is, and who did the manual pass. A vendor who has done the work will answer all four without hesitating; one who has bought a badge will change the subject.
This site is built to the same bar. The build fails on an accessibility violation, and every page was checked in a real browser before it went live — including colour contrast, which the automated suite structurally cannot check.