Maybe a contracting officer has asked for an Accessibility Conformance Report before your proposal can move forward. Maybe your nonprofit just accepted a federal grant and the terms mention Section 508. Or a federal agency runs a WordPress microsite and someone in the program office wants to know whether it would hold up to review. In each case the question lands on whoever looks after the website, and that person usually has no idea where to start. Section 508 website compliance work, as we do it, is practical: test the site against the standard 508 points to, fix what blocks people, and hand over findings precise enough to write an honest conformance report.
A plain word before anything else. We are a WordPress team, not attorneys and not federal accessibility officials, and nothing on this page is legal advice. We can tell you what the standard asks for in technical terms and what your site does or does not do. Whether a given contract, grant or agency policy applies to you, and what you are obliged to claim, is a question for your contracting officer, your agency’s Section 508 program manager or your own counsel.
Who Section 508 reaches, and why a vendor ends up holding it
Section 508 of the Rehabilitation Act applies to federal agencies. It governs the information and communication technology they build, buy, use and maintain: websites, web applications, software, electronic documents and more. On paper, a private company is not directly covered.
In practice the duty flows outward through paperwork. An agency that buys a web product, or pays a contractor to build and run a site, has to consider whether what it is buying meets the 508 standards. So the requirement shows up in solicitations, statements of work and contract clauses. Grantees often meet it the same way, because the grant terms or the funding agency’s policy carry the expectation down to them. State agencies and universities sometimes adopt 508 language in their own procurement rules too.
The people who call us about this tend to fall into a few groups:
- Small vendors and SaaS companies answering a federal solicitation that asks for an ACR on the product’s web interface.
- Contractors who build or maintain a WordPress site for an agency office, a lab or a program.
- Nonprofits, research groups and community organizations funded by federal grants who publish reports, toolkits and event pages.
- Agency staff who own a small site outside the main web platform and want an outside technical review.
If you are a city, county or school district, the rules you are more likely facing come from ADA Title II rather than 508, and our page on Title II website work for public entities covers that path.
How Section 508 relates to WCAG 2.0 Level AA
The 2017 refresh of the Section 508 standards did something very helpful for anyone doing the technical work: it incorporated WCAG 2.0 Level AA by reference. For web content, the success criteria in WCAG 2.0 at Levels A and AA are the test. The refresh also applies those criteria to electronic documents and software that are not web pages, and keeps a set of functional performance criteria that describe outcomes for people with different disabilities.
So Section 508 website compliance, for a site, comes down to a WCAG 2.0 AA review. Anyone who wants the background on the guidelines first can read our short primer on the WCAG standard.
Here is the wrinkle. Our audits are run against WCAG 2.2 Level AA, which is the current W3C Recommendation. WCAG is designed to be backward compatible, so a page that meets 2.2 AA meets nearly everything 2.0 AA asks. There is one exception worth knowing about. WCAG 2.2 removed 4.1.1 Parsing, but WCAG 2.0 still contains it, which means a report written against 2.0 still needs a line for it. We check markup for the duplicate IDs and broken nesting that criterion was about and record the result separately.
| Question | WCAG 2.0 AA (Section 508) | WCAG 2.2 AA (our audit baseline) |
|---|---|---|
| What it is | The version the 2017 refresh adopted by reference | The current W3C Recommendation, published October 2023 |
| Criteria added since 2.0 | None of the 2.1 or 2.2 additions | Includes reflow, non-text contrast, text spacing, target size, focus not obscured and others |
| 4.1.1 Parsing | Still listed, so a 508 report must address it | Removed; we test it separately when a 508 report is needed |
| Practical effect | The legal floor for federal ICT | A stricter test that covers the 2.0 floor and more |
Testing to the newer version costs little extra and leaves you better placed if an agency, a state buyer or a private customer asks about 2.1 or 2.2 later. The report simply marks which findings fall under 2.0 and which come from the newer criteria, so nobody mixes the two up. The official Section 508 site run by GSA is the place to read the standard and agency guidance in the original.
What our Section 508 accessibility review covers
We do not test every URL on a large site. We agree a sample with you that represents every template and every distinct feature, then test that sample by hand. A typical sample for a contractor or grantee site looks like this:
- The home page, a standard content page and a long article with headings, lists and tables.
- Navigation: the main menu with any dropdowns, the mobile menu, search and the footer.
- Every form that matters: contact, registration, newsletter, application or login.
- Listing and archive templates such as news, events, publications or staff directories.
- Embedded media: video players, maps, social feeds and any third-party widget.
- A selection of the PDFs and Word files people download most, because 508 covers documents as well as pages.
- For a product, the screens a buyer would actually use, signed in, with realistic data.
On that sample we run automated scanners, then do the part machines cannot: a full keyboard pass, two screen reader passes (NVDA in a Windows browser, then VoiceOver on Apple hardware), zoom and reflow checks, color contrast checks on text and controls, and a read-through of headings, labels, link text and error messages. The page on manual testing with assistive technology explains that part in more depth.
Things 508 reviews often turn up on WordPress sites
Federal and grant-funded sites tend to share a few habits. Reports go up as scanned PDFs with no text layer. Data tables are built with columns of paragraphs instead of real table markup. Program logos with text baked in carry no alt text. The events calendar plugin produces a grid that a screen reader reads as a stream of numbers. A survey form embedded from another service has inputs without labels. None of these is exotic, but each one fails a specific criterion and each one shows up in the report.
From audit findings to an ACR on the VPAT template
This is where people get confused, so it helps to be precise about the words. The VPAT, or Voluntary Product Accessibility Template, is a blank form. Once someone fills it in for a specific product or site, the result is an Accessibility Conformance Report, or ACR. Buyers ask for “a VPAT” all the time, but what they need from you is the completed ACR.
An ACR goes criterion by criterion. For each one it states a conformance level and gives remarks explaining it. The template uses terms such as Supports, Partially Supports, Does Not Support and Not Applicable. The remarks are where honesty lives: a buyer reading “Partially Supports” wants to know which part of the product falls short and what the impact is.
Our part is the technical evidence. After the audit we give you, for every WCAG 2.0 A and AA criterion:
- What we tested and on which pages or screens.
- What we found, with each failure tied to a location and a short description a developer can reproduce.
- A suggested conformance level based on that evidence.
- Draft remark text in plain language, describing limits without minimizing them.
You, or the product owner, then fill in the ACR. If you want us to put the findings into the template layout for you, we can, but the document goes out under your organization’s name, with your product description, your contact details and your signature on the claims. We will not sign a conformance claim on anyone’s behalf, and we would be wary of any vendor that offers to.
Why the signer matters
An ACR is a statement your organization makes to a buyer, often a federal one. If it says Supports where the product does not, that is your organization’s statement, not your tester’s. Keeping the technical findings and the claim separate protects everyone: we stay accurate about what we saw, and you decide what to assert with full knowledge of the evidence. The posts on reading an accessibility audit report and on how WCAG conformance levels work are worth a look before you fill in your first one.
Fixing issues before the report goes out
Most people would rather send an ACR with fewer “Does Not Support” lines. That means fixing first and writing the report afterward, when the schedule allows.
On a WordPress site, fixes usually fall into three buckets. Theme fixes, such as restoring visible focus outlines, correcting heading structure in templates, labeling icon buttons and making the mobile menu work from the keyboard. Plugin fixes, such as replacing or patching a form plugin that does not tie errors to fields, or adding keyboard handling to a tab or accordion component. Content fixes, such as writing alt text, rebuilding fake tables and converting scanned PDFs into tagged documents or plain HTML pages.
We work on staging where one exists, fix in priority order, then retest the exact checks that failed. Anything we cannot fix, for instance a third-party embed you have no control over, is recorded with its impact so the ACR can describe it truthfully. How we make and record code and content changes is set out on our accessibility remediation page.
When the timeline is short
Procurement deadlines rarely wait for a full remediation cycle. If you have to submit before fixes are done, the honest route is an ACR that reflects the site as it is today, with remarks noting which issues are being fixed. Buyers see partial support constantly. What causes trouble later is a report that claims more than a reviewer can confirm with a keyboard and ten minutes of testing.
Electronic documents under Section 508
Agencies and grantees publish a lot of documents, and the 2017 refresh applies WCAG 2.0 to many of them. A program report, a fact sheet, a slide deck shared after a webinar: each one can be reviewed for headings, reading order, alt text, table structure, language and contrast, just like a page.
We start by asking which documents need to be documents at all. A two-page notice that people read once is often better as a web page, where accessibility is easier to keep. For the rest, we check tagging and reading order, fix what can be fixed in the source file, and tell you plainly when a document should be recreated from its original Word or InDesign file rather than patched. The post on making website PDFs accessible goes into tagging and when to drop the PDF entirely.
What you receive at the end
- A findings report organized by WCAG 2.0 criterion, with the newer 2.1 and 2.2 findings marked separately.
- The page and document sample we tested, so anyone can repeat the work.
- For each failure: location, what a user experiences, the criterion and how it was fixed or why it remains.
- Suggested conformance levels and draft remark text for every row of the ACR.
- A change log of fixes made to the theme, plugins and content.
- Retest notes showing which issues were confirmed fixed.
- A short list of issues outside your control, such as vendor embeds, with their effect on users.
If you also need a public accessibility statement on the site, it can be drafted from the same results; see our page on writing an honest accessibility statement.
What we need from your side
- A WordPress login with administrator rights, set up as its own user so you can delete it when the project closes, plus a staging copy if one exists.
- The solicitation language, contract clause or grant term that mentions 508, so we test against what was actually asked.
- A list of the pages, forms, documents and features that matter most to the buyer or the public.
- For a product: test accounts with realistic roles and data, and a note of anything off limits.
- A named person who can decide on fixes that change design or content, and who will own the ACR.
- Any earlier VPAT, ACR or audit, even an old one, so we can see what was claimed before.
How to judge the work honestly
Do not judge a 508 review by a single score. A scanner that reports zero errors only tells you that the checks a machine can run came back clean. Instead, try a few things yourself. Unplug your mouse and complete the main form. Turn on the free NVDA screen reader, open a key page and listen to whether the headings and buttons make sense when spoken. Zoom the browser until the layout narrows to a phone width and see whether anything gets cut off.
Then read the findings report and pick three issues at random. Can you find them on the page from the description? Does the retest note say how the fix was confirmed? Does every “Supports” suggestion actually have testing behind it? A good report survives that kind of spot check.
Mistakes that cause trouble with 508 reviews
- Copying an old ACR forward. A report from two releases ago describes a different product. Update it whenever the interface changes.
- Marking everything “Supports” to look good. Reviewers often test a sample. One obvious failure makes them doubt every other line.
- Testing only the marketing pages. For a product, the buyer cares about the screens staff will use daily, not the landing page.
- Installing an overlay toolbar and calling it done. A widget does not change the underlying markup that an ACR describes.
- Forgetting the documents. A site can pass page by page while its most-downloaded file is a scanned image.
- Treating 2.0 as the finish line. It is the 508 floor, but other buyers increasingly ask about 2.1 or 2.2.
Doing it yourself or bringing in help
A small, simple site with one form and a handful of pages can get a long way with a free scanner, a keyboard pass and some reading of the criteria. If the buyer asks only for a short ACR on a brochure site, a careful in-house person can produce one, especially using the GSA guidance.
Outside help earns its place when the site has many templates, custom plugins, a signed-in product area, a pile of documents, or when nobody on staff has used a screen reader before. It also helps when the ACR will be read closely by a federal accessibility reviewer, because an independent tester’s evidence makes the claims easier to defend. If your wider question is how 508 sits beside ADA Title III, the plain-English ADA overview for websites sets Title III, Title II and 508 side by side.
Questions to ask any provider
- Which screen readers and browsers are in your test setup, and is every page also tried from the keyboard alone?
- Will the report tie each finding to a WCAG 2.0 criterion and a specific location?
- Who fills in and signs the ACR, and will you put conformance claims in writing on our behalf? (The right answer to the second part is no.)
- How do you handle 4.1.1 Parsing when you audit against WCAG 2.2?
- Once the report is delivered, who makes the repairs, and who checks them again?
- Will you review our documents, or only the web pages?
Keeping Section 508 website compliance current on WordPress
An ACR is a snapshot. The day after it is signed, a plugin update can change a form’s markup, an editor can paste in a chart without alt text, or a new theme version can drop the focus styles you fixed. For a contract that lasts a few years, the report needs to stay true for that long.
We pair 508 work with regular checks: the key pages and forms are retested on a schedule, new documents are reviewed before they go up, and the findings log is updated so the next ACR revision starts from facts rather than memory. That fits naturally with ordinary monthly WordPress maintenance, where each update is tried on a staging copy first. To see how this service fits with the audit, remediation and monitoring work we offer, start from our accessibility services overview.