Critical for accessibility: Setting severity to 'Error' makes this rule a hard requirement that will fail builds when violated.

Missing alt attributes create barriers for users with screen readers and violate WCAG guidelines. Here's how screen readers interpret images:

<!-- Image without alt -->
<img src="logo.png">
<!-- Screen reader announces: "image" or filename -->

<!-- Image with alt -->
<img src="logo.png" alt="Company Logo">
<!-- Screen reader announces: "Company Logo, image" -->

The selector uses CSS-like syntax to target all img elements in the document. This approach makes the rule definition intuitive for web developers already familiar with CSS selectors. You can create more specific selectors like 'article img' or 'img.hero' to target only certain images.

The condition 'alt-missing' checks specifically for the absence of the alt attribute, while the message provides clear guidance on what needs to be fixed. This combination helps developers understand both the issue and how to resolve it, improving the overall accessibility of their HTML content.

The 'Semantics' rule type evaluates proper HTML5 semantic element usage to enhance:

• Accessibility: Screen readers rely on semantic structure
• SEO: Search engines weigh semantic elements in ranking
• Code clarity: Self-documenting structure is easier to maintain

Consider these examples:

<!-- Non-semantic approach -->
<div class="header">
  <div class="logo">Site Name</div>
  <div class="nav">...</div>
</div>

<!-- Semantic approach -->
<header>
  <h1>Site Name</h1>
  <nav>...</nav>
</header>

Using 'Warning' severity creates a balance between enforcing best practices and maintaining flexibility. Unlike errors, warnings won't break builds or deployments but still highlight opportunities for improvement. This is ideal for semantic issues which may require contextual judgment rather than strict enforcement.

The options object provides powerful configuration capabilities beyond simple attribute checking. Here, it creates a complex validation rule that can evaluate specific content patterns within meta tags. This extensibility allows for highly customized rules tailored to project-specific requirements and SEO standards.

The HTML Linter supports JSON configuration to decouple rules from code. This enables:

1. Project-specific rule customization without code changes
2. Version-controlled linting standards
3. Shareable configurations across projects

A typical rules.json file might look like:

{
  "rules": [
    {
      "name": "img-alt",
      "rule_type": "AttributePresence",
      "severity": "Error",
      "selector": "img",
      "condition": "alt-missing"
    },
    {
      "name": "semantic-header",
      "rule_type": "Semantics",
      "severity": "Warning",
      "selector": "div.header"
    }
  ]
}

The actual linting operation is a single function call that processes the entire HTML document against all defined rules. Despite its simple interface, the linter performs complex parsing and analysis under the hood, leveraging Rust's performance advantages to handle even large documents efficiently. The operation returns a Result type, properly handling potential errors.

The linter returns structured results that include both the severity level and the detailed message. This makes it easy to filter issues by importance or to format them appropriately for different output contexts - such as CI/CD pipelines, development environments, or reporting tools. The example shows simple console output, but the structured data enables integration with any reporting system.