Common UI Bugs: Examples and How to Find Them

Common UI bugs include controls that cannot be reached with a keyboard, forms that fail without explaining why, status conveyed only by color, labels that do not identify their inputs, low-contrast text, and layouts that become difficult to use at narrow viewports. Find them by carrying out real tasks with a keyboard, submitting invalid form data, checking labels and visual cues, and repeating the task at smaller and enlarged viewports. These checks reveal useful evidence; they do not prove that a page is bug-free or conforms to an accessibility standard.

Many examples below are accessibility-related interface failures. They are a practical subset of UI bugs, not a complete inventory of visual, functional, compatibility, or performance defects. The checks are grounded in WCAG 2.2, W3C design guidance, and the U.S. Department of Justice’s examples of website accessibility barriers. The DOJ page describes barriers; it should not be read as a universal legal conclusion for every site or jurisdiction.

What are common UI bugs?

A UI bug is a defect in how an interface communicates or responds during use. A user may not be able to operate a control, understand what a form needs, identify a status, or reach content after the layout changes. A bug can be technically reproducible even when it affects only one input method, viewport, or state.

Bug pattern	What a person may notice	First check
Mouse-only control	A menu or action cannot be reached or activated by keyboard.	Complete the task using Tab, Shift+Tab, and the control’s standard activation key.
Focus or navigation failure	Focus skips an action, moves unpredictably, or gets trapped.	Follow the focus order and verify there is a keyboard route out of each component.
Missing or vague form error	A form fails, but the affected field or problem is not explained.	Submit empty and invalid values; look for a text explanation tied to the field.
Color-only status	An error, required state, or success is indicated only by a color change.	Check whether text, an icon with an accessible name, or another cue conveys the same meaning.
Low contrast	Text or controls blend into their background.	Review important text and controls against their backgrounds.
Missing or unclear label	The purpose of a field is not apparent or its label is not associated with it.	Inspect the visible label and the input’s accessible name.
Weak feedback or inconsistent navigation	Actions give no clear result, or repeated navigation controls change names or positions.	Compare related pages and observe what happens after each action.
Narrow viewport or enlarged-text failure	Content, navigation, or controls become obscured, clipped, or difficult to reach.	Repeat the task at a narrow viewport and with larger text.

These are guidance-based examples, not a ranking by prevalence. The cited material documents requirements and practical concerns, not how often each bug occurs.

How do I find UI bugs? A practical inspection workflow

1. Choose a real task. Pick a user goal such as finding an item, changing a setting, opening a menu, or submitting a form. Start from a known page state and record the expected result.
2. Repeat the task with a keyboard. Use Tab and Shift+Tab to move through links, buttons, and fields. Activate controls using their expected keyboard interaction. Note skipped controls, confusing focus, unexpected page changes, and components that cannot be exited. WebAIM describes Tab as the typical way to move among page links, buttons, and input fields; also consider a mobile device with an external keyboard if the product supports that use.
3. Exercise form states. Submit the form empty, then try malformed or out-of-range values appropriate to the field. Confirm the user can identify the field in error and understand what failed from text. Do not count a red border alone as a complete explanation. Browser-native validation may be generic, and W3C notes that behavior can vary across user-agent and screen-reader combinations.
4. Check meaning and visibility. Verify that every input has a clear label, important text is legible against its background, status is not conveyed by color alone, interactive elements are identifiable, and actions provide understandable feedback.
5. Vary viewport and text size. Repeat the same task at a narrow or mobile-sized viewport and with enlarged text. Look for horizontal clipping, hidden controls, overlapping content, or a focus order that no longer matches the visible layout.
6. Record a reproducible report. Include the task, starting state, input method, viewport, exact steps, expected behavior, actual behavior, and the affected control. Add a screenshot when it clarifies a visual state, but keep the steps sufficient to reproduce the problem without it.

This is a manual starting point. It does not establish WCAG conformance, find every defect, or replace evaluation with assistive technology users.

Check keyboard operation and focus

Try each meaningful control without a mouse: menus, dialogs, tabs, custom dropdowns, expandable sections, media controls, and form actions. Check both operation and escape. A component that can be entered but traps focus still blocks task completion.

