Common Web Accessibility Issues and How to Fix Them

Common web accessibility issues include low text contrast, meaning conveyed only by color, missing or unhelpful image alternatives, unclear form labels, weak heading structure, controls that require a mouse, invisible keyboard focus, and media without appropriate alternatives or controls. Fix them by making meaning available in more than one way, providing clear structure and labels, and ensuring every function works with a keyboard.

Use WCAG 2.2 as the standards reference. A quick review can expose some barriers, but it does not prove a site is accessible or conforms to WCAG. W3C describes its Easy Checks as a first review and points to further evaluation resources.

1. Insufficient text contrast

Text can be hard to read when its color is too close to the background, when it sits over a busy image, or when controls have faint labels. This can make instructions, status messages, and navigation difficult to perceive.

How to fix it

• Measure the foreground and background colors for each text style and state, including hover, focus, disabled, and error states.
• For ordinary text, WCAG 2.2 Success Criterion 1.4.3 specifies a minimum contrast ratio of 4.5:1. For large text, the minimum is 3:1. The criterion has exceptions, including logos and certain incidental content; do not treat either ratio as a universal rule for every visual element.
• Adjust the text or background color when the ratio falls short. For text over photography, place a sufficiently solid backing behind the text or choose a less variable image area.
• Check controls and meaningful graphical objects against the relevant WCAG criteria as well; text contrast alone does not cover every visual contrast requirement.

W3C’s design tips recommend considering contrast as part of accessible design.

2. Meaning conveyed by color alone

A red outline alone may be the only indication that a field has an error. A green dot alone may indicate success. People who cannot distinguish those colors may miss the state entirely, and the meaning can also be unclear when color is unavailable or hard to see.

How to fix it

• Add a text label such as “Error: enter a valid email address” or “Saved.”
• Use an icon or pattern as an additional cue, with an accessible name where the icon communicates information.
• For charts and status indicators, combine color with labels, shapes, patterns, or direct annotations.
• Keep the cue close to the item it describes. Do not make users infer meaning from a distant legend alone.

3. Missing or unhelpful image alternatives

Without an appropriate text alternative, people using assistive technology may miss information conveyed by an image. On the other hand, describing every decorative detail can add noise instead of useful information.

How to fix it

• For an informative image, provide alternative text that communicates its purpose or relevant information in the current context.
• For a decorative image that adds no information, avoid sending an irrelevant description into the reading flow.
• For an image that acts as a control, give the control an accessible name that describes its purpose, such as the action it performs.
• Review image alternatives in context. The same image may need different treatment depending on whether it is informative, decorative, or interactive.

W3C’s tips discuss alternatives for images, and WCAG 2.2 includes a non-text content criterion. See the W3C design guidance and WCAG 2.2.

4. Unlabeled or unclear form fields

A placeholder is not a dependable substitute for a clear field label. If users cannot tell what information a field expects, they may enter the wrong value or be unable to complete the form. An error shown only through color can also be missed.

How to fix it

• Give each field a clear label that describes the information to enter.
• Explain required information and expected formats before or alongside the field, for example, a date format or password requirement.
• When input is invalid, identify the field and explain the error in text. Where practical, give a concrete correction.
• Do not rely on color alone to identify required fields or errors.
• Check that the labels and error messages make sense when read without the surrounding visual layout.

5. Weak headings and navigation

Headings that communicate only through size or styling, labels that do not describe a topic or purpose, and inconsistent navigation make pages harder to scan. Screen-reader users may use headings to move through a page, so heading text should be meaningful outside its visual appearance.

How to fix it

• Use headings to express the page’s hierarchy and the subject of each section.
• Choose navigation and control labels that describe their topic or purpose.
• Keep navigation clear and consistent across pages.
• Review the sequence of headings as a list: it should still give a useful outline of the page.

6. Mouse-only controls and invisible keyboard focus

Menus, buttons, links, and form controls can exclude people who navigate by keyboard if an action requires a mouse. Even if keyboard navigation works, users can lose their place when the currently focused item is hard to see.

How to fix it

• Make every function available from a keyboard.
• Provide a visible focus indicator and verify that it remains apparent against the background and surrounding content.
• Use a keyboard to move through links, buttons, menus, and forms; confirm that focus follows an understandable order and that actions can be completed.
• Check interactive states such as opening a menu, submitting a form, and dismissing a dialog—not only the initial page view.

WCAG 2.2 addresses keyboard accessibility and visible focus. See the relevant criteria in the W3C standard, and include keyboard use in a first review.

7. Media without appropriate alternatives or controls

People may miss spoken information in video or audio without suitable alternatives. Automatically moving or starting content can also make a page harder to use.

How to fix it

• Provide captions where needed to convey speech and relevant non-speech audio.
• Provide appropriate alternatives for media so important information is available through another form.
• Give users controls for content that starts automatically.
• Review whether the alternatives convey the information people need from the media, rather than treating their presence alone as sufficient.

