November 13, 2023 · reala11y team

Section 508 and WordPress: what it is and who it applies to

Section 508 sets accessibility requirements for US federal IT and maps to WCAG 2.0 AA. What it covers, who's bound by it, and what it means for WordPress site owners.

If you’ve shopped for accessibility tooling, you’ve seen “Section 508” thrown around as if it were a checkbox. It isn’t. Section 508 is a specific piece of US federal law with a specific scope, and understanding what it actually covers — and who it binds — saves you from both over-claiming and under-preparing. This post is a practical orientation, not legal advice; talk to qualified counsel about your specific obligations.

What Section 508 actually is

Section 508 is an amendment to the Rehabilitation Act of 1973. It requires that electronic and information technology developed, procured, maintained, or used by US federal agencies be accessible to people with disabilities — both federal employees and members of the public who interact with that technology.

The law itself is broad. The technical requirements come from the “508 Standards,” maintained by the US Access Board. In the 2017 “Refresh,” the Access Board did something important: it incorporated WCAG 2.0 Level A and AA by reference as the standard for web content and many software interfaces. So in practical terms, the web portion of Section 508 means meeting WCAG 2.0 AA.

That mapping is the single most useful thing to know. It means the work you already do for the web — the work this whole blog is about — is the same work Section 508 points at, just anchored to an older WCAG version.

WCAG 2.0, 2.1, 2.2 — which one?

Section 508 references WCAG 2.0 AA. The web has moved on: WCAG 2.1 added criteria in 2018, and WCAG 2.2 became a W3C Recommendation on 5 October 2023. Both are supersets — every 2.0 criterion still exists in 2.2.

That gives you a clean strategy: build to WCAG 2.2 AA and you comfortably cover the WCAG 2.0 AA that Section 508 names. You don’t target the floor; you build above it and the floor is included. The newer criteria (target size, focus appearance, accessible authentication) aren’t required by 508 today, but they’re where procurement and other regulations are heading, so there’s little reason to deliberately stop at 2.0.

Who is actually bound by it

This is where people misapply the term. Section 508 directly binds:

• US federal agencies — their public websites, internal systems, and procured technology.
• Vendors and contractors selling IT to the federal government — in practice, 508 conformance shows up as a contract and procurement requirement, often backed by an accessibility conformance report (a VPAT).

Section 508 does not, by itself, impose requirements on a private business’s own website. That’s a common confusion. A private company’s site falls under the ADA (Title III) and, increasingly, state laws — not Section 508 — unless that company is selling technology to a federal agency.

State and local government sites are a separate track again: the US DOJ’s April 2024 ADA Title II rule sets WCAG 2.1 AA for them. So the regulatory map looks roughly like this:

• Federal agencies + their IT vendors → Section 508 (WCAG 2.0 AA).
• State / local government → ADA Title II rule (WCAG 2.1 AA).
• Private businesses → ADA Title III (no single named standard, but WCAG 2.1 AA is the de facto bar in litigation).

What this means for WordPress site owners

If you run a WordPress site for a federal agency, or you build sites that are sold to one, Section 508 is a contract reality and “WCAG 2.0 AA” is your technical target. A few practical implications:

• Expect a VPAT. Federal procurement frequently asks for a Voluntary Product Accessibility Template documenting how a product meets the 508 Standards. Treat it as a deliverable, not an afterthought.
• Bake the standard into acceptance criteria. If you’re a vendor, write WCAG 2.0/2.1 AA into scope up front rather than discovering the gap at launch.
• Mind third-party plugins and embeds. A 508 obligation extends to the whole rendered experience, including that booking widget or PDF viewer you dropped in. Inaccessible third-party components are a frequent source of failures.
• PDFs count. Section 508 famously covers documents, not just web pages. An untagged, image-only PDF on a federal site is a 508 problem as much as a missing alt attribute is.

If you’re a private business with no federal contracts, Section 508 probably isn’t your obligation — but the underlying WCAG work is identical, so building to it loses you nothing.

Where tooling fits — and the honest limit

The code-level issues Section 508 cares about are the same ones we write about constantly: missing alt text, low contrast, broken heading order, unlabelled form fields, keyboard traps. A scanner finds the mechanical subset of these quickly. reala11y identifies and remediates the code-level ones in your HTML, and helps your site move toward WCAG 2.2 AA conformance.

What no tool can do is make a site “508 compliant” by itself, and you should be wary of any product that says it can. Automated tooling — ours included — typically detects roughly 30–40% of WCAG issues by criteria; the rest requires human review, and conformance is a determination about a whole site, not an output a plugin emits. Section 508 conformance for a federal deliverable is something you document (via a VPAT) and stand behind, after both automated checks and manual testing.

The honest takeaway

Section 508 is the federal accessibility law, its web requirements map to WCAG 2.0 AA, and it binds federal agencies and the vendors who sell to them — not, by itself, every private website. If that’s you, build to WCAG 2.2 AA so the older 2.0 bar is automatically covered, treat the VPAT as a real deliverable, and pair automated scanning with manual review. For your actual obligations and any conformance reporting, check with qualified counsel. The technical work, reassuringly, is the same work good accessibility always asks for.