What Is Section 508 Compliance? Accessibility Testing Guide

Section 508 compliance means that covered information and communication technology (ICT) used, developed, procured, maintained, or operated by U.S. federal agencies conforms to the applicable Revised 508 Standards. For web content, the standards incorporate WCAG 2.0 Level A and AA success criteria, but Section 508 is not simply a WCAG checklist: requirements depend on the kind of ICT and the applicable provisions. The Access Board publishes the standards; Section508.gov provides federal implementation and testing guidance. Start with the [Revised 508 Standards](https://www.access-board.gov/ict/) and your agency’s Section 508 program.

For developers, compliance work is a repeatable process: define the product and version in scope, combine automated checks with systematic manual evaluation, record findings in a reproducible report, remediate defects, and retest changed versions. An automated scan, vendor report, or assistive technology walkthrough can provide useful evidence, but none alone proves that an entire product conforms.

1. What Section 508 compliance means

Section 508 concerns accessibility of federal ICT. Covered technology can include public and internal websites, web applications, software, electronic documents, hardware, and other ICT. The applicable technical provisions depend on the ICT type and use. Federal guidance covers commercial off-the-shelf and open-source products as well as custom agency systems and vendor-delivered products.

The Revised 508 Standards incorporate WCAG 2.0 Level A and AA success criteria for web content. Do not assume that every relevant requirement is expressed as a WCAG criterion: consult the applicable provisions and the agency’s policy for the product being evaluated. The Access Board is the standards authority; Section508.gov explains federal implementation, procurement, and testing practices. See the [Access Board standards](https://www.access-board.gov/ict/) and [Section508.gov’s web testing overview](https://www.section508.gov/test/websites/).

These materials explain federal ICT requirements. They do not establish a universal legal conclusion for state, local, or private-sector accessibility duties. For a specific obligation, use the applicable law, contract, solicitation, and agency policy.

2. Scope the evaluation before testing

A result is meaningful only when readers can tell what was evaluated. Before running tools, write down the scope and acceptance context.

Identify the product. Record its name, version or release, purpose, owner, and delivery model. Include the exact build or deployment when possible.
Identify the governing requirements. Map the ICT type to applicable Revised 508 provisions, relevant WCAG criteria, agency policy, procurement language, and contract acceptance terms. When unsure, ask the agency Section 508 program or accessibility lead.
Choose representative content and tasks. Include critical user journeys, templates, unique components, forms, dialogs, navigation, media, data tables, documents, and error states. Include both public and authenticated areas when they are in scope.
Set the environment. Record operating system, browser and version, viewport, input method, and relevant assistive technology. Select combinations required by the agency or needed to reproduce a defect.
State boundaries and exclusions. List pages, modules, third-party integrations, platforms, languages, or flows not evaluated and explain why. Do not imply that sampling covers untested areas.
Choose evaluation depth. Specify whether the work is an automated scan, targeted component check, spot check, or comprehensive evaluation. Align this choice to the risk, contract, project stage, and agency process.

Build accessibility evaluation into planning, requirements, design, development, testing, deployment, and operations. Test before release as agency policy requires and after relevant content or software changes. The [Technology Accessibility Playbook](https://www.section508.gov/manage/playbooks/technology-accessibility-playbook/10/) discusses integrating ICT accessibility testing into the lifecycle.

3. How to test a website for Section 508 compliance

Use automation to find issues it can detect consistently, then perform manual checks for interaction, meaning, context, and other requirements that tools cannot decide. For federal web content, consider the DHS Trusted Tester manual process. If using a different process, federal guidance says its methods and toolset should align with the ICT Testing Baseline. The Baseline helps build or check process coverage; it is not itself a test process or a testing tool.

Review the page and task inventory. Select pages and states that cover each unique template and critical flow. Include form validation, menus, overlays, and dynamically updated content, not only the initial landing page.
Run automated checks. Scan representative routes and components. Triage each result: confirm whether it is a real defect, understand its scope, and file it with the affected page and state. Track false positives and missed areas rather than treating the tool’s score as a pass.
Inspect structure and content manually. Check headings, landmarks, labels, accessible names, instructions, meaningful reading order, image alternatives, link purpose, table relationships, and error messages in context.
Operate the interface with a keyboard. Navigate without a pointer. Check focus visibility and order, ability to reach and leave controls, dialogs and menus, keyboard traps, and whether custom widgets expose the expected interaction.
Check visual presentation. Review text and non-text contrast, zoom and reflow behavior, focus indication, and information conveyed by color. Apply the exact applicable criterion and testing method; a screenshot alone cannot establish these results.
Evaluate dynamic behavior. Trigger validation, loading, updates, disclosures, and dialogs. Check that status changes and errors are perceivable and that focus behavior remains usable.
Use assistive technology where appropriate. Validate that names, roles, values, reading order, and task flow are communicated in supported combinations. Assistive technology testing provides valuable usability evidence, but use it alongside code and standards-based checks; it alone does not establish conformance.
Map findings to requirements. For each applicable provision or criterion, record the method and outcome. Mark a requirement not applicable only with a specific explanation.

Section508.gov lists [ANDI (Accessible Name & Description Inspector)](https://www.section508.gov/tools/tools-for-testing-ict/) as a free, open-source bookmarklet used in the Trusted Tester process and ICT Testing Baseline tests. Browser developer tools and contrast analyzers can support particular checks. These tools assist evaluation; no single one certifies an entire site or product.

4. Automated scans, manual methods, and hybrid testing

Method	Useful for	Limits
Automated accessibility checks	Repeatable detection of certain markup and presentation issues; quick feedback during development.	Partial coverage. They cannot reliably judge every context-dependent requirement, task flow, or user experience.
Manual protocol, such as Trusted Tester	Structured inspection of web content and repeatable checks requiring human evaluation.	Requires trained testers and time; web-focused protocols do not automatically cover every ICT type.
Assistive technology and user evaluation	Understanding real interaction, usability barriers, and behavior with relevant technologies.	Does not by itself demonstrate code conformance or cover every applicable requirement.
Hybrid process	Combines repeatability and speed of automation with manual standards checks and relevant usability evidence.	Needs a defined scope, competent review, evidence management, and retesting.

Federal guidance describes automated testing as a useful supplement that provides only partial coverage. Select tools and methods by coverage, human judgment, repeatability, product type, skill and time needs, reproducibility of findings, and fit with agency policy and procurement terms. See the [ICT Testing Baseline portfolio](https://www.section508.gov/test/ict-testing-baseline-portfolio/) and [Trusted Tester guidance](https://www.section508.gov/test/trusted-tester/).

5. Capture screenshots as defect evidence

A screenshot can help a developer locate a visual defect, such as a clipped label, missing focus indicator, or overlapping dialog. It is supporting evidence, not a conformance verdict. Screenshots cannot show keyboard operability, accessible names, screen reader announcements, source semantics, or every state and viewport. Pair them with steps to reproduce, environment details, and—when useful—relevant code or accessibility tree information.

For manual evidence capture, open the relevant page and reproduce the exact state, viewport, and interaction. Capture the issue and surrounding context, then record the URL, browser, operating system, viewport, steps, and expected versus actual behavior. Avoid including personal or sensitive data in evidence. Retake evidence after remediation if it helps verify the specific visual fix; still rerun the applicable underlying test.

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can help capture reproducible visual evidence, including full-page or selector-based shots, but it does not test Section 508 conformance. Its cookie-banner, newsletter-popup, and chat-widget cleanup can be disabled step by step; when evaluating the actual user experience of those elements, capture them present or disable cleanup so evidence represents the tested state. Learn more at ScreenshotNeo.

Or skip the browser setup

One GET request can save the returned screenshot. See the ScreenshotNeo API documentation for the options and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie banners, popups, and chat widgets are removed before a shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, no card required.

6. Record defects so teams can fix and verify them

Write each finding so a developer who did not observe the test can reproduce it. Give it a stable identifier, a concise title, affected requirement, severity or priority according to the agency’s scheme, affected product version, location, and steps.

A useful defect record includes:

Page, component, route, and exact application state.
Environment: operating system, browser/version, viewport, input method, and assistive technology when relevant.
Steps to reproduce and the actual result, followed by the expected accessible behavior.
Applicable Revised 508 provision and relevant WCAG success criterion, where applicable.
Impact on users and severity using the team’s defined scale.
Screenshot, short recording, code snippet, or accessibility tree details when they clarify the finding.
Suggested remediation where the tester can offer it, plus owner, status, fix version, and verification result.

Report an outcome for every relevant requirement, including not applicable with rationale. Keep product-level summaries separate from detailed developer findings. Section508.gov describes the [essential elements of an accessibility test report](https://www.section508.gov/test/elements-of-an-accessibility-test-report/) and names the DHS Section 508 Compliance Reporting Tool and agency templates as possible formats.

7. Review vendor accessibility claims and ACRs

An Accessibility Conformance Report (ACR), often produced using an ITIC VPAT template, is a structured vendor statement about a product’s accessibility support. Use it to understand claims and prepare procurement questions, not as a substitute for validating the product. Check the product name and version, report date, scope, evaluation method, environments, and explanation behind each outcome.

Compare the ACR with your intended use and contract requirements. Request test evidence, demonstrations, or acceptance documentation when the solicitation or agency policy calls for them. Contract terms determine the process and evidence expected, and an agency may arrange independent testing. See [Section508.gov guidance on understanding vendor claims](https://www.section508.gov/buy/understand-claims/) and [buying accessible products and services](https://www.section508.gov/buy/).

For agency workflows, the Accessibility Requirements Tool (ART) helps determine requirements for technology an agency buys or builds. The ACR Editor helps accessibility subject matter experts create machine-readable OpenACR reports. These support requirements and reporting workflows; they are distinct from hands-on conformance testing tools.

8. Retest fixes and manage change

Confirm the deployed or candidate build identifier and the versions of affected pages and components.
Reproduce each defect on the original test path and verify the reported behavior is corrected.
Run the relevant manual and automated checks again, including regression checks for shared components and dependent flows.
Evaluate newly changed content and instances. A previously tested template does not automatically validate every changed instance.
Update the report with retest date, tester, build, outcome, and remaining limitations.
Reassess scope when a major update, new feature, integration, browser support change, or procurement condition alters the product or its use.

Accessibility results attach to a tested version and scope. A passing result for an earlier build should not be presented as a result for materially changed content or software.

9. Performance, reliability, and cost planning

There is no single testing duration or cost that applies to every product. Estimate effort from the number of unique templates and interactions, ICT types, supported environments, criticality, contract requirements, and level of evidence needed. A risk-based inventory can reduce duplicated checks, while reusable components and automated regression checks help catch repeated issues earlier. They do not remove the need to validate changed instances and context-specific behavior.

For reliability, preserve test cases, environment details, build identifiers, and defect records so results can be repeated. Separate confirmed issues from tool warnings and untested scope. Include the relevant accessibility expertise in planning, and reserve time to verify fixes; a scan performed only at release often discovers issues after they are expensive to correct.

For screenshot evidence, use consistent viewport and state settings and retain only evidence needed to locate and verify a defect. ScreenshotNeo offers caching with a selectable TTL and asynchronous jobs among its options; its billing rules state that only clean shots are billed, while bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. The response includes page-verdict and billed headers. These are capture and cost details, not accessibility-testing guarantees. Check the documentation before integrating request parameters.

10. Common mistakes and troubleshooting

Problem	Likely cause	Correction
“The scan passed, so the site is compliant.”	Automated tools only detect part of the applicable requirements.	Use automation as one evidence source and complete systematic manual evaluation aligned to the applicable standards and agency process.
A defect cannot be reproduced.	The report omits route, state, environment, or interaction steps.	Record the exact URL, version, browser, viewport, steps, and expected/actual result. Capture supporting evidence if useful.
The report says “N/A” without explanation.	Applicability was not documented.	Identify the provision and explain why it does not apply to this product or tested scope.
A vendor ACR is treated as proof.	A vendor statement was mistaken for independent validation.	Review its version, scope, date, method, and explanations; validate the product against intended use and contractual requirements.
Keyboard users cannot reach or leave a control.	Custom interaction may omit expected keyboard behavior or focus management.	Reproduce with keyboard only, capture the sequence and state, map the applicable criterion, and verify the fix across the full interaction.
A screenshot looks correct but the issue remains.	Visual evidence does not expose semantic or assistive technology behavior.	Test the relevant code, accessibility tree, keyboard interaction, and assistive technology behavior as applicable.
A previously clean component fails after a release.	Markup, content, dependencies, or interaction changed after the earlier evaluation.	Retest the updated version and all affected instances; associate results with the new build.
A capture shows a clean page but not the banner or overlay under test.	Capture cleanup may remove consent banners, popups, or chat widgets.	For evidence about those elements, turn off the relevant cleanup step or use a capture method that preserves the actual tested state.

11. Section 508 testing checklist

Scope names the ICT, build/version, pages, tasks, environments, requirements, and exclusions.
Applicable Revised 508 provisions and agency or contract requirements are identified.
Automated checks are combined with appropriate manual inspection.
Testing method is repeatable and aligned with agency guidance; web testing considers Trusted Tester or Baseline alignment.
Critical flows, interaction states, and representative content are included.
Each applicable requirement has an outcome, and not-applicable results include rationale.
Defects include reproduction steps, environment, location, impact, and useful evidence.
Vendor ACR claims are checked against product version, intended use, and evidence needs.
Fixes are retested and results updated for the tested version.

12. Frequently asked questions

Is Section 508 the same as WCAG?

No. The Revised 508 Standards incorporate WCAG 2.0 Level A and AA success criteria for web content, but the applicable requirements depend on the ICT and relevant standards provisions.

Is an automated accessibility scan enough?

No. Automation can identify some issues efficiently, but federal guidance describes it as partial coverage. Use manual testing for requirements that depend on context and judgment.

No. Assistive technology testing can reveal valuable interaction and usability evidence, but it should not be the only method used to determine code conformance.

What is the difference between an ACR and a test report?

An ACR is a structured product-level statement, often supplied by a vendor. A test report records a specific evaluation in enough detail for teams to understand scope and reproduce defects.

Can a screenshot prove that a page is accessible?

No. It documents visible appearance at a particular state and viewport. It cannot establish keyboard access, semantic structure, accessible names, or screen reader behavior.

Does this guide determine whether my organization has a legal duty?

No. It explains federal ICT testing guidance. Determine obligations from the applicable law, agency program, solicitation, and contract, with appropriate legal or accessibility-program advice.