Checker de Accesibilidad HTML (Básico)

Automated Accessibility Auditing for HTML

Web accessibility ensures that websites and applications are usable by everyone, including people who rely on assistive technologies such as screen readers, keyboard navigation, or switch devices. The Web Content Accessibility Guidelines (WCAG) define a comprehensive set of success criteria for accessible content, but many of the most impactful violations are also the most common — missing alternative text on images, unlabeled form controls, broken heading hierarchies, and absent language declarations. These issues affect millions of users and often go undetected during standard development workflows because sighted developers may not notice them during visual testing.

This tool performs a basic automated accessibility audit on HTML snippets, catching the most frequent WCAG violations that can be detected through static analysis. It examines your markup for missing alt attributes on images, form inputs without associated labels, heading levels that skip numbers in the hierarchy, missing lang attributes on the root element, absent ARIA attributes where required, and indicators of potential color contrast issues. While automated testing cannot replace manual evaluation with real assistive technologies — it cannot assess whether alt text is meaningful, whether focus order is logical, or whether custom widgets are truly operable — it provides a valuable first-pass check that catches the low-hanging fruit responsible for the majority of accessibility barriers encountered in the wild.

Common WCAG Violations Detected by Automated Checks

Research consistently shows that a small number of issue types account for the vast majority of accessibility failures. The WebAIM Million study, which audits the top one million home pages annually, finds that missing alternative text, empty links, missing form labels, and missing document language are among the top six most common detectable errors year after year. These are precisely the issues that static analysis can catch reliably.

Missing alt attributes on <img> elements violate WCAG Success Criterion 1.1.1 (Non-text Content). When an image lacks alt text, screen readers announce the file name or URL instead, which provides no useful information. For decorative images, an empty alt="" attribute tells assistive technology to skip the element entirely — this is intentional and correct, but omitting the attribute altogether is always a failure.

Form controls without programmatically associated labels violate Success Criterion 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value). A <label> element with a matching for attribute, a wrapping <label>, or an aria-label / aria-labelledby attribute are all valid labeling techniques. Without any of these, users of assistive technology cannot determine the purpose of the input field.

Heading hierarchy violations occur when heading levels are skipped — for example, jumping from <h1> directly to <h3> without an intervening <h2>. This violates Success Criterion 1.3.1 because screen reader users often navigate by headings to understand page structure, and skipped levels suggest missing content sections.

ARIA Attributes and Landmark Requirements

WAI-ARIA (Accessible Rich Internet Applications) provides a vocabulary of attributes that communicate roles, states, and properties of interactive elements to assistive technologies. While the first rule of ARIA is "don't use ARIA if a native HTML element already provides the semantics you need," there are many cases where ARIA is required — custom widgets, dynamic content regions, and complex interactive patterns that have no native HTML equivalent.

This checker verifies several ARIA-related requirements. Elements with explicit role attributes must include the required properties for that role — for example, a role="checkbox" requires aria-checked, and a role="slider" requires aria-valuenow, aria-valuemin, and aria-valuemax. Using a role without its required attributes creates a widget that assistive technology cannot interpret correctly, violating Success Criterion 4.1.2.

ARIA landmark roles (banner, navigation, main, contentinfo) help screen reader users understand page structure and navigate efficiently. While HTML5 sectioning elements (<header>, <nav>, <main>, <footer>) provide implicit landmark roles, pages that lack these structural elements force users to navigate linearly through all content. The checker flags pages that have no discernible landmark structure.

The lang attribute on the <html> element is required by Success Criterion 3.1.1 (Language of Page). Without it, screen readers cannot determine which language pronunciation rules to apply, potentially rendering the content unintelligible to users who rely on text-to-speech. For multilingual pages, the lang attribute on individual elements (Success Criterion 3.1.2) indicates language changes within the content.

Color Contrast and Visual Accessibility Indicators

WCAG Success Criterion 1.4.3 (Contrast — Minimum) requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Success Criterion 1.4.6 (Enhanced) raises these to 7:1 and 4.5:1 respectively. While precise contrast calculation requires evaluating computed styles against backgrounds — something that static analysis of HTML alone cannot fully achieve — this checker identifies common patterns that indicate potential contrast issues.

Inline style declarations with color values are analyzed against any co-occurring background colors on the same or parent elements. Text elements using CSS classes commonly associated with light or low-contrast palettes are flagged for manual review. The tool also detects the anti-pattern of relying solely on color to convey information (Success Criterion 1.4.1 — Use of Color), such as error states indicated only by red text without an accompanying icon, label, or text description.

