How to Fix Section 508 Accessibility Errors on Your Website

If your site must meet federal standards, Website Remediation Section 508 is the task of removing accessibility barriers so people who use assistive technology can use your pages. This guide lists common Section 508 errors, shows concrete fixes, and gives a practical remediation workflow you can follow right away.

What Section 508 requires for websites

Section 508 covers electronic and information technology produced by or for the federal government. The refreshed Section 508 standards for web content adopt the WCAG 2.0 Level AA success criteria as the technical reference. Many organisations also map their work to WCAG 2.1 or 2.2 for newer mobile and cognitive criteria.

How to find Section 508 accessibility errors

Run automated scans first, then verify with manual checks. Automated tools find some issues quickly. Manual checks catch real-world problems automated tools miss.

• Automated scanners: Axe, WAVE, Lighthouse are commonly used for quick coverage.
• Manual checks: keyboard-only navigation, testing with a screen reader such as NVDA or VoiceOver, and verifying contrast with a colour contrast tool.
• Document review: test PDFs and office documents with an accessibility checker in the authoring tool and by keyboard/screen reader testing.

Website Remediation Section 508: common errors and fixes

Below are the errors you will see most often and exact fixes you can apply in templates or component code.

1. Images missing alternative text

Problem: Decorative and meaningful images have no alt attribute or incorrect text. Fix: Add concise, functional alt text for meaningful images. Use empty alt for decorative images.

Example:

<!-- meaningful image -->
<img src="team-photo.jpg" alt="Two engineers reviewing a circuit board">

<!-- decorative image -->
<img src="divider.svg" alt="" aria-hidden="true">

2. Links with non-descriptive text

Problem: Links that read “click here” or “read more” do not make sense out of context. Fix: Use link text that describes the destination or purpose.

Example:

<!-- bad -->
<a href="/policy.pdf">Click here</a>

<!-- good -->
<a href="/policy.pdf">Download the privacy policy (PDF)</a>

3. Form controls missing labels

Problem: Inputs without associated labels and poor error announcements. Fix: Use <label> with a matching for/id, or aria-label, and connect error messages with aria-describedby.

<label for="email">Email address</label>
<input id="email" name="email" type="email" aria-describedby="email-error">
<div id="email-error" role="alert">Enter a valid email</div>

4. Poor keyboard focus and invisible focus states

Problem: Interactive elements are not reachable by keyboard or focus outline is removed. Fix: Ensure every interactive control is in the tab order and provide a visible focus style. Avoid tabindex>0 unless necessary.

/* CSS example for a clear focus state */
button:focus, a:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

5. Low colour contrast

Problem: Text fails contrast requirements. Fix: Adjust colours so foreground and background meet WCAG minimums. Use a contrast tool to confirm ratios for normal and large text.

6. Missing headings or incorrect heading order

Problem: Pages without semantic heading structure make navigation with assistive tech hard. Fix: Use <h2> to <h6> in logical order and avoid skipping levels solely for styling.

7. Inaccessible tables

Problem: Data tables lack header cells or captions. Fix: Add <caption> and use <th> with scope attributes for row or column headers.

<table>
  <caption>Quarterly sales by region</caption>
  <thead>
    <tr>
      <th scope="col">Region</th>
      <th scope="col">Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">North</th>
      <td>£120,000</td>
    </tr>
  </tbody>
</table>

8. Video without captions or audio description

Problem: Videos lack captions and transcripts. Fix: Provide accurate captions, a text transcript, and audio description when visual information is essential.

9. ARIA misuse and empty roles

Problem: Incorrect ARIA attributes can make content less accessible than plain HTML. Fix: Use native HTML first. Add ARIA only when needed and follow WAI-ARIA patterns for dialogs, menus and alerts.

10. Inaccessible PDFs and documents

Problem: PDFs created without tags or reading order are not accessible. Fix: Start with accessible source files, tag documents, provide a text alternative or HTML version, and test with a screen reader.

Step-by-step remediation workflow

1. Triage pages by risk: high-traffic pages, transactional pages, and pages likely to be requested under law first.
2. Run automated scans across the site to get a coverage baseline.
3. Manually test a representative set of pages with keyboard and screen reader.
4. Fix issues in templates and components first. This prevents repeating fixes on many pages.
5. Create tickets with clear steps to reproduce, the failed success criterion, and the recommended code change.
6. Validate fixes with automated and manual tests, then deploy to staging for a final review.

Pre-release accessibility checklist

• Keyboard navigation works for all interactive controls.
• Meaningful images have alt text; decorative images are empty alt.
• Forms have labels and clear error messaging announced to assistive tech.
• Contrast meets WCAG minimums for normal and large text.
• Headings form a logical document outline. Landmarks are present (header, main, nav, footer).
• Multimedia has captions, transcripts, and controls are keyboard operable.
• PDFs either are tagged or an accessible HTML alternative exists.
• No ARIA used where native HTML works. ARIA follows WAI-ARIA design patterns.

Tools and testing resources

Use a mixture of automated tools and people. Automated checks catch many issues fast. Manual tests reveal keyboard and screen reader problems that scanners miss.

• Automated scanners for bulk coverage.
• Screen readers such as NVDA or VoiceOver for real behaviour.
• Colour contrast checkers and keyboard-only testing.
• Document authoring tools that include accessibility checks for Word and PDF content.

When to hire an accessibility specialist

Bring in an expert when you need a full audit, remediation planning for many pages, or help implementing complex interactive components such as custom widgets, modal dialogs or dynamic single-page applications. A specialist can produce an accessibility conformance report and help set testable standards for your team.

Governance: keep accessibility fixed, not one-off

Make accessibility part of your release process. Add an accessibility gate to pull requests, train designers and developers on semantic HTML and WAI-ARIA, and schedule periodic audits. Track accessibility defects like other bugs and measure remediation time.

Final checklist before you close a remediation ticket

• Document the issue, the code change, and the WCAG success criteria addressed.
• Confirm fix with automated scan and with a screen reader and keyboard test.
• Update component tests and QA scripts so the issue does not regress.
• Publish a short note in the release log describing the accessibility improvement.

Following these steps will help you turn Website Remediation Section 508 work from ad hoc fixes into repeatable, measurable improvements. If you need a remediation plan for a large site, focus first on templates and high-risk pages, then scale fixes across components.