Government website accessibility is governed by two connected rulebooks: Section 508 of the Rehabilitation Act, which applies to federal agencies, and the Web Content Accessibility Guidelines (WCAG), the technical standard those rules point to. In practice, a federal site must be built so people using screen readers, keyboards instead of mice, or other assistive tools can perceive, understand, navigate, and interact with every page. The same standards shape state benefits portals, which follow their own mix of federal and state law.
The stakes are concrete. A veteran checking claim status, a parent renewing benefits, or a taxpayer filing a return all meet the government through a browser. When a page blocks a screen reader or traps a keyboard user in a menu, that person loses access to a public service, not just a shopping cart. As the W3C's Web Accessibility Initiative puts it, the web is designed to work for everyone, whatever their hardware, software, or ability, and badly built sites create barriers that exclude people.
This article explains where the rules come from, what WCAG actually asks developers to do, and the failure points that show up again and again in agency sites. It also covers what a blocked user experiences, because that experience is the reason the standards exist.
Where the legal requirements come from
The anchor is the Section 508 Amendment to the Rehabilitation Act of 1973, which requires federal agencies to make their electronic and information technology accessible. Section 508 does not spell out every technical detail itself. It points to a technical standard, and that standard incorporates WCAG, the guidelines published by the World Wide Web Consortium (W3C), the body that maintains the web's core specifications.
WCAG is not just a US rulebook. Background material on accessibility law lists both Section 508 and WCAG among the government mandates that standardize accessibility testing in product development, alongside laws in other countries. WCAG 2.2 has also been adopted as an international standard, ISO/IEC 40500, which means a contractor building for one agency is likely working against the same benchmark everywhere.
One distinction trips up readers: the Americans with Disabilities Act standards maintained by the US Access Board govern physical facilities, such as ramps, entrances, and state and local government buildings, not websites. The Access Board explains that its ADA standards apply to places of public accommodation and government facilities in new construction and alterations. Digital accessibility for federal agencies runs through Section 508 instead. State and local government websites sit in a different legal lane, and the exact obligation can vary, so agencies and vendors track both the physical and digital rulebooks.
What WCAG actually requires
WCAG organizes its requirements around four qualities a page must have. Content must be perceivable, meaning users can sense it in some form, whether by sight, sound, or touch. It must be operable, meaning every control works no matter how the user inputs commands. It must be understandable, with predictable behavior and clear language. And it must be robust, meaning it works with the assistive technologies people actually use, including current and older browsers and screen readers.
Those principles translate into specific, checkable practices. The W3C's own introduction to web accessibility gives the classic examples. Images need alternative text ("alt text") in the code, so a screen reader can speak what the picture shows; without it, the image's information simply never reaches a blind user. All functionality must work from a keyboard, because many people cannot use a mouse, including many older users with limited fine motor control. Audio files need text transcripts so deaf users get the same information hearing users get.
WCAG also carries conformance levels, labeled A, AA, and AAA, with AA as the level most legal requirements target. The levels stack: AA includes everything in A plus additional requirements. The higher levels demand more contrast, more flexibility, and more tolerance for user settings, which is why AAA is treated as an aspiration rather than a baseline for whole sites.
The web's power is its universality. When a page assumes every visitor sees, hears, and clicks the same way, it stops being universal.
Where agency sites fail audits
The recurring failures are rarely exotic. They are the basics, left undone at scale:
- Missing or useless alt text. Charts on a benefits page that say only "chart" or "image" convey nothing to a screen reader user trying to learn an eligibility rule.
- Keyboard traps and unreachable controls. A menu, date picker, or file uploader that a keyboard user cannot reach or escape blocks the whole task, not just one step.
- Forms without labels. A field that shows only a placeholder hint, with no programmatic label, leaves screen reader users guessing what to type.
- Poor color contrast and color-only meaning. Light gray text on white, or errors marked only by a red border, fail users with low vision or color blindness.
- Documents that never got fixed. A compliant web page linking to an inaccessible PDF still delivers an inaccessible service.
A pattern worth naming: problems cluster at the edges of the page, in the widgets and third-party embeds that agencies buy rather than build. A homepage may pass while the payment widget inside it fails. That is why audits examine whole user journeys, not just landing pages.
Another practical limit: the W3C is explicit that no automated tool alone can determine whether a site meets accessibility guidelines, and that knowledgeable human evaluation is required. Automated scanners catch missing alt text and contrast ratios, but they cannot judge whether a page makes sense in the order a screen reader will read it. Agencies that treat a clean scan as compliance have tested the easiest third of the problem.
What a blocked user actually experiences
Picture a benefits portal with a multi-step application. A blind user's screen reader reads the page aloud, but the "Next" button has no accessible name, so the reader announces it as unlabeled. A keyboard-only user tabs through the page and hits a calendar widget that swallows the Tab key; there is no way out except closing the browser. A user with low vision enlarges the text, and the fixed-width layout clips half of every sentence.
None of these users can call a caseworker to fix the code. The barrier is the service. This is why the W3C frames web access as an equal-opportunity issue, noting that access to information and communications technology is defined as a basic right in the United Nations Convention on the Rights of Persons with Disabilities, whose Article 9 commits signatories to accessibility across their systems.
The same fixes help people without disabilities. Captions serve someone reading in a noisy room. Keyboard support serves someone with a broken arm. Strong contrast serves everyone on a phone in sunlight. Accessibility work is usability work with a narrower, higher-stakes audience.
What this means for agencies and vendors
Our analysis of how these projects go right versus wrong comes down to timing. The W3C advises building accessibility in from the very beginning of a project, because retrofitting a finished site means redoing work. That advice lands hardest in procurement: if a state buys a benefits platform without accessibility requirements written into the contract, it inherits the vendor's barriers. The same procurement dynamics that drive cost overruns in how states procure benefits software apply here, since accessibility found late is change-order work. We covered a connected angle in Benefits system procurement: How states procure benefits software, and why modernization projects run over budget.
For agencies, a workable sequence looks like this:
- Write accessibility conformance into contracts and statements of work, naming the standard and level.
- Evaluate early and throughout development, combining automated scans with human testing by people who use assistive technology.
- Test real journeys, such as applying, appealing, and paying, not individual pages.
- Fix documents, not just web pages, since PDFs and forms are part of the service.
Vendors serving government have noticed the market signal. Microsoft's accessibility programs, from its Disability Answer Desk to its chief accessibility officer role, reflect how large suppliers now treat accessibility as a product requirement rather than an afterthought, a posture agencies increasingly demand in bids.
Accessibility also connects to adjacent obligations. The plain-language rules described in what the Plain Writing Act requires of government documents serve the same goal from the content side: a screen reader reads faster and clearer when the writing is clear. And agencies building to the design baseline in the federal website design standards start from components that have accessibility behavior built in, which removes entire classes of failure.
Where to get an official answer
The rules above describe the general framework, and they change: WCAG versions update, and agency regulations follow. For an individual question about a specific site or program, the official channel is the agency itself, through the contact or accessibility statement on its own site. Federal agencies generally publish an accessibility statement and a feedback route, and Section 508 questions can be raised with the agency's Section 508 coordinator.
SocialGov is an independent publication, not a government agency or portal. It cannot process applications or issue determinations about any site's compliance. What it can do is explain the system, and the system's core promise is simple: a government website that works for everyone, checked by humans as well as machines.