W3C’s design tips cover media alternatives and controls for automatically starting content.

8. How to make a website accessible: a first review

Use this pass to find obvious barriers and make a list of fixes. It is not a complete accessibility evaluation or proof of WCAG conformance.

1. Inspect image alternatives. Check whether informative images communicate their purpose, decorative images avoid irrelevant descriptions, and image controls have useful names.
2. Review headings and labels. Scan the page’s headings as an outline. Check that navigation, controls, and form fields have clear names and purposes.
3. Check contrast. Measure text against its background, including text over images and relevant interface states. Compare text with the WCAG 2.2 thresholds and account for the standard’s exceptions.
4. Use the keyboard. Navigate through links, buttons, menus, and forms. Confirm every function is available and the current focus is visible.
5. Review media. Check for suitable captions or other alternatives and for controls when content starts automatically.
6. Fix, then review again. Revisit the affected content and interactions after changes. Include the pages and states where the barrier can occur.

W3C’s Easy Checks – A First Review of Web Accessibility provides a structured starting point and links to further evaluation. For a large site, complex interactive flows, or a high-stakes experience, a first pass may not be enough: choose a deeper evaluation that can assess the relevant pages, states, keyboard operation, and meaning of the content. The reviewed sources distinguish preliminary checks from further evaluation; they do not prescribe one specific evaluation provider.

9. Troubleshooting common review findings

Finding	Likely cause	What to do
Text is difficult to read	Foreground and background colors are too similar, or a background image makes contrast inconsistent.	Measure the actual text and background combination. Adjust the palette or add a solid backing; check relevant states too.
An error is easy to miss	The message is indicated only by red, a border, or another visual change.	Add a nearby text explanation and make the affected field identifiable without relying on color.
An image has a long but unhelpful description	The alternative describes visual detail without conveying the image’s purpose in context.	Rewrite it to convey relevant information, or avoid adding an irrelevant description when the image is decorative.
A form field’s purpose is unclear	It relies on placeholder text, an ambiguous label, or unexplained format requirements.	Provide a clear label and explain required information and expected format.
Keyboard users lose their place	Focus is not visible, a control cannot be reached, or an interaction cannot be completed from the keyboard.	Test the full interaction by keyboard, make each function available, and provide a visible focus indicator.
A quick scan found no problems	A first review was treated as a complete evaluation.	Use Easy Checks as a starting point. Arrange deeper evaluation when the site’s scope, complexity, or stakes call for it.

10. ScreenshotNeo for reviewing visual page states

Visual screenshots can help a team review how pages render across URLs, viewports, and states. They can support a visual review of contrast, layout, or a changed page, but a screenshot by itself cannot establish that alternative text, keyboard operation, accessible names, or other nonvisual behavior is correct. Keep those checks in the review too.

ScreenshotNeo is a website screenshot API and MCP server for developers. Its captures remove known consent banners, newsletter popups, and chat widgets before the shot, and those steps can be turned off individually. The API supports full-page or CSS-selector captures, device presets or custom viewports, dark mode, retina scale, custom CSS and JavaScript, selector waits, delay or network-idle waits, and other capture settings. See the ScreenshotNeo API documentation.

Or skip the browser setup

Make a one-call capture to inspect a rendered page. Replace the URL with a page you are reviewing and use your API key. The response is an image; it complements accessibility checks and does not test keyboard or screen-reader behavior.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners, popups, and chat widgets are removed before the shot.
• Bot checks, blank pages, and failed loads are never billed; response headers identify the page verdict and billing status.
• An MCP server lets AI agents use screenshot tools, including take_screenshot, get_page_info, and capture_pdf.
• 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

11. Frequently asked questions

What are common website accessibility issues?

Frequent barriers include poor text contrast, color-only meaning, missing or unsuitable image alternatives, unclear form labels, weak headings, keyboard barriers, invisible focus, and media without appropriate alternatives or controls.

How do I check color contrast?

Measure the text and background colors actually used, including relevant states. WCAG 2.2 sets a 4.5:1 minimum for ordinary text and 3:1 for large text under Success Criterion 1.4.3, subject to exceptions.

Do images need alt text?

Images need treatment appropriate to their purpose. Provide a meaningful alternative for informative images, avoid irrelevant descriptions for decorative images, and give image controls an accessible name that communicates their purpose.

Can a website be used without a mouse?

WCAG 2.2 says functionality should be available through a keyboard. Test links, controls, menus, and forms with a keyboard and ensure focus is visible.

Does passing Easy Checks mean a site conforms to WCAG?

No. Easy Checks are a first review that identifies some common issues. Follow up with further evaluation appropriate to the site and experience.

References

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI, Designing for Web Accessibility – Tips for Getting Started
• W3C WAI, Easy Checks – A First Review of Web Accessibility
• ADA.gov, Guidance on Web Accessibility and the ADA