• Use Tab and Shift+Tab to traverse interactive controls. Confirm focus is visible and lands in a sensible order.
• Use Enter or Space where appropriate to activate buttons and links. Use arrow keys in components whose interaction pattern calls for them.
• Open menus and dialogs, then verify the expected controls are reachable and there is a keyboard route to close or leave the component.
• Check that focus does not disappear behind a fixed header, modal, or other overlay.
• Repeat critical checks with an external keyboard on a supported mobile setup.

WCAG 2.2 includes a keyboard-operability requirement, with an exception for functions whose underlying operation depends on the path of movement rather than just its endpoints. The WCAG 2.2 Recommendation is the normative reference for the criteria discussed here. A quick keyboard pass is useful but is not a complete conformance evaluation.

Check form labels, errors, and feedback

For each field, ask whether a person can determine what information belongs there, whether required status and constraints are clear before submission, and whether a failed submission identifies the field and describes the error in text. W3C’s explanation of Error Identification says an automatically detected input error must identify the item and describe the error in text. Re-displaying an unsuccessful form without indicating that submission failed is not enough.

• Inspect visible labels and verify that they are associated with their controls; placeholder text alone can disappear as the person types.
• Submit missing and invalid values. Verify the message names the affected field and describes the problem, rather than saying only “invalid input.”
• Check whether focus or an error summary helps users find the problem after submission.
• Confirm success and failure states are both communicated. A color change can supplement an explanation, but should not be the only cue.
• Test correction: fix the value and resubmit. Confirm stale errors clear and successful submission has clear feedback.

Native browser validation can help, but a generic browser message may not explain the product’s requirement. W3C notes that native validation behavior and what is exposed can vary by browser and screen-reader combination. Assess the actual experience rather than assuming a browser tooltip covers every case.

Check color, contrast, controls, and responsive layouts

Review interface meaning without relying on a color distinction. Required fields, errors, selected items, and success states need another cue, such as text or a clear symbol with an accessible name. The DOJ guidance on web accessibility describes color-only cues and insufficient contrast among common barriers; W3C’s design tips also cover contrast, identifiable interactive elements, labels, feedback, navigation, and different viewport sizes.

• Inspect important text and control boundaries against their backgrounds, including hover, focus, disabled, selected, and error states.
• Check whether links and buttons look and behave like interactive elements and have understandable names.
• Compare navigation across pages: repeated controls should be recognizable and changes should not make the user lose context.
• At narrow widths and enlarged text, confirm that users can still reach content and operate controls without unintended clipping or overlap.

A screenshot is useful for comparing visual states and viewport behavior. It cannot tell you whether a control works from the keyboard, whether its accessible name is meaningful, or whether a screen reader announces feedback correctly. Pair visual review with interaction checks.

Capture screenshots to document a visual bug

For a repeatable visual report, capture the same route at the same viewport and state. A local browser automation script can make the capture consistent. This Playwright example runs with Node.js after installing Playwright and its Chromium browser:

npm install --save-dev playwright
npx playwright install chromium

// save as capture-ui-bug.mjs
import { chromium } from 'playwright';

const target = process.argv[2] ?? 'http://localhost:3000';
const browser = await chromium.launch();
const page = await browser.newPage({
  viewport: { width: 390, height: 844 },
  deviceScaleFactor: 1,
});

try {
  await page.goto(target, { waitUntil: 'networkidle', timeout: 30000 });
  await page.screenshot({ path: 'ui-bug.png', fullPage: true });
  console.log(`Saved ui-bug.png for ${target}`);
} finally {
  await browser.close();
}

node capture-ui-bug.mjs http://localhost:3000

Use a controlled test account and non-sensitive data. Do not capture private customer information into an issue tracker. For a dynamic page, add explicit setup steps before the screenshot, such as opening the relevant menu or entering the test values. Keep keyboard and assistive technology findings in the report separately; an image is evidence of appearance, not operation.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. A single GET request can return a PNG, JPEG, WebP, or PDF. For UI review, use captures to compare rendered states or document a visual regression; still perform keyboard, form, and assistive technology checks directly.

