Section 508 accessibility: what a data product must actually do

The rule, stated precisely

Section 508 of the Rehabilitation Act of 1973, as amended, is codified at 29 U.S.C. § 794d. It says that when a federal agency develops, procures, maintains, or uses information and communication technology, that technology has to be accessible to federal employees with disabilities and to members of the public with disabilities seeking information from the agency, on terms comparable to the access everyone else gets. The operative words for a technology vendor are "procures" and "uses." A product an agency buys and runs is squarely in scope.

The technical content does not live in the statute. Congress assigned standard-setting to the U.S. Access Board, and the Board's Revised 508 Standards are codified at 36 CFR Part 1194. The revision published on January 18, 2017 at 82 FR 5790, carried a compliance date of January 18, 2018, and replaced a 1998-era rule organized around product categories with one organized around functions. Anyone still working from a checklist that talks about "web-based intranet and internet information and applications" under the old §1194.22 is two standards behind.

The most useful single fact about 36 CFR Part 1194 is that it does not write its own web rules. Appendix A, provision E205.4, says electronic content shall conform to Level A and Level AA success criteria and conformance requirements in WCAG 2.0. Provision E207.2 says the same for software with a user interface. So the regulatory floor for a federal deliverable is WCAG 2.0 Level AA, applied through the Access Board's scoping. Agencies routinely ask for WCAG 2.1 AA or 2.2 AA in the solicitation itself, because the later versions cover reflow, mobile gestures, and status messages that 2.0 never addressed. Read the solicitation. A contract can require more than the regulation. It cannot require less.

Who it binds, and how it reaches a vendor

Section 508 binds agencies, not companies. That distinction confuses people and it helps a vendor not at all, because the agency's obligation arrives inside the vendor's contract. FAR subpart 39.2 is the delivery mechanism. FAR 39.203 requires that requirements documents and solicitations for information and communication technology identify the applicable standards at 36 CFR 1194, and that the contracting officer specify them. FAR 39.204 lists the exceptions, and they are narrow: technology acquired by a contractor incidental to a contract; a national security system as defined at 40 U.S.C. 11103(a); technology located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring; undue burden on the agency; and fundamental alteration in the nature of the technology or its function.

Two of those get misread constantly. "Incidental to a contract" covers the contractor's own working tools that are never delivered, such as the internal project tracker used to run the job. It does not exempt the product being handed over. And undue burden is an agency determination made in writing by the head of the agency or a designee, with the basis documented; under E202.6 the agency still has to provide access by an alternative means. It is not a box a vendor gets to check.

Dollar value is not on the exception list either. A $9,000 analytics subscription bought under the $10,000 micro-purchase threshold at FAR 2.101 carries the same accessibility scoping as a $2 million platform bought well over the $250,000 simplified acquisition threshold. There is one shelter worth knowing: provision E202.2 exempts unaltered legacy technology that met the original 1998 standards. The moment a component is altered, the shelter lapses for that component. A modernization effort on an old reporting system therefore removes the protection the old system had, which is why accessibility shows up in modernization solicitations with unusual force.

The chapters that actually govern a data product

Appendix C to Part 1194 holds the technical requirements, and four chapters matter to software. Chapter 3 is the Functional Performance Criteria. Chapter 4 covers hardware. Chapter 5 covers software, provisions 501 through 504. Chapter 6 covers support documentation and services, provisions 601 through 603. A vendor shipping a web application is answering Chapters 3, 5, and 6, plus the WCAG mapping that E205.4 and E207.2 pull in.

Provision 302 is written as outcomes rather than code. It requires that the product be usable without vision (302.1), with limited vision (302.2), without perception of color (302.3), without hearing (302.4), with limited hearing (302.5), without speech (302.6), with limited manipulation (302.7), with limited reach and strength (302.8), and with limited language, cognitive, and learning abilities (302.9). When no technical provision addresses a particular feature, 302 is the fallback test, and it is the provision a skeptical reviewer reaches for when a novel interface does something WCAG never anticipated.

Provision 502 is interoperability with assistive technology, and it is where custom data components die. 502.2 requires that documented accessibility features actually work. 502.3 enumerates what has to be exposed through the platform accessibility services, running from 502.3.1 through 502.3.14: object information, row and column identification, values, label relationships, hierarchical relationships, text attributes, list of available actions, focus and selection attributes, modification of values and text, and event notification. A virtualized grid drawn from styled containers exposes none of that. Neither does a chart painted to a canvas element. Provision 503 then covers the application layer, including 503.2, which forbids a product from disrupting platform settings for color, contrast, font type, font size, and focus cursor, and 503.4, which requires user controls for captions and audio description wherever the product plays video.

The part data products keep missing

Provision 504 covers authoring tools, and it catches analytics platforms by surprise. If the product lets a user create or edit content, and building a dashboard, composing a report, or defining a chart all qualify, then the product is an authoring tool for the purposes of 504. Provision 504.2 requires the tool to enable the creation of content that conforms to WCAG 2.0 Level AA. Provision 504.2.1 requires that accessibility information survive format conversion whenever the conversion is under the tool's control. Provision 504.3 requires the tool to prompt authors toward conforming content. Provision 504.4 requires that where the tool ships templates, at least one template supporting conforming content be available.

