The Most Common Section 508 Violations on Government Websites (And How to Fix Them Fast)

Your government website probably has accessibility violations you don’t know about yet.

Not because your team doesn’t care. Because the most common Section 508 violations are easy to miss, show up consistently across every federal agency, and are rarely caught by automated tools alone. The FY2024 Governmentwide Section 508 Assessment found that the federal government’s average conformance score actually dropped year over year, falling to 1.74 out of 5, and intranet testing coverage fell sharply, with agencies testing just 8% of their internal web pages.

The good news: the violations that appear most often are also the most fixable. Here’s what they are, why they matter, and exactly how to address them.

Why Do Section 508 Violations Keep Happening?

Most accessibility failures on government websites aren’t the result of bad code. They’re the result of process gaps. Content gets published without review. PDFs get uploaded without tagging. Videos go live without captions. Forms get built by developers who’ve never tested with a screen reader.

The FY2024 Assessment found that nearly half of respondents lacked the resources to test their highest-traffic digital assets, including top-viewed web pages, documents, and videos. When teams don’t have the tools or trained staff to catch issues before publishing, violations accumulate faster than they can be remediated.

Understanding which violations happen most often is the first step to stopping them at the source.

Violation 1: Missing or Inadequate Alt Text on Images

What it is: Images, charts, icons, and graphics that have no alternative text, or alt text that simply repeats the file name (“image001.png”) or states the obvious (“photo of a man”).

Why it matters: Screen readers used by blind and low-vision users read alt text aloud in place of the image. Without it, the user gets nothing, or worse, a string of meaningless characters. Images, icons, and graphics missing alternative text means screen readers cannot interpret the content, making it inaccessible to many people who are blind or have low vision.

How to fix it fast:

• Add descriptive alt text to every non-decorative image. Describe what the image shows and why it’s there, not just what it looks like.
• For charts and graphs, describe the key takeaway in the alt text (e.g., “Bar chart showing a 40% increase in applications from 2022 to 2024”).
• For purely decorative images, use an empty alt attribute (alt="") so screen readers skip them.
• For images of text, reproduce the text in the alt attribute word for word.

Tool to use: WAVE (wave.webaim.org) flags missing alt text automatically and shows you exactly which images on a page are missing it.

Violation 2: Insufficient Color Contrast

What it is: Text that doesn’t have enough visual separation from its background, making it hard or impossible to read for users with low vision or color blindness.

Why it matters: Insufficient contrast between text and background colors means users with low vision or color blindness may struggle to read content. This is one of the most common violations across government sites and one of the easiest to overlook during design, especially when brand colors are involved.

The standard: WCAG 2.0 Success Criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for larger text. For reference, black text on a white background has a contrast ratio of 21:1.

How to fix it fast:

• Run your site through the WebAIM Contrast Checker (webaim.org/resources/contrastchecker) to test any color combination before publishing.
• Check body text, navigation links, button labels, form field text, and placeholder text, all of which are frequently overlooked.
• For UI components like buttons, form inputs, and focus indicators, a 3:1 contrast ratio is required.
• Never rely on color alone to convey meaning. Use text labels, icons, or patterns alongside color.

Tool to use: Axe DevTools browser extension highlights contrast failures directly on the page while you’re browsing.

Violation 3: Videos Without Captions or Transcripts

What it is: Video content published without synchronized closed captions, or with auto-generated captions that haven’t been reviewed for accuracy.

Why it matters: Users who are deaf or hard of hearing rely on captions to access audio information. Users who are blind need audio descriptions when key information is conveyed visually but not spoken. Auto-generated captions from YouTube or other platforms frequently contain errors, especially with technical terminology, names, or acronyms common in government content.

The standard: All prerecorded video content that contains audio must have captions. Live captions are also required for live multimedia content when it’s part of public-facing or official agency communication. Transcripts must be available for all prerecorded multimedia.

How to fix it fast:

• Before uploading any video, create or review a caption file (.vtt or .srt format). Don’t publish and rely on auto-captions.
• Review auto-generated captions for accuracy, particularly for acronyms, program names, and technical terms.
• Host videos on YouTube or a similar platform where caption tracks can be added and edited easily.
• Add a full text transcript beneath every video or link to one on a separate accessible page.
• For videos with important visual content not described in the audio (e.g., a demonstration, a chart being referenced), add an audio description track or extended description in the transcript.

