#1: Images Missing Alternative Text Critical

Images without alt attributes are the single most common accessibility issue. When a screen reader encounters an image without alt text, it may read the file name ("IMG_2847.jpg") or announce nothing at all, leaving blind users unable to understand the image content.

Why It Matters

Images often contain essential information: product photos, diagrams, infographics, or instructional images. Without alt text, this information is completely inaccessible to blind users. It's also one of the most frequently cited issues in ADA lawsuits.

How to Fix It

Add descriptive alt text to every meaningful image:

<img src="product.jpg" alt="Blue running shoe with white sole">

For decorative images that don't convey information, use empty alt text:

<img src="decorative-border.png" alt="">

Read our complete alt text guide for detailed examples.

#2: Insufficient Color Contrast Serious

Light gray text on white backgrounds, or similar low-contrast combinations, are difficult or impossible to read for users with low vision, color blindness, or anyone viewing a screen in bright light.

Why It Matters

About 1 in 12 men have some form of color blindness. Millions more have low vision. Low contrast text affects readability for everyone but creates a complete barrier for many users. It's also easy for automated tools to detect, making it a common target in accessibility complaints.

How to Fix It

Ensure text meets minimum contrast ratios:

• Normal text: 4.5:1 contrast ratio minimum
• Large text (18pt+): 3:1 contrast ratio minimum
• UI components: 3:1 contrast ratio minimum

Use a contrast checker tool to verify your colors. Read our color contrast guide for details.

#3: Form Inputs Without Labels Critical

Form fields without properly associated labels leave users guessing what information to enter. Screen readers announce "edit text" or "text field" with no indication of what the field is for.

Why It Matters

Forms are critical interaction points: login, checkout, contact forms, search. If users can't understand what to enter, they can't complete these tasks. This affects not just screen reader users but anyone who clicks on labels to focus fields.

How to Fix It

Every form input needs a label with a matching "for" attribute:

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

Placeholder text is NOT a substitute for labels; it disappears when users start typing and isn't announced consistently by screen readers.

#4: Links Without Descriptive Text Serious

Links that say "click here," "read more," or have no text at all don't tell users where the link goes. Screen reader users often navigate by pulling up a list of links. Imagine hearing "read more, read more, read more, click here, click here" with no context.

Why It Matters

Links are how users navigate the web. Unclear link text makes navigation frustrating and time-consuming. Icon-only links (like social media icons) are especially problematic if they have no text alternative.

How to Fix It

Write link text that describes the destination:

<!-- Bad -->
<a href="/pricing">Click here</a>

<!-- Good -->
<a href="/pricing">View pricing plans</a>

For icon-only links, add visually hidden text or an aria-label:

<a href="https://twitter.com/example" aria-label="Follow us on Twitter">
  <svg>...</svg>
</a>

#5: Missing or Generic Page Titles Serious

Pages without <title> elements, or pages with generic titles like "Home" or "Untitled," make it difficult for users to identify pages. Screen readers announce the page title when a page loads, and titles appear in browser tabs and bookmarks.

Why It Matters

Users with multiple tabs open rely on titles to find the right tab. Screen reader users hear the title first when arriving at a page. Search engines use titles for results. Missing or duplicate titles cause confusion everywhere.

How to Fix It

Give every page a unique, descriptive title that identifies the page content and site:

<title>Pricing Plans | Acme Software</title>
<title>Contact Us | Acme Software</title>
<title>Shopping Cart (3 items) | Acme Store</title>

#6: Interactive Elements Not Keyboard Accessible Critical

Buttons, links, and other interactive elements that only work with a mouse leave keyboard users unable to use your site. This often happens with custom JavaScript widgets, dropdown menus, and modal dialogs.

Why It Matters

Many users navigate entirely by keyboard, including people with motor impairments, power users, and screen reader users. If they can't tab to and activate controls, the site is unusable. Keyboard traps (where users can enter a component but not exit) are especially severe.