In plain terms: the dashboard your customer builds inside your product is your problem. If a user can drop an image into a report with no field for a text alternative, the product fails 504.3. If the export path emits an untagged PDF, it fails 504.2.1. Untagged output is the single most common defect we find in federal data products, and it is the one most often discovered by the customer rather than the vendor, because the vendor tested the screen and never opened the artifact. Provision E205.4.1 closes that door explicitly by substituting "content" for "web page" when WCAG is applied to non-web documents, so a generated PDF or spreadsheet is measured against the same success criteria as the application that produced it.

Chapter 6 is the other blind spot. Provision 602.2 requires that documentation describe the product's accessibility and compatibility features. Provision 602.3 requires that electronic support documentation itself conform to WCAG 2.0 Level AA, which means the user guide, the online help, the API reference, and the training deck are all in scope. Provision 603.2 requires support services to provide information on accessibility features, and 603.3 requires them to accommodate the communication needs of users with disabilities. A perfectly accessible application delivered with an inaccessible PDF administrator guide is a nonconforming delivery, and that finding is trivially easy for a reviewer to make.

The artifacts that have to exist

Conformance is a claim, and a claim needs evidence attached to it. Six artifacts carry the weight, and a vendor that has all six is ready for any federal, state, or local buyer.

Artifact	What it is	Where it gets checked
Accessibility Conformance Report	Provision-by-provision statement against the Revised 508 Standards, normally written on the VPAT	Requested with the proposal; re-verified at acceptance
Test results	Raw output from the process used, typically manual test records plus automated scan logs	Requested whenever the report is challenged
Accessibility statement	Published page naming the standard, known limitations, and how to report a barrier	OMB M-24-08 pushed agencies to publish these; buyers now ask vendors for the equivalent
Remediation plan	Dated list of open defects with severity and committed fix dates	Attached wherever the report says "Partially Supports"
Tagged output samples	Real exports the product generates, not files repaired by hand	Acceptance testing, and the fastest place to fail
Support documentation set	Help, guides, API docs, and training material, each conforming under 602.3	Delivery review

What a conformance report is worth

The Voluntary Product Accessibility Template is maintained by the Information Technology Industry Council and ships in four editions: a WCAG edition, a Revised Section 508 edition, a European edition keyed to EN 301 549, and an international edition covering all three. For a federal buy, fill out the Revised Section 508 edition, because it walks Chapters 3 through 6 in the order an agency reviewer expects and maps the WCAG criteria alongside them. A completed template is called an Accessibility Conformance Report. The template is the blank form; the report is the filled one, and solicitations ask for the latter.

The conformance language is fixed and it carries meaning. "Supports" means the functionality meets the criterion with no known defects. "Partially Supports" means some functionality does not. "Does Not Support" means the majority does not. "Not Applicable" means the criterion has no bearing on the product. The remarks column is where credibility is won or lost. A report claiming "Supports" on every criterion with an empty remarks column reads, to an experienced accessibility program manager, as a document nobody tested. A report that marks 1.4.11 as "Partially Supports" and notes that three chart legend swatches measure 2.8:1 against the panel background with a fix committed for the next release reads as a vendor who did the work. The second one wins evaluations. The first one invites a request for test evidence that does not exist.

GSA runs an Accessibility Requirements Tool at buyer.section508.gov that contracting officers use to generate requirement language and acceptance criteria for a solicitation. Reading the output of that tool is the cheapest hour a vendor can spend, because it shows exactly what will be asked for before anyone asks.

What gets found on a data product

Findings repeat. Across analytics platforms, reporting systems, and case-management front ends, the same defects appear in nearly the same order:

• Tables that are not tables. Grids built from generic containers with no header cells, no scope, and no caption. Fails WCAG 1.3.1 and provision 502.3.
• Charts with no text equivalent. A canvas or bitmap chart with no alternative text and no equivalent data table behind it. Fails 1.1.1.
• Status carried by color alone. Red, amber, and green cells with no icon, label, or pattern. Fails 1.4.1 and provision 302.3.
• Contrast below threshold. Text under 4.5:1, and interface components or graphical objects under 3:1. Chart series palettes, disabled buttons, and focus rings are the repeat offenders. Fails 1.4.3 and 1.4.11.
• Keyboard traps and lost focus. Filter modals that cannot be exited from the keyboard, and focus thrown back to the top of the document every time a query reruns. Fails 2.1.2, 2.4.3, and 2.4.7.
• Silent updates. A filtered table repaints with 12 rows instead of 4,000 and announces nothing. Fails 4.1.3 under WCAG 2.1; under 2.0 it lands squarely on provision 302.1.
• Placeholder text used as a label. The filter input's only name disappears the instant the user types. Fails 1.3.1, 3.3.2, and 4.1.2.
• Session timeout with no warning. A long-running query discarded with no notice and no way to extend. Fails 2.2.1.
• Untagged and unstructured exports. PDFs with no tag tree, spreadsheets with merged header cells and no defined header row, documents with visual headings that are not real headings.
• Map layers with no non-visual path. Features reachable only by pointer, with no table of the same records and no keyboard route to a feature's attributes.

