The most common accessibility issues on websites are missing image alt text, insufficient color contrast, unlabeled form fields, missing or broken keyboard navigation, and absent heading structure. These categories appear consistently across audit reports and affect how people with disabilities interact with web content. Understanding each one helps teams prioritize remediation and move toward WCAG 2.1 AA or WCAG 2.2 AA conformance.
| Issue Category | Why It Matters |
|---|---|
| Missing alt text | Screen readers cannot convey the meaning of images without descriptive alt attributes |
| Low color contrast | Text becomes unreadable for users with low vision when foreground and background colors are too similar |
| Unlabeled form fields | Assistive technology cannot announce the purpose of an input without a programmatic label |
| Keyboard inaccessibility | Users who cannot operate a mouse are blocked from reaching interactive elements |
| Missing heading structure | Screen reader users rely on heading hierarchy to understand page organization |
| Inaccessible links | Generic link text provides no context when read outside the surrounding sentence |
Missing or Inadequate Image Alt Text
Images without alt text are one of the most frequently identified issues in accessibility audits. When an image carries meaning and lacks a text alternative, screen readers either skip it entirely or announce the file name, which is rarely useful.
Every meaningful image needs alt text that conveys its purpose. A product photo, an infographic, or a chart all require descriptions. Decorative images that add no informational value should use an empty alt attribute (alt=””) so assistive technology ignores them. Getting this distinction right eliminates a significant portion of conformance gaps on most websites.
Insufficient Color Contrast
WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Many websites fall short, particularly with light gray text on white backgrounds or colored text on colored backgrounds.
This affects people with low vision, color blindness, and anyone viewing content in bright sunlight. Contrast issues are one of the few categories that automated scans can reliably detect. But the presence of passing contrast scores in a scan does not mean the full page is conformant. Scans only flag approximately 25% of issues overall.
Unlabeled Form Fields and Controls
Forms are where users take action: logging in, signing up, making a purchase. When form inputs lack programmatic labels, screen readers announce them as “edit text” or “blank” with no indication of what information is expected.
Placeholder text is not a substitute for a label element. Placeholders disappear when a user begins typing, and many assistive technologies do not treat placeholder content as an accessible name. Every input, select menu, and textarea needs a visible label that is programmatically associated with the control.
How Does Keyboard Accessibility Break?
Some users rely entirely on a keyboard. No mouse. No trackpad. When interactive elements like buttons, links, dropdown menus, or modal dialogs cannot receive keyboard focus or respond to keyboard input, those users are locked out.
Common patterns that break keyboard accessibility include custom JavaScript components that override native focus behavior, focus traps inside modals that never release, and missing visible focus indicators. A sighted keyboard user who cannot see where focus is on the page faces the same dead end as a screen reader user who cannot reach a button at all.
Accessible.org evaluates keyboard navigation as a core part of every audit. It is one of the most consequential areas because a single broken keyboard interaction can block an entire workflow.
Poor Heading Structure
Screen reader users often move through a page by jumping between headings. If a page has no headings, or if headings skip levels (jumping from H1 to H4, for example), the page becomes disorganized and difficult to scan.
Headings also need to be meaningful. Using an H2 tag for visual styling on a sentence that is not actually a section heading creates a misleading experience. Headings should reflect the actual information hierarchy of the content.
Inaccessible Links and Buttons
Link text like “read more” tells a screen reader user nothing when they pull up a list of all links on a page. Descriptive anchor text that conveys the link’s destination or purpose is a WCAG conformance requirement.
Buttons and links also need correct semantic markup. A div styled to look like a button but coded without a button element or proper ARIA role will not behave as expected for keyboard and assistive technology users.
Missing or Incorrect ARIA Usage
ARIA (Accessible Rich Internet Applications) attributes are intended to fill gaps where native HTML falls short. But ARIA used incorrectly introduces new issues instead of resolving existing ones.
A common example: adding aria-label to an element that already has visible text, creating a conflict between what sighted users see and what screen readers announce. Another: applying role=”button” to a link without also adding keyboard event listeners for the Enter and Space keys. The first rule of ARIA is that if a native HTML element does the job, use that instead.
Video and Multimedia Without Captions
Pre-recorded video content requires synchronized captions under WCAG 2.1 AA. Many websites embed video without any captions or rely on auto-generated captions that contain errors.
Audio-only content also needs a text transcript. These are not optional enhancements. They are conformance requirements that directly affect users who are deaf or hard of hearing.
Why Do These Issues Keep Appearing?
Most of these issues stem from the same root cause: websites are built without accessibility factored into the design and development process. Content authors add images without alt text because the CMS does not prompt them. Developers use div elements as buttons because the visual result looks identical. Designers choose low-contrast color palettes because they look clean on screen.
A manual accessibility audit is the only way to determine WCAG conformance. Automated scans are useful for catching surface-level contrast and alt text issues, but they miss the majority of what an auditor identifies during a thorough evaluation. Training teams on WCAG conformance requirements before code is written prevents many of these issues from entering production in the first place.
What Comes After Identifying Issues?
An audit report documents every issue, maps it to the relevant WCAG criterion, and provides guidance for remediation. From there, teams prioritize and fix. Accessibility Tracker Platform helps teams track each issue through the remediation lifecycle with Risk Factor and User Impact prioritization formulas that surface the most critical items first.
Accessible.org audits are always fully manual, evaluating every page and component against the full WCAG standard. The result is a complete picture of where a website stands and what needs to change to reach conformance.
Can automated scans catch all of these issues?
No. Automated scans only flag approximately 25% of accessibility issues. They are helpful for detecting color contrast ratios and missing alt attributes, but they cannot evaluate whether alt text is accurate, whether keyboard navigation works correctly, or whether ARIA is applied properly. A manual audit conducted by a qualified auditor is the only way to determine WCAG conformance.
Which WCAG version should my website conform to?
Most organizations target WCAG 2.1 AA. It is the standard referenced in ADA compliance expectations and many procurement requirements. WCAG 2.2 AA is gaining traction, and some clients are already requesting it. The right version depends on your regulatory context and contractual obligations, but 2.1 AA remains the most widely adopted baseline.
How often should a website be evaluated for accessibility?
A good cadence is after any significant redesign, major content update, or platform migration. Ongoing monitoring through periodic accessibility audits keeps conformance from drifting as content and code change over time.
Accessibility issues on websites are predictable, well documented, and fixable. The path from identification to conformance is clear when the right evaluation and remediation process is in place.
Contact Accessible.org to schedule an accessibility audit for your website.
