Section 508 vs WCAG 2.2: the difference, and how to check both

If you sell to a US federal agency, a university, or anyone spending federal money, sooner or later a procurement form asks: is your site Section 508 compliant? And if you have been testing against WCAG 2.2, the honest answer is "probably, and then some", but you need to know why that is true before you sign it. This guide untangles the two standards and ends with a concrete way to check a real page against both.

What Section 508 actually is

Section 508 is a US federal law: an amendment to the Rehabilitation Act of 1973. It requires federal agencies to make their information and communication technology (websites, software, documents, kiosks) accessible to people with disabilities. It binds federal agencies directly, and it reaches vendors indirectly: if you want a federal contract, your product is expected to meet it, which is why the question shows up in procurement.

The part people miss: since the 2017 refresh (in force January 2018), Section 508 does not define its own technical checklist anymore. It incorporates WCAG 2.0 Level A and AA by reference. In other words, for web content, "508 compliant" today effectively means "meets WCAG 2.0 AA", plus some requirements for non-web software and support documentation.

What WCAG is, and where 2.2 fits

WCAG (Web Content Accessibility Guidelines) is the W3C's technical standard for accessible web content. It is not a law; it is the checklist laws point at. Each version adds success criteria on top of the last: 2.0 (2008) is the baseline, 2.1 (2018) added mobile, low-vision, and cognitive criteria, and 2.2 (October 2023) added nine more, including focus appearance, dragging alternatives, target size minimums, and accessible authentication.

What about the ADA?

People say "508" when they often mean the ADA (Americans with Disabilities Act). They are different laws. The ADA covers businesses and state/local government broadly; in April 2024 the Department of Justice published a rule requiring state and local governments (Title II) to meet WCAG 2.1 AA, with compliance deadlines in 2026 and 2027 depending on population size. For private-sector sites, US courts have repeatedly treated WCAG conformance as the de facto benchmark in ADA lawsuits even without a formal rule. The pattern is the same everywhere: the law names a WCAG version, and the safest engineering posture is to meet the newest one.

How to actually check a page

Automated checks catch the objective failures fast; a short manual pass catches what automation cannot judge. You need both, and neither requires installing anything anymore.

1. 1

   Run an automated WCAG 2.2 + 508 scan first

   Point a checker at the page and let it flag the mechanical failures: missing alt text, unlabeled form fields, broken ARIA references, missing document language, contrast failures. This is 20 to 40 percent of the criteria, found in about a minute.

2. 2

   Check the things that need a real browser

   Contrast of text over gradients and images, focus order, what happens at 200 percent zoom (reflow), and whether interactive targets meet the 24px minimum from 2.2. Static HTML analysis guesses at these; a real rendering engine measures them.

3. 3

   Do the two-minute keyboard pass

   Unplug your mouse. Tab through the page: can you reach everything, see where focus is at all times, operate menus and dialogs, and escape them? Focus visibility is exactly the area WCAG 2.2 tightened.

4. 4

   Spot-check with a screen reader

   NVDA on Windows or VoiceOver on macOS, ten minutes: does the page read in a sensible order, do images say something useful, do form errors get announced?

5. 5

   Record what you found and fix by user impact

   A missing label on the checkout email field outranks a decorative icon without alt. Track findings with stable IDs so re-tests show progress instead of starting over.

Common questions