How to Fix It

• Use native HTML elements (<button>, <a>, <input>) which are keyboard accessible by default
• If using custom elements, add tabindex="0" to make them focusable
• Handle both click and keydown events for custom controls
• Ensure modal dialogs can be closed with the Escape key
• Test by navigating your entire site using only Tab, Shift+Tab, Enter, and Escape

#7: Missing Document Language Moderate

HTML documents without a lang attribute on the <html> element don't specify what language the content is in. Screen readers use this attribute to select the correct pronunciation rules.

Why It Matters

When a screen reader doesn't know the language, it may pronounce words incorrectly, making content difficult or impossible to understand. A French screen reader trying to read English text (or vice versa) produces gibberish.

How to Fix It

Add the lang attribute to your <html> element:

<html lang="en">  <!-- English -->
<html lang="es">  <!-- Spanish -->
<html lang="fr">  <!-- French -->

For content in a different language within the page, use the lang attribute on that element:

<p>The French word for hello is <span lang="fr">bonjour</span>.</p>

#8: Skipped or Improper Heading Levels Moderate

Headings that skip levels (H1 to H3, skipping H2), use heading elements purely for visual styling, or lack a logical hierarchy make pages difficult to navigate and understand.

Why It Matters

Screen reader users navigate by headings; they can jump from heading to heading to quickly scan page content. Improper heading structure is like a book with chapter numbers out of order or missing. It creates confusion about content relationships.

How to Fix It

• Use one H1 per page for the main page title
• Use headings in order (H1, then H2, then H3) without skipping levels
• Use headings for structure, not styling. Use CSS for visual appearance
• Ensure every section has a heading that describes its content

<h1>Product Name</h1>
  <h2>Features</h2>
    <h3>Performance</h3>
    <h3>Design</h3>
  <h2>Pricing</h2>
  <h2>Reviews</h2>

#9: Missing or Hidden Focus Indicators Serious

When CSS removes or hides the default focus outline (the ring that appears around focused elements), keyboard users can't see where they are on the page. This often happens with outline: none or outline: 0.

Why It Matters

Keyboard users need to know which element is currently focused so they know what will happen when they press Enter or Space. Without a visible focus indicator, navigating a page is like using a mouse with an invisible cursor.

How to Fix It

Never remove focus styles without providing an alternative:

/* Bad - removes focus indicator */
:focus { outline: none; }

/* Good - custom focus style */
:focus {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

/* Better - only hide on mouse click, show on keyboard */
:focus:not(:focus-visible) { outline: none; }
:focus-visible { outline: 2px solid #2563eb; }

#10: Incorrect ARIA Attributes Serious

ARIA (Accessible Rich Internet Applications) attributes can enhance accessibility when used correctly, but incorrect usage can make accessibility worse. Common mistakes include invalid ARIA roles, missing required attributes, and ARIA that conflicts with native HTML.

Why It Matters

Screen readers rely on ARIA to understand custom widgets and dynamic content. Incorrect ARIA provides wrong information, like a button announced as a checkbox, or an expandable menu that doesn't announce its state. This is more confusing than no ARIA at all.

How to Fix It

• First rule of ARIA: Don't use ARIA if native HTML will work. A <button> is better than <div role="button">
• Use valid values: Only use roles and properties defined in the ARIA specification
• Include required attributes: Some roles require specific properties (e.g., role="checkbox" needs aria-checked)
• Keep ARIA current: Update aria-expanded, aria-selected, etc. when state changes
• Test with a screen reader: Verify ARIA behaves as expected

<!-- Bad: Using ARIA when native HTML works -->
<div role="button" tabindex="0">Submit</div>

<!-- Good: Native button -->
<button type="submit">Submit</button>

<!-- Good ARIA usage: Custom toggle -->
<button aria-expanded="false" aria-controls="menu">Menu</button>
<div id="menu" hidden>...</div>