None of these are exotic. Almost all of them trace back to three early decisions: the grid component, the charting library, and the export path bolted on near the end. That is why the sequence below puts component selection ahead of screen-level remediation.

The cost of getting it wrong

Start with the proposal, because that is where the first bill arrives. When a solicitation makes a conformance report a submission requirement and an offeror submits nothing, or submits one written for a different product version, the evaluation record has a hole in it that anyone can see. A technically unacceptable rating on a checkable submission item is the cheapest possible loss for an agency to document and defend.

After award, 29 U.S.C. § 794d(f) gives an individual with a disability an administrative complaint route against the agency and a private right of action, with the remedies of section 505 of the Rehabilitation Act at 29 U.S.C. § 794a, which carries attorney's fees. The agency is the named party. The agency then looks down the contract, through acceptance criteria and warranty terms, at the vendor whose product created the barrier.

The ordinary cost is quieter and larger than either: rework. Retrofitting accessibility into a shipped analytics product usually means replacing the grid component, replacing the chart layer, and rebuilding the export pipeline. Those three pieces are most of a front end. Doing that work at design time costs a fraction of doing it at acceptance, and doing it at acceptance costs a fraction of doing it under a signed corrective action plan with a delivery date and a customer watching.

Where the state and local line sits now

A vendor selling the same product to a state agency or a city is no longer working in a different rule set. Many states adopt the federal standards by reference, and states accepting grant funds under the Assistive Technology Act of 1998 give an assurance that they comply with Section 508. The larger change came from the Department of Justice. Its ADA Title II rule for web content and mobile applications published on April 24, 2024 at 89 FR 31320, adding subpart H to 28 CFR Part 35, and it sets WCAG 2.1 Level AA as the standard for state and local government web content and mobile apps. Compliance was required by April 24, 2026 for public entities serving 50,000 or more people, and is required by April 26, 2027 for smaller entities and special district governments.

For a product team, that convergence is good news. One conformance target now serves the federal, state, and local pipeline: build to WCAG 2.1 Level AA, report against the Revised Section 508 edition of the template, and the same evidence answers all three buyers. Building only to WCAG 2.0 because that is what 36 CFR 1194 cites leaves a gap that a county customer will find in 2027.

A sequence that works the first time through

The order is doing real work. Fixing contrast before fixing focus order wastes the contrast effort, because focus indicators carry their own contrast requirement and the focus work moves them. Fixing screens before fixing components means fixing the same defect once per screen, forever. And writing the conformance report before the test evidence exists produces the empty-remarks document that reviewers discount on sight.

Testing: what actually catches defects

Automated scanning is necessary and insufficient. Rule engines such as axe-core, Pa11y, WAVE, and ANDI, the inspector published by the Social Security Administration, all find the same broad class of machine-detectable failures: missing text alternatives, missing form labels, empty links, many contrast failures, and some ARIA misuse. They find a minority of real WCAG failures and they say almost nothing about whether the workflow is usable. A product that passes a scan cleanly can still be impossible to operate from a keyboard.

The manual process federal reviewers know is DHS's Trusted Tester, currently version 5.1, built on the ICT Testing Baseline for Web maintained by the interagency accessibility community through Section508.gov. It reads as a deterministic script: perform these steps, in this order, with the keyboard and a specified inspection tool, and record the result. Two testers running it against the same page should reach the same conclusion. That reproducibility is why agencies accept its output, and why a conformance report backed by it survives a challenge that a report backed by a scanner screenshot does not.

Assistive technology testing is the third layer and the one that changes designs. NVDA with Firefox and JAWS with Chrome cover most federal desktop use; VoiceOver on iOS and TalkBack on Android cover mobile. Anyone who has listened to a screen reader read a filtered table will find the announcement gaps no scanner reports, and will stop shipping status messages that exist only as a color change in the corner of a chart.

Before you submit

• Conformance report written on the Revised Section 508 edition, for the exact product version being offered
• Every "Partially Supports" carries a specific remark and a dated fix commitment
• Real product exports tested as artifacts: tagged PDF, structured spreadsheet, documents with true heading styles
• Help, user guide, API reference, and training material tested to the same standard under 602.3
• Keyboard-only pass across the full primary workflow, with a visible focus indicator at every step
• Screen-reader pass on the highest-traffic screens using real assistive technology, not a browser simulator
• Contrast measured on chart series, disabled states, and focus rings, not only on body text
• Support desk briefed on 603.2 and 603.3, with an accessibility contact published

Bottom line

Section 508 asks a narrow question with a checkable answer: can a person using assistive technology do the same work, on the same terms, as everyone else? For a data product the answer lives in five places most teams never test, which are the grid, the chart, the export, the documentation, and the help desk. Fix the components first, test the artifacts rather than the screens, and write a conformance report a program manager can believe. Done in that order, accessibility stops being a risk item on a schedule and becomes a differentiator in a source selection where half the field submitted a blank template with every row marked "Supports."

Frequently asked questions