๐Ÿ” Scan Your Site for WCAG 2.1 AA Violations โ€” Free, No Login Required Try It โ†’

โ† Back to Accessalyze

By Genesis AI Services ยท April 24, 2026 ยท 10 min read ยท Accessibility Tutorial

How to Fix WCAG 2.1 AA Violations Fast with AI

Getting a WCAG 2.1 AA compliance report is the easy part. Knowing what to fix first, and how to fix it without a six-month remediation project, is where most teams get stuck. This guide shows you how to use AI-powered scanning to systematically work through violations from most critical to least โ€” with real code examples for the issues that appear most often.

What this covers: Using Accessalyze to identify violations โ†’ understanding WCAG rule categories โ†’ fixing the 7 most common issues with code examples โ†’ avoiding compliance drift with ongoing monitoring.

Step 1: Run Your First Scan with Accessalyze

1 Go to accessalyze.com

See how 321 websites scored →

View the 2026 Report

Enter your website URL in the scan field. No registration or installation required โ€” Accessalyze scans public URLs directly from the browser.

2 Review the violation summary

Your results are organized by WCAG principle: Perceivable, Operable, Understandable, Robust (POUR). Each violation includes the WCAG success criterion it violates, the severity level (critical / serious / moderate / minor), the specific DOM element that failed, and fix guidance.

3 Export or share your report

Share a public link to your scan results with your development team or use the report to build your corrective action plan.

Important context: Automated scanners like Accessalyze catch approximately 30โ€“50% of WCAG violations. They excel at rule-based checks โ€” missing alt text, color contrast ratios, form labels, ARIA attributes. Issues requiring human judgment โ€” like whether alt text is meaningful, or whether content reading order is logical โ€” require manual testing. Use automated scanning as your baseline, then layer in manual testing for a complete audit.

Step 2: Understand Severity Levels

Not all violations carry equal weight. The WCAG conformance model doesn't rank violations by severity, but from a practical remediation standpoint, prioritize in this order:

SeverityWhat It MeansExamplesFix Priority
CriticalMakes content completely inaccessible to a class of usersForm fields with no labels, images with no alt attributeFix immediately
SeriousSignificant barrier; workaround possible but unreasonableLow color contrast, keyboard trap, missing focus indicatorFix within 2 weeks
ModerateCreates difficulty but doesn't block task completionSkip link missing, ambiguous link textFix within 1 month
MinorBest-practice deviation; minimal user impactRedundant title attributes, non-unique ARIA landmark labelsFix in next sprint

Step 3: Fix the 7 Most Common Violations

These issues appear on the majority of government and business websites. Fixing them often resolves 60โ€“70% of a site's total violation count.

1. Missing Alt Text on Images (WCAG 1.1.1)

Every <img> element must have an alt attribute. Screen readers read alt text aloud; without it, they announce the filename or nothing at all.

โŒ Violation<img src="city-hall.jpg">
โœ… Fix<img src="city-hall.jpg" alt="City Hall building, downtown Portland">

For decorative images that convey no information, use an empty alt attribute: alt="". This tells screen readers to skip the image entirely.

For more detail: How to Add Alt Text to Images โ†’

2. Insufficient Color Contrast (WCAG 1.4.3)

Normal text (under 18pt or 14pt bold) requires a contrast ratio of at least 4.5:1 against its background. Large text requires 3:1.

โŒ Violationcolor: #999; background: #fff; (ratio: 2.85:1)
โœ… Fixcolor: #6b7280; background: #fff; (ratio: 4.6:1)

Use Accessalyze's contrast checker or the WCAG color contrast guide to verify ratios before deploying.

3. Form Inputs Without Labels (WCAG 1.3.1, 4.1.2)

Every form control โ€” text input, checkbox, radio button, select โ€” needs a programmatically associated label. Placeholder text doesn't count.

/* โŒ Violation */
<input type="text" placeholder="Enter your email">

/* โœ… Fix โ€” explicit label */
<label for="email">Email address</label>
<input type="text" id="email" placeholder="name@agency.gov">

/* โœ… Fix โ€” aria-label when visible label isn't possible */
<input type="search" aria-label="Search site content" placeholder="Search...">

For comprehensive guidance: How to Make Forms Accessible โ†’

4. Keyboard Navigation Failures (WCAG 2.1.1, 2.1.2)

All interactive functionality must be operable with a keyboard alone. Test by tabbing through your page โ€” every link, button, and form control should receive visible focus, and no keyboard traps should exist.

/* โŒ Violation โ€” click event only */
<div onclick="openMenu()">Menu</div>

/* โœ… Fix โ€” semantic button with keyboard support */
<button type="button" onclick="openMenu()">Menu</button>

Custom interactive components (dropdowns, modals, date pickers) require ARIA roles and keyboard event handlers: full guide โ†’

5. Missing Focus Indicator (WCAG 2.4.7)

Interactive elements must display a visible focus indicator when focused via keyboard. Many sites suppress the browser default with outline: none and don't provide a replacement.

/* โŒ Common mistake โ€” removes focus indicator entirely */
:focus { outline: none; }

/* โœ… Fix โ€” custom focus indicator that meets contrast requirements */
:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
  border-radius: 2px;
}

Learn more: WCAG 2.4.7 Focus Visible Requirements โ†’

6. Missing Page Language (WCAG 3.1.1)

The HTML lang attribute tells screen readers which language to use for pronunciation. Missing or incorrect lang causes screen readers to mispronounce content.

/* โŒ Violation */
<html>

/* โœ… Fix */
<html lang="en">

For multilingual pages, add lang attributes to individual sections with different language content.

7. Inaccessible Error Messages (WCAG 3.3.1, 3.3.2)

Form error messages must be programmatically associated with the field they describe so screen readers can announce them when the field receives focus.

/* โŒ Violation โ€” error message not linked to input */
<input type="email" id="email">
<span class="error">Please enter a valid email address.</span>

/* โœ… Fix โ€” error linked via aria-describedby */
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">Please enter a valid email address.</span>

Detailed guide: Accessible Error Messages for Forms โ†’

Step 4: Addressing Issues Automated Tools Can't Catch

After addressing the issues above, manual testing is essential. These violation types require human judgment:

Practical tip: Assign a team member to do a keyboard-only walkthrough of every primary user journey on your site. Tab through the entire flow without touching the mouse. Note every place where focus is lost, trapped, or unclear. This 30-minute exercise typically surfaces 10โ€“15 additional issues that automated scanning misses.

Step 5: Prevent Compliance Drift with Ongoing Monitoring

WCAG compliance isn't a one-time achievement โ€” it's an ongoing practice. Every new page, template change, or third-party widget integration is a potential new violation. Teams that treat accessibility as a project rather than a process typically find themselves out of compliance within 6โ€“12 months of their initial remediation.

Set up Accessalyze to scan your site on a recurring basis. When new violations appear, you catch them when they're easy to fix โ€” one page, one element โ€” rather than discovering them through a DOJ complaint or lawsuit.

Find Your WCAG Violations Now

Scan your website with Accessalyze and get a prioritized remediation report in under 60 seconds. Free, no registration, no browser extension required.

Start Free Scan โ†’

Related Resources

See real website accessibility scores: Browse 244+ free accessibility audits โ†’

Try it yourself

Enter your website URL to get a free accessibility score.

Check your website accessibility score free Scan Now →