Additionally, the checker identifies images and interactive elements that may lack sufficient non-text contrast (Success Criterion 1.4.11 — Non-text Contrast). UI components and graphical objects require at least a 3:1 contrast ratio against adjacent colors. Focus indicators, custom checkboxes, icon buttons, and chart elements are commonly affected. The tool flags elements where focus styles are explicitly suppressed via outline: none or outline: 0 without providing an alternative visual focus indicator.

Limitations of Automated Testing

Automated accessibility testing tools, including this one, can detect roughly 30-50% of WCAG failures. The remaining issues require human judgment — evaluating whether alt text is meaningful rather than merely present, whether tab order follows a logical reading sequence, whether custom interactions are operable with assistive technology, and whether content makes sense when CSS is disabled or linearized.

This tool is designed as a first-pass filter: it catches the obvious, mechanically detectable issues that account for a disproportionate share of real-world barriers. It should be complemented by manual testing with actual screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation testing, and ideally usability testing with people who have disabilities. The goal is not to achieve a passing score from any single tool, but to remove barriers that prevent people from accessing your content.

Code Examples

HTML with common accessibility issues (before fixing)

<!-- Missing lang attribute on html element -->
<html>
<head><title>My Page</title></head>
<body>
  <!-- Heading hierarchy skips h2 -->
  <h1>Welcome</h1>
  <h3>About Us</h3>

  <!-- Image without alt attribute -->
  <img src="hero-banner.jpg" width="800" height="400">

  <!-- Form input without associated label -->
  <input type="email" id="email" placeholder="Enter email">

  <!-- Button with no accessible name -->
  <button><img src="search-icon.svg"></button>

  <!-- Custom widget missing required ARIA attributes -->
  <div role="checkbox">Accept terms</div>

  <!-- Link with no discernible text -->
  <a href="/profile"><img src="avatar.png"></a>

  <!-- Focus indicator suppressed -->
  <a href="/home" style="outline: none;">Home</a>
</body>
</html>

Output:

Accessibility Issues Found: 8

[ERROR] Missing lang attribute on <html> element
  → WCAG 3.1.1: Language of Page
  → Fix: Add lang="en" (or appropriate language code)

[ERROR] Missing alt attribute on <img>
  → WCAG 1.1.1: Non-text Content
  → Element: <img src="hero-banner.jpg">

[ERROR] Form input missing associated label
  → WCAG 1.3.1, 4.1.2: Info and Relationships
  → Element: <input type="email" id="email">

[ERROR] Heading hierarchy skipped (h1 → h3)
  → WCAG 1.3.1: Info and Relationships
  → Expected: h2 before h3

[ERROR] role="checkbox" missing required aria-checked
  → WCAG 4.1.2: Name, Role, Value

[ERROR] Image button missing accessible name
  → WCAG 4.1.2: Name, Role, Value
  → Fix: Add alt text to img or aria-label to button

[WARNING] Link contains only an image without alt text
  → WCAG 2.4.4: Link Purpose

[WARNING] Focus indicator suppressed (outline: none)
  → WCAG 2.4.7: Focus Visible
  → Ensure alternative focus style exists

Corrected HTML with accessibility issues resolved

<!-- Correct: lang attribute present -->
<html lang="en">
<head><title>My Page</title></head>
<body>
  <!-- Correct: proper heading hierarchy -->
  <h1>Welcome</h1>
  <h2>About Us</h2>

  <!-- Correct: descriptive alt text -->
  <img src="hero-banner.jpg" width="800" height="400"
       alt="Team collaborating in a modern office space">

  <!-- Correct: label associated via for attribute -->
  <label for="email">Email address</label>
  <input type="email" id="email" placeholder="Enter email">

  <!-- Correct: aria-label provides accessible name -->
  <button aria-label="Search">
    <img src="search-icon.svg" alt="">
  </button>

  <!-- Correct: required ARIA attributes present -->
  <div role="checkbox" aria-checked="false" tabindex="0">
    Accept terms
  </div>

  <!-- Correct: image inside link has alt text -->
  <a href="/profile">
    <img src="avatar.png" alt="User profile">
  </a>

  <!-- Correct: custom focus style instead of removing outline -->
  <a href="/home" class="nav-link">Home</a>
  <!-- CSS: .nav-link:focus { outline: 2px solid #005fcc; } -->
</body>
</html>

Standards & Specifications

• WCAG 2.2 — The current W3C Web Content Accessibility Guidelines defining success criteria for accessible web content at Levels A, AA, and AAA
• WAI-ARIA 1.2 — W3C specification defining roles, states, and properties for accessible rich internet applications and custom widgets
• ARIA in HTML — W3C specification defining which ARIA roles and attributes are allowed on each HTML element and their implicit mappings
• HTML Accessibility API Mappings 1.0 — Defines how HTML elements and attributes map to platform accessibility APIs used by assistive technologies