See the ScreenshotNeo API documentation. This cURL example saves a WebP capture:

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

Python:

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)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

The Node example uses Bun’s file writer. In Node.js, save the response body with the built-in file APIs:

import { writeFile } from 'node:fs/promises';

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners are accepted like a visitor and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is on every plan.

Sign up for 1,000 free screenshots a month, with no card required.

Troubleshooting UI bug investigations

Symptom	Possible cause	Next step
Keyboard focus seems to skip a control	The control may not be keyboard-focusable, may be hidden in the current state, or custom code may have changed focus behavior.	Check the control in the rendered state, then inspect its semantics and focus handling. Record the exact key sequence and state.
Focus enters a dialog but cannot leave	A modal or custom widget may have no working exit path, or focus management may not match its open and closed states.	Reproduce from a clean page state and record how the dialog opened. Test the documented close action and the focus destination afterward.
The form reports an error without identifying a field	The page may rely on color, a generic alert, or browser-native validation alone.	Submit one invalid field at a time. Add a text message that identifies the field and describes the problem; retest how the error is exposed.
The screenshot differs between runs	Content, animations, fonts, asynchronous requests, or viewport settings may vary.	Use the same viewport and page state, wait for the relevant content, and disable or settle animation in the test environment. Include the setup in the report.
A screenshot looks correct but users still report a UI problem	Visual appearance does not reveal keyboard operation, accessible names, screen-reader announcements, or every interaction state.	Repeat the actual task with keyboard and assistive technology checks, and document the input method and state separately.
A defect appears only on a narrow screen	Responsive rules may hide, overlap, or reorder content and controls.	Record the viewport size and text scale; repeat the task at that size and verify the control remains visible and reachable.

Performance, reliability, and cost of finding bugs

Start with a small, repeatable manual pass on the user journey where failure matters. A keyboard and invalid-form review costs little to repeat and can expose failures that a screenshot cannot. Add screenshots when visual comparison or a reproducible layout state is useful; do not treat more captures as a substitute for checking behavior.

• Make evidence comparable: hold route, viewport, data, and UI state constant when comparing captures.
• Keep the report small and useful: include one concise image for a visual issue, plus steps and expected/actual behavior. Avoid attaching sensitive data.
• Recheck after the fix: repeat the original task and the failing input or viewport. Verify adjacent states such as focus, error clearing, and successful submission.
• Use standards carefully: WCAG 2.2 supplies defined criteria, not an automatic guarantee that every usability problem has been found. WCAG 3.0 surfaced in the research as a working draft, not the current conformance standard.

ScreenshotNeo charges only for clean shots; bot checks, CAPTCHA pages, blank pages, timeouts, failed loads, and cache hits are not billed. Its listed monthly plans are Free (1,000), Starter ($5 for 3,000), Growth ($15 for 15,000), Pro ($39 for 60,000), Scale ($99 for 250,000), and Business ($249 for 1,000,000); annual billing gives two months free. Use the response’s X-Page-Verdict and X-Billed headers to tell what happened to a capture. Choose a plan based on the capture volume you need; the article’s manual checks do not require a screenshot API.

Frequently asked questions

Can an automated accessibility scan find every UI bug?

No. Automated checks can help identify some issues, but the workflow here depends on using the interface, checking what errors communicate, and reviewing states across input methods and viewports. The research evidence does not establish the effectiveness of any scanner or suggest that a scan proves conformance.

Does a passing WCAG check mean the interface is easy to use?

It means the evaluated content met the particular criteria and scope that were checked. It does not mean every usability problem has been found. Include task-based review and feedback from people who use the interface.

Is WCAG 3.0 the current conformance standard?

No. The cited WCAG 3.0 material is a working draft. Use WCAG 2.2 as the normative reference for the requirements described in this guide.

Should every failed form rely on browser validation?

Not by assumption. Check the actual browser and assistive technology experience, and ensure an automatically detected error identifies the item and describes the issue in text.

What should a UI bug report include?

State the user task, starting state, input method, viewport, reproduction steps, expected result, actual result, and affected control. Add a screenshot when appearance is relevant.