# How to Fix Common Accessibility Issues Found by Automated Scanners

You just ran an automated accessibility scan on your website and the report came back with dozens, maybe hundreds, of violations. The list looks overwhelming, but here is the good news: most automated scanners flag the same core set of issues, and every one of them has a straightforward fix. This guide walks you through the most frequently reported violations in the exact order you should tackle them, with code examples you can implement immediately.

Automated accessibility scanners like AccessGuard, axe-core, and Lighthouse can detect roughly 30-40% of all WCAG 2.1 issues. The issues they catch tend to be the most common and most impactful, which means fixing your scan results is the single highest-leverage accessibility improvement you can make.

Understanding Your Scan Report

Before you start fixing issues, take a moment to understand how scan reports are organized. Most tools categorize violations by severity: critical, serious, moderate, and minor. They also reference specific WCAG 2.1 success criteria, such as 1.1.1 (Non-text Content) or 4.1.2 (Name, Role, Value).

Start with critical and serious violations. These are the issues most likely to completely block users from accessing your content and the ones most likely to trigger legal complaints. Work through moderate and minor issues afterward.

Each violation in your report should include three things: the WCAG rule that was broken, the specific HTML element that failed, and guidance on how to fix it. If your scanner provides element selectors or XPath references, use those to locate the exact code you need to change.

Missing Alternative Text on Images

WCAG Criterion: 1.1.1 Non-text Content (Level A)

This is the single most common violation on the web. Every element needs an alt attribute. The fix depends on the purpose of the image.

Informative images need descriptive alt text:

Decorative images that add no information should use an empty alt attribute:

Linked images where the image is inside an anchor tag should describe the link destination:

A common mistake is writing alt text like "image of" or "photo of." Screen readers already announce that the element is an image, so the alt text should describe the content directly.

Empty Links and Buttons

WCAG Criterion: 4.1.2 Name, Role, Value (Level A)

Scanners flag this when a link or button has no accessible name. This happens frequently with icon buttons and linked images that lack text.

For links that only contain an image, the image alt text becomes the link's accessible name:

If a link wraps both text and an icon, the text already provides the accessible name. Mark the icon as decorative with aria-hidden="true" to prevent screen readers from announcing it redundantly.

Insufficient Color Contrast

WCAG Criterion: 1.4.3 Contrast (Minimum) (Level AA)

Low contrast between text and its background is one of the most frequently flagged issues. WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold).

The fix is simple but sometimes requires design coordination. Check each flagged element and increase the contrast by either darkening the text or lightening/darkening the background.

/ Before: gray text on white, ratio 2.5:1 /
.subtitle {
  color: #999999;
}

/ After: darker gray, ratio 4.6:1 /
.subtitle {
  color: #767676;
}

Use a contrast calculator to verify your changes. Tools like the WebAIM Contrast Checker let you enter foreground and background colors and see the exact ratio. For text overlaid on images or gradients, test the lowest-contrast combination that occurs.

Missing Form Labels

WCAG Criterion: 1.3.1 Info and Relationships (Level A)

Form inputs without associated labels are a critical barrier for screen reader users. Every input must have a programmatically associated label. The most reliable method is the element with a matching for attribute.

Email address

If your design requires visually hidden labels, use a CSS class that hides the label visually while keeping it available to screen readers:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

Never rely on placeholder alone. Placeholder text disappears when the user starts typing, leaving them with no reference for what the field expects.

Missing Document Language

WCAG Criterion: 3.1.1 Language of Page (Level A)

This is one of the simplest fixes you will encounter. Scanners flag this when the element is missing a lang attribute. Screen readers use this attribute to select the correct pronunciation engine.

If your page contains content in multiple languages, add lang attributes to the specific elements in a different language:

The French word for hello is bonjour.

Heading Hierarchy Issues

WCAG Criterion: 1.3.1 Info and Relationships (Level A)

Scanners check for skipped heading levels, such as jumping from

directly to

, and for missing

elements. Headings create the document outline that screen reader users rely on for navigation.

Rules to follow:

• Every page should have exactly one

  that describes the page content.

• Headings must be nested sequentially:

  , then

  , then

  . Do not skip levels.

• Do not use heading elements purely for visual styling. If you need large bold text that is not a section heading, use CSS on a

  or instead.

Our Products
Featured Items


Our Products
Featured Items

Missing ARIA Attributes on Custom Widgets

WCAG Criterion: 4.1.2 Name, Role, Value (Level A)

Custom interactive components like tabs, accordions, dropdowns, and modals need ARIA roles and properties to communicate their behavior to assistive technology.

For a tab interface:

  

    Description
  
  

    Reviews
  


  

The key principle is that custom components must expose the same information to assistive technology that native HTML elements provide automatically. If you can use a native element instead of a custom one, that is almost always the better choice.

Empty Table Headers

WCAG Criterion: 1.3.1 Info and Relationships (Level A)

Data tables must have elements that label each column and/or row. Scanners flag tables where cells are empty or where data tables use for every cell including the header row.

  
  

Name
Price
Widget A
$10.00



  
    
  
  
    
  


Name
Price


Widget A
$10.00

What To Do After Fixing Scanner Results

Once you have resolved the violations from your automated scan, do not stop there. Automated tools catch only a fraction of accessibility issues. The next steps are:

Keyboard testing. Tab through every page and verify that all interactive elements are reachable, operable, and have visible focus indicators.

Screen reader testing. Test with at least one screen reader (NVDA on Windows is free) to verify that the content makes sense when read linearly.

Rescan regularly. New code deployments can introduce regressions. Schedule recurring scans to catch issues before they reach users.

Automate Your Accessibility Monitoring

Fixing scan results is step one. Keeping your site compliant as it evolves requires ongoing monitoring. AccessGuard provides automated WCAG 2.1 scanning that you can run on demand or schedule weekly. Every scan generates a prioritized report with specific element references and code-level remediation guidance.

Run a free scan now to see your current violation count, or explore AccessGuard's Pro plan for scheduled monitoring, trend tracking, and team collaboration features that keep accessibility on track across every deployment.