Tool to use: YouTube’s caption editor allows you to correct auto-generated captions line by line before making a video public.

Violation 4: Inaccessible PDFs and Electronic Documents

What it is: PDFs and other documents that are missing tag structure, have incorrect reading order, use images of text, or were created by scanning a paper document without running optical character recognition (OCR).

Why it matters: Screen reader users may find it challenging or impossible to navigate or understand untagged documents. If documents come from scanned copies, they must be scanned as text, not images. A PDF that looks perfectly formatted on screen can be completely unreadable to a screen reader if the underlying tag structure is absent or wrong.

This is the hardest category to fix at scale. Many agencies have hundreds or thousands of legacy PDFs that were never tagged, and retroactive remediation is time-consuming.

How to fix it fast:

• For new documents: create them in Word or Google Docs with proper heading structure (H1, H2, H3), then export to PDF using the “Save as PDF” or “Export” function, not “Print to PDF,” which strips tags.
• For existing PDFs: open in Adobe Acrobat Pro, run the Accessibility Checker (under Tools > Accessibility), and use the Reading Order and Tags panel to fix issues.
• For scanned PDFs: run OCR first (Acrobat Pro > Scan and OCR > Recognize Text) before adding tags.
• Add alt text to all images within PDFs, set the document language, and ensure the title is set in Document Properties.
• Where possible, replace high-traffic PDFs with accessible HTML pages, which are easier to maintain and work more reliably with assistive technology.

Tool to use: Adobe Acrobat Pro’s built-in Accessibility Checker is the most practical starting point for document remediation.

Violation 5: Non-Keyboard-Navigable Content

What it is: Page elements, menus, forms, or interactive components that can only be activated with a mouse, with no keyboard equivalent.

Why it matters: Many users with motor disabilities, and virtually all screen reader users, navigate entirely by keyboard using Tab, Enter, arrow keys, and keyboard shortcuts. When content does not support keyboard navigation, users who interact with content using the keyboard only may be unable to fully engage with it.

How to fix it fast:

• Test your site right now: close the mouse and try to navigate using only the Tab key. Can you reach every link, button, form field, and menu item? Can you see where your focus is at all times?
• Ensure all interactive elements (dropdowns, modals, carousels, date pickers) are keyboard operable and have a visible focus indicator.
• Never remove the default browser focus outline with outline: none in CSS without replacing it with a visible custom focus style.
• Ensure modal dialogs trap focus inside the modal while open, and return focus to the triggering element when closed.
• Use native HTML elements (button, a, input) wherever possible instead of custom div or span elements with click handlers.

Tool to use: Manual keyboard testing is the only reliable method here. Automated tools frequently miss keyboard navigation issues entirely.

Violation 6: Missing or Generic Link Text

What it is: Hyperlinks with text like “click here,” “read more,” “learn more,” or “here” instead of descriptive text that tells the user where the link goes.

Why it matters: Screen reader users frequently navigate a page by jumping between links, hearing only the link text without surrounding context. A list of “click here” links is completely meaningless. Non-descriptive links may create confusion for screen reader users who need context to understand where a link will lead.

How to fix it fast:

• Replace generic link text with descriptive text that makes sense out of context. Instead of “click here to download the report,” write “Download the FY2024 Section 508 Assessment Report (PDF).”
• Include the file format and size in parentheses when linking to non-HTML files (PDF, DOCX, XLSX) so users know what to expect.
• Avoid linking the same text to different destinations on the same page.
• Do not use the raw URL as link text (e.g., “https://www.section508.gov/manage/…”). Use a descriptive label instead.

Tool to use: WAVE identifies ambiguous link text automatically. A manual audit takes just minutes on most pages.

Violation 7: Inaccessible Forms

What it is: Web forms with unlabeled fields, unclear error messages, fields that require mouse interaction, or instructions that only appear as placeholder text inside the field.

Why it matters: Forms are one of the most critical interaction points on government websites, used to apply for benefits, submit requests, register for programs, and more. An inaccessible form can completely block a user from accessing a service they’re entitled to.

How to fix it fast:

• Every form field needs a programmatically associated label, not just visible text nearby. Use the HTML for attribute on labels and the matching id on inputs.
• Never use placeholder text as the only label. Placeholder text disappears when the user starts typing and is often low-contrast.
• Error messages must identify the specific field with the error and explain how to fix it, not just say “please correct the errors above.”
• Required fields must be indicated in a way that doesn’t rely on color alone (e.g., asterisk with a legend explaining it).
• Test every form with a screen reader before publishing.

Tool to use: Axe DevTools and WAVE both detect unlabeled form fields. Manual testing with NVDA (free) or VoiceOver (built into Mac and iOS) catches what automated tools miss.

How Do I Know Which Violations My Site Has?

Start with a layered approach:

Step 1: Automated scan. Run your highest-traffic pages through WAVE (wave.webaim.org) or the Axe browser extension. These tools catch roughly 30 to 40% of real-world accessibility issues and give you a fast snapshot of the most obvious violations.

Step 2: Keyboard test. Close the mouse. Tab through the entire page. Note anything that’s unreachable, invisible, or broken.

Step 3: Screen reader test. Download NVDA (free, Windows) or use VoiceOver (built into Mac and iOS). Navigate a page as a screen reader user would. Listen to how images are announced, how forms are read, how links are described.

Step 4: Document audit. Open your top five most-downloaded PDFs in Adobe Acrobat Pro and run the Accessibility Checker on each one.

Step 5: Video review. Pull up your five most-viewed videos. Watch each one with the sound off using only captions. Are the captions accurate, timed correctly, and readable?

This five-step process will surface the vast majority of issues on any government site in a few hours.

Frequently Asked Questions About Section 508 Violations

Can automated tools catch all Section 508 violations? No. Automated tools reliably catch roughly 30 to 40% of accessibility issues. The rest require manual testing, particularly for keyboard navigation, screen reader compatibility, logical reading order, and meaningful alt text. Automated tools cannot determine whether alt text is actually descriptive or just present.

What are the most common Section 508 violations in PDFs? Missing tag structure, incorrect reading order, images without alt text, documents created by scanning without OCR, missing document title in properties, and tables without proper header markup are the most frequent PDF issues. Legacy scanned documents are the hardest category to remediate at scale.

How do I fix auto-generated YouTube captions for Section 508? Go to YouTube Studio, select the video, open Subtitles, and click the auto-generated caption track to edit it. Review every line for accuracy, correct any errors (especially acronyms and technical terms), and save. You can also upload a corrected .vtt or .srt caption file to replace the auto-generated version entirely.

What is the minimum color contrast ratio required by Section 508? The standard requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt and above, or 14pt bold and above). Use the WebAIM Contrast Checker to verify any color combination before publishing.

Does Section 508 apply to PDFs on government websites? Yes. All PDFs published on federal agency websites, including forms, reports, and guidance documents, must be fully accessible. OMB M-24-08 also recommends using HTML as the default format instead of PDF wherever possible, since HTML works more reliably with assistive technology at scale.

How long does it take to fix a Section 508 violation? It depends on the type. Adding alt text to a single image takes under a minute. Fixing a form label takes minutes. Remediating a complex, untagged 50-page PDF can take several hours. Missing captions on a 30-minute video may take two to four hours to caption and review. The key is building accessible practices into your creation process so violations don’t accumulate.

Related Topics to Explore

• What Government Agencies Need to Know About Section 508 Compliance in 2026 (start here if you need the full legal overview)
• How to Remediate PDFs for Section 508 Compliance (step-by-step guide for the most complex violation category)
• How to Build a Section 508 Testing Program from Scratch
• WCAG 2.0 vs. WCAG 2.2: What’s Changing and What It Means for Federal Agencies
• Section 508 and Procurement: What Contracting Officers Need to Know
• Understanding and Evaluating VPATs

The Bottom Line

The violations covered here show up on government websites constantly, not because agencies don’t care about accessibility, but because publishing workflows rarely have accessibility built in as a checkpoint. Alt text gets skipped. PDFs get uploaded as-is. Videos go live before captions are reviewed. Forms go out the door without a keyboard test.

Every one of these is fixable. Most don’t require a developer. They require a process: a content checklist, a review step before publishing, and staff who know what to look for.

Start with your five highest-traffic pages and your five most-downloaded documents. Run the automated scan, do the keyboard test, and listen to a screen reader navigate the page. What you hear will tell you exactly where to start.

For official guidance and free testing resources, visit Section508.gov. The WebAIM Contrast Checker and WAVE tool are both free and